lkml.org 
[lkml]   [2006]   [Apr]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks
From
Date
On Tue, 2006-04-18 at 13:57 -0700, Crispin Cowan wrote:
> SELinux has NSA legacy, and that is reflected in their inode design: it
> is much better at protecting secrecy, which is the NSA's historic
> mission. AppArmor has legacy in intrusion prevention, and so its primary
> design goal was to prevent compromised programs from compromising the
> host. Name-based access control is better at that, because it lets you
> directly control which programs can change the contents of path names
> that have critical semantic meaning in UNIX/Linux, such as /etc/shadow,
> /etc/hosts.allow, /srv/www/htdocs/index.html and so forth.

This is bunk, pure and simple. The core security model of SELinux is
Type Enforcement, and Type Enforcement was originally used for
integrity, as a mechanism for complementing and filling in the gaps left
by the MLS (secrecy/confidentiality) model. Type Enforcement can be
used for confidentiality as well, as it is just a simplification of the
Lampson access matrix, but its original goals were integrity oriented.
Name-based access control is _not_ better for integrity. You don't want
trusted program FOO (e.g. /bin/su) to accept data from an untrustworthy
file that happens to be named /etc/shadow in your namespace, so you want
your integrity controls to be governed by the real security attributes
of the real object, not just its name. The only argument I've seen
regarding "names are better for integrity" is that it is easier to
preserve the association when the object is re-created at that location.
But that association may be fallacious - if an untrustworthy process
re-created /etc/shadow, I don't want it to retain an association with
high integrity data.

--
Stephen Smalley
National Security Agency

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

\
 
 \ /
  Last update: 2006-04-19 14:42    [W:0.199 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site