Re: [RFC][PATCH 0/11] security: AppArmor - Overview

["Theodore Ts'o" <tytso@mit.edu>]

On Mon, Apr 24, 2006 at 02:18:50PM +1000, Neil Brown wrote:
> Think about the name of this system for a minute.  "AppArmor".
> i.e. it is Armour for an Application.  It protects the application.
> It doesn't (as far as I can tell: I'm not an expert and don't work on
> this thing) claim to protect files.  It protects applications.
...
> While the protection against subversion cannot be complete, it can be
> sufficient to dramatically reduce the chances of privilege
> escalation.   There are lots of wrong things you can get an
> application to do once you find an exploitable bug.  Many of these
> will lead to a crash.  AppArmor will not try to protect against these
> (I suspect).  There are substantially fewer that lead to privilege
> escalation.   AppArmor focusses its effort in terms of profile design
> on exactly these sorts of unplanned behaviours.
> 
> So I think you still haven't given convincing evidence that AppArmor
> is broken by design.

I have to agree with Neil here.  I spent over 10 years doing network
security as my day job, including chairing the IP Security working
group and being a member of the IETF Security Area Directorate, before
switching over to Linux as the thing that would pay the bills, and I
can state quite authoratatively that perfect security which is never
used because it's too hard to install, maintain, and configure, isn't
worth much compared to imperfect security which is easy enough such
that users always use it by default.

The goal of protecting against broken, buggy applications is a worthy
one.  If people can show that for a large set of stack overruns, or
other types of buggy applications, it is possible to evade AppArmor by
doing something clever, then AppArmor would need to be fixed or it's
not worth doing.  But if it can prevent a large class of buggy
applications from allowing an atttacker to escalate that bugginess
into a system penetration, then it has added value.

In the security world, there is a huge tradition of the best being the
enemy of the good --- and the best being so painful to use that people
don't want to use it, or the moment it gets in the way (either because
of performance reasons or their application does something that
requires painful configuration of the SELinux policy files), they
deconfigure it.  At which point the "best" becomes useless.

You may or may not agree with the philosophical architecture question,
but that doesn't necessarily make it "broken by design".  Choice is
good; if AppArmor forces SELinux to become less painful to use and
configure, then that in the long run will be a good thing.

						- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/