[apparmor] Generate a default/fallback profile? No blacklisting

[John Johansen]

On 12/19/2012 05:55 AM, alexofen wrote:
> Dear people working with AppArmor,
> 
> I have read the FAQ Wiki:
> This point gives me quite some trouble
> http://wiki.apparmor.net/index.php/FAQ#Is_AppArmor_policy_Default_Deny_.28White_listing.29
> I would ask for your assistence.
> 
> I cannot understand. Either there is enough safety by the ordinary linux (DAC style) file permissions which makes AppArmor and other MACs rather superflous or there is a good point in having AppArmor which then it makes little sense to me to be satisfied that any unkonwn Program results into an unconfined execution of this code?
> 
Well DAC and MAC are orthogonal they each have their place and they complement each other one doesn't necessarily replace the other.

There are plenty of cases where a targeted policy is appropriate, and that you are not running arbitrary unknown programs. In general a targeted policy is not as secure as a strict policy (total system lockdown) but it is much more usable for most people.

Generally we take the approach of if the policy is strict enough that the user is turning it off then it is of no benefit, so we default to a more relaxed targeted policy that raises the bar but is not perfect. For those who want tighter security, and want to learn/deal with the added complexity we try to make it easy for them to update the policy.

For arbitrary execution of unknown code we are working on improving our dynamic sandboxing so that these applications can be run in very tight little containers.

> Is there a way to have something like a fallback/default deny thing for applications that are not profiled?
> 
you can define a default profile by doing

profile default /** {
  #insert default profile rules here
}

to have this applied to all processes it must be precompiled and loaded from the init ramfs

However a default policy does not really end up being much different than unconfined.

> The ease of deployment should not be the primary concern and the safety sacrifized. The product sold (AppArmor)
Our experience is actually contrary to this. Users will turn off security if it gets in their way too much. Generally speaking users don't understand and don't want to understand security, they just want to do what they want and it gets in their way. Our single biggest problem is that users complain that our loose targeted policy is too tight and they just turn it off instead of tweaking it for what they want. Security that isn't used has no benefit, a loose targeted policy while imperfect still raises the bar and is better than nothing.

> without profiles is rather useless (as it is in most desktop Ubuntus) and I assume only by setting it active fall all programs via
AppArmor is not sold, its a community project that distros are free to integrate into their systems. It is impossible for us to define a strinct policy that would work for a distro as each distro is different and would have to modify it to suite their system.

The argument about targeted vs. strict policy also applies at the distro level, where distros have limited resources and won't apply security if its too much work. Keeping a strict policy up to date is an absolute pain, as it requires a lot of effort in testing and evaluating changes in every application.

Which brings up another problem we have, several upstream projects do not like that we are imposing additional security constraints, and complain that there applications/frameworks weren't designed to deal with this. This is in fact very true of the linux frameworks, and added security can result in weird hard to debug failures. And in some cases over zealous policy has lead to security holes because applications often do not properly check returned error codes and do stupid things like assuming just because they are root the can setuid to another user.  When the setuid fails and the applications continues to execute what should have been priv-sep code as root you get new holes.

> a default profile that is limiting would be a safe solution.
> 
A default profile can provide extra security, but it takes additional effort. Without a broader profile set with profiles on all applications that require special privilege, a default profile that works is effectively the equivalent of unconfined.

Currently setting a default profile that applies to the whole system from boot is a bit of a pain but we do have plans to improve that. Unfortunately there is enough other work happen that I don't see it happen soon.

> I do not wanna provoke or insult etc. And if for heaven's sake it must be that we have cases in which AppArmor
> is deployed with this kind of "everything unprofiled is white", that is ok. But what is the trick to setup a default profile
>
np. no insult taken, its a valid question. As I said above targeted policy has been the projects focus because of experience with users and distros, that doesn't mean we don't want to be able to provide strict policy and we have slowly improved our ability here.

The default profile solution is to provide a profile that matches everything

default /** {

}

but to apply to everything it must also confine init, which means it needs to be compiled and loaded from the initramfs. To make this easier the initial default profile can be just a shell, that gets replaced after init with an expanded policy load, you generally don't want to deny what init is doing during early boot anyways.

Even doing this setting up a strict policy is not easy, but is possible. We have plans to improve this but I can't speak to when those improvements will land