linux-kernel - Re: AppArmor FAQ

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 18 Apr 2007 16:03:19 -0400 (EDT)
From:	Shaya Potter <spotter@...columbia.edu>
To:	Crispin Cowan <crispin@...ell.com>
cc:	James Morris <jmorris@...ei.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Andi Kleen <andi@...stfloor.org>,
	Casey Schaufler <casey@...aufler-ca.com>,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/