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
--
AppArmor mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
