lkml.org 
[lkml]   [2007]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: AppArmor FAQ
On Wed, 18 Apr 2007, Crispin Cowan wrote:

> Please explain why labels are necessary for effective confinement. Many
> systems besides AppArmor have used non-label schemes for effective
> confinement: TRON, Janus, LIDS, Systrace, BSD Jail, EROS, PSOS, KeyOS,
> AS400, to name just a few. This claim seems bogus. Labels may be your
> method of choice for confinement, but they are far from the only way.

One problem with AppArmor and Janus and Systrace and everything else that
relies on pathname resolution is the point where they do the pathname
resolution.

If you read the janus, systrace, subdomain (apparmor's predecssor?)
papers, you'll see how they have to jump through hoops to handle things
like symlinks, when there's no fundamental reason why they have to.

If one simply worked at the FS level, all one cares about is lookup() and
permission. You have a set of rules that lookup() is able to use to
dynamically tag dentries and permission() then checks that tag. One
doesn't jump through hoops anymore.

So, while I sound like a broken record, something like a stackable file
system works wonders here (I know, I implemented one). Now, stackable
file systems aren't perfect here (mount point crossing, additional mounted
file systems on top of the stackable file system) can cause problems,
overall it seems like a cleaner solution.

Another option would be if the LSM could be extended to allow a simple
method of storing "private" data along with every dentry/inode (the main
reason one needs a stackable file system). In this way, if the lookup()
oepration was extended to be able to take a function that filled in that
data and permission() was able to be extended to take a function that
could use that data, one wouldn't even need a stackable file system, but
one would still be operating at the simplest layer (which is the file
system).
-
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: 2007-04-18 22:07    [W:1.351 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site