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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Mon, 2006-04-24 at 03:03 -0400, Theodore Ts'o wrote:
> 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.

Seems like a strawman.  We aren't claiming that SELinux is perfect, and
there is plenty of work ongoing on SELinux usability.  But a
fundamentally unsound mechanism is more dangerous than one that is never
enabled; at least in the latter case, one knows where one stands.  It is
the illusory sense of security that accompanies path-based access
control that is dangerous.  You don't have to be an SELinux advocate to
see the problems with a path-based kernel access control mechanism.

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

Does it have any hope of stopping an attacker who has designed his
attack with full knowledge of AppArmor's design and implementation (no
security through obscurity)?

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

The problems with path-based mechanisms are technical in nature, not
just philosophical.

Stephen Smalley
National Security Agency

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at
Please read the FAQ at

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux