linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Shaya Potter <spotter@cs.columbia.edu>
To: Crispin Cowan <crispin@novell.com>
Cc: James Morris <jmorris@namei.org>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Andi Kleen <andi@firstfloor.org>,
	Casey Schaufler <casey@schaufler-ca.com>,
	linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: AppArmor FAQ
Date: Wed, 18 Apr 2007 16:03:19 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0704181552370.10574@takamine.ncl.cs.columbia.edu> (raw)
In-Reply-To: <4626746A.9010701@novell.com>

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

  reply	other threads:[~2007-04-18 20:03 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-16 21:33 AppArmor FAQ John Johansen
2007-04-17  0:20 ` James Morris
2007-04-17 15:03   ` David Safford
2007-04-17 16:00     ` Karl MacMillan
2007-04-17 18:05       ` Andi Kleen
2007-04-17 17:47         ` James Morris
2007-04-17 18:10           ` Andi Kleen
2007-04-17 20:19             ` Casey Schaufler
2007-04-17 20:50               ` James Morris
2007-04-17 21:16               ` Andi Kleen
2007-04-17 21:41                 ` Karl MacMillan
2007-04-17 22:12                   ` Andi Kleen
2007-04-17 22:29                     ` Karl MacMillan
2007-04-17 21:58                 ` Alan Cox
2007-04-18 13:45                   ` James Morris
2007-04-18 14:33                     ` Shaya Potter
2007-04-18 19:41                     ` Crispin Cowan
2007-04-18 20:03                       ` Shaya Potter [this message]
2007-04-18 21:14                       ` James Morris
2007-04-19 17:14                       ` Stephen Smalley
2007-06-09 21:01                       ` Pavel Machek
2007-06-09 21:28                         ` david
2007-06-09 23:02                           ` Pavel Machek
2007-06-10  0:06                             ` david
2007-04-18 20:15                     ` David Lang
2007-04-19 17:27                       ` Stephen Smalley
2007-04-17 21:48               ` Karl MacMillan
2007-04-17 23:12                 ` Casey Schaufler
2007-04-17 22:26             ` Karl MacMillan
2007-04-19 17:46         ` Stephen Smalley
2007-04-20 18:45           ` David Lang
2007-04-20 19:23             ` Karl MacMillan
2007-04-17 23:09     ` Crispin Cowan
2007-04-17 23:20       ` Karl MacMillan
2007-04-19 17:56       ` Stephen Smalley
2007-04-17 21:55   ` Karl MacMillan
2007-04-17 22:55     ` Crispin Cowan
2007-04-17 23:13       ` Karl MacMillan
2007-06-09 14:11       ` Pavel Machek
2007-04-18  7:21     ` Rob Meijer
2007-04-18  7:08       ` David Lang
2007-04-18 13:33         ` James Morris
2007-04-18 12:15       ` Joshua Brindle
2007-04-18 13:31         ` Casey Schaufler
2007-04-18 14:05         ` Rob Meijer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0704181552370.10574@takamine.ncl.cs.columbia.edu \
    --to=spotter@cs.columbia.edu \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=andi@firstfloor.org \
    --cc=casey@schaufler-ca.com \
    --cc=crispin@novell.com \
    --cc=jmorris@namei.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).