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

[John Johansen]

On 12/20/2012 08:14 AM, alexofen at gmail.com wrote:
> On 12/19/2012 11:24 PM, John Johansen wrote:
>> On 12/19/2012 05:55 AM, alexofen wrote:
>>> Dear people working with AppArmor,
>>>
>>> [...]
>> [...]
>> 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.
> Why should we care about people that do not appreciate security and are willingiy discarding all for the little effort involved?
> I see the point totally, I only do not share the conclusion
> 
fair enough

>> 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 AA connected to the LXC project? is LXC what you referred to?
No, and no. Though there is work to provide better lxc integration as well so that you can
use lxc as a VM and have an apparmor profile wrap the VM and also allow the VM to have its
own set of profile just like a real VM with unshared kernel.

apparmor can also be used to setup sandboxes in a manner very similar to what lxc does, or
in fact eventually conjuction with lxc.

The sandbox tool is just in the protype stages and works in conjunction with the templating
tool (another tool in the prototype stage).

It lets you create a profile for an application by referencing a set of templates, which
in turn are mostly ways of grouping apparmor abstractions.

The sandbox is setup so that it doesn't apply to the system in general, and just to the
application launched in it. eg.
  ./aa-sandbox --templates-dir=`pwd`/easyprof/templates -X /usr/bin/gedit

the code is at
  https://code.launchpad.net/~jdstrand/+junk/apparmor-sandbox

and the thread covering it in more detail at
https://lists.ubuntu.com/archives/apparmor/2012-August/002992.html

>>> 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.
> why would there be no difference?
the qualifier here is "much" different, and it really depends on the rest of the policy

It can actually very different, depending on the work that gets put into it and the rest of
policy. Let me put it this way, as an upstream shipping an example policy set, that can not
even rely on where distro decide to put things the default profile we would have to ship
would not be much different from unconfined, unless we expected distros to do significant
modification.

admittedly this
> Assume in a attack scenario I can manage to dispose a executable somewhere.
> a) without the default rule this executable would be (that is how I understand it) without a AA profile and hence
> NO AAprofile equals unconficed. Only DAX left.
> 
correct

> b) with a default or fallback rule the executable likewise to above does not have a dedicated AA-profile, but (again  this is my undestanding or idea)
> there can be still some restrictions (those of the default).
> 
correct

again its what restrictions your willing to impose for those applications going into the default. Doing things like setting up roles, or profile admin tools can allow significant tightening of the default

>>> 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.
> Thank you for sharing the experience. Maybe I am thinking "no pain, no gain", having stricter rules, even at the short-term necessitated effort would result in a long-term security gain. It's a absurd thinking but in a way AA this idea is like this "better a poorly working diet" than one that the person skips. Well anyhow either way we will have overweight person. (I excuse this crude example). I just so much think any progress is done once the necessity exits, as long as you exemp users from doing some work (its mostly the distributions maintainers, right) they happily free-ride and do very little, since possible
indeed progress is slow, and as a small project we really are not in position to force change. We do try to cooperate with other projects to bring about security improvements.

Even the distros have problems forcing change as this is some what the antithesis of what open source is. Forks and new derivatives happen all the time, when there is something a user doesn't like. You wouldn't believe how many people/projects recommend to just turn apparmor off in its entirety, because a profile blocks some behavior. This is particularly annoying because policy has been deliberately set up to make it easy for a user to extend or selectively disable individual profiles.

>>> 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.
> I wanna apologize here. I used a very bad term. Let me take the chance to applaud and thank the people giving effort and work an life for this good thing AA.
>> 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.
> I am sceptical that it should or must be equivalent with unconfined. Can you elaborate why / how you mean this?

hopefully my explanation above is sufficient.