[apparmor] any way of denying profiled executable(s) to be ran at all

[John Johansen]

On 11/16/22 11:59, janko metelko wrote:
> Thank you for making AppArmor, if any of the developers are here. I am not a security guy, but such a solution seems like it should or will become an absolute must-use for any application deployment, locally or on a server.
> 
> I have a question. I want to make a profile that prevents execution of any file from user-writable directories like /home /tmp, *except* if the executable has a AA profile.
> 
> This would effectively mean that the user (or user level process) can't (knowingly or unknowingly) "install" and run anything that wasn't "confirmed" by root.
> 
> It seems I can do this by creating an empty profile for /home/** which denies everything and then creating separate AA profiles for specific executable files inside /home that I allow to run.
> 
> If I understand it right, all executables in /home without profiles will in this case crash or at least can't do any side effects since they are blocked from all IO/shared libs/configs/etc. In practice, they will probably just crash. It would be much nicer experience if such apps would be prevented to run, not start and crash.
> 
> But I can only find directives in AA, that limit or allow certain resorces to the executable, and no directive, that would prevent executable to be ran in the first place.
> 
> Is there any such solution? Am I maybe looking at it all wrong? Should I do this on another level, not with AppArmor?
> 
> *Example*
> 
> Maybe stupid example, but still. Let's say I want to prevent non-root users or RCEs from wget-ing into any other directory other than /tmp. I can simply create a profile for /usr/bin/wget { ... /tmp w, } and the job is done. But user/RCE can then simply do cp /usr/bin/wget ~/mywget and use wget for whatever it wants. If we prevent execution of non-profiled executables in user writable directories then he/it can't do that and our primary objective stands.
> 
> I hope it makes some sense ... Thank you again. Ubuntu rocks also, and Xubuntu! :)
> 

So lets split this into two cases.
1. Executing an application when confined
2. Executing an application when unconfined

there are some differences so it is worth covering

1. Executing an application when confined

When an application is confined all execs are covered by the profiles domain transition rules. Those rules require a qualifier to determine what should be done at exec.
ix - inherit
px - transition to a profile if it exists, otherwise FAIL the exec
cx - transition to a child profile if it exists, otherwise FAIL the exec
ux - transition to unconfined

there are currently a set of fallback options available instead of failing the exec
pix, cix - transition to profile if it exists, otherwise inherit current confinement
pux, cux - transition to profile if it exists, otherwise transition to unconfined.

you can also explicitly deny an exec with a deny rule

   deny x /tmp/*,  # no need for a qualifier on deny rules


So in this case there are a few ways to deny at exec time instead of crashing


2. Executing an application when unconfined

This case is the currently problematic one. Where unconfined tasks essentially use an exec rule of

   pix /**,

meaning no exec will fail, it will either transition to a defined profile or allow the exec to continue as unconfined.

Currently the only way to deal with this is indeed create a "trap" profile that doesn't grant permissions, causing the application to fault after exec

profile trap /tmp/** {
   # no permissions.
}


Obviously this is less than satisfactory. Ideally to avoid this you would be in situation #1, but the reality is that this just isn't how apparmor has been deployed and not all user tasks are confined.


There is work going on to fix this, but it has not landed as of upstream kernel 6.1 or Ubuntu 22.10. When it lands (hopefully 23.04) you will be able to specify attachments that should be denied. Instead of having to create a trap profile. It will be a rule similar to what is in the profile.

   deny x /tmp/**,

and will have the longest left match prioritization, that attachments currently have. That is

   deny x /**,

would stop execution of anything that didn't have a profile defined. But since
   profile example /bin/foo { }

has a more specific attachment match it would take priority and allow exec under that profile.