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

[alexofen at gmail.com]

 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

 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?

 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?
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.

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).

  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

 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?


 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.

 That is good to here. As you see I was worried it could have been taken
the wrong way, just because I have quite some strong wishes and opnion in
terms of what should be strict security etc. etc. But indeed I really like
the AA project of course

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

default /** {

}


 regards,
Alexander
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20121220/4899c5c3/attachment.html>