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]

Message-Id: <1176822230.3366.65.camel@localhost.localdomain>
Date:	Tue, 17 Apr 2007 11:03:50 -0400
From:	David Safford <safford@...son.ibm.com>
To:	James Morris <jmorris@...ei.org>
Cc:	John Johansen <jjohansen@...e.de>, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: AppArmor FAQ

On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:
> On Mon, 16 Apr 2007, John Johansen wrote:
> 
> > Label-based security (exemplified by SELinux, and its predecessors in
> > MLS systems) attaches security policy to the data. As the data flows
> > through the system, the label sticks to the data, and so security
> > policy with respect to this data stays intact. This is a good approach
> > for ensuring secrecy, the kind of problem that intelligence agencies have.
> 
> Labels are also a good approach for ensuring integrity, which is one of 
> the most fundamental aspects of the security model implemented by SELinux.  
> 
> Some may infer otherwise from your document.

In fact, I am not sure how you can provide integrity support without
labels. AppArmor confines a process, but does not effectively confine 
its output files, precisely because the output files are not labeled. 
Other processes are free to access the unlabeled, potentially malicious 
output files without restriction. 

> Imagine if you were re-inventing Unix and decided to implement pathname 
> security for DAC instead of inode labeling.  What you would have is a more 
> generalized version of apparmor, with the DAC attributes of pathnames for 
> the entire filesystem stored in a text database with an in-kernel regex 
> engine performing path reconstruction and pattern matching on every file 
> access.  Sound like a good idea?  I hope not.

Actually, this is pretty much how z/OS/RACF works. Labels and pathnames
for all files are stored in one database. There are advantages and 
disadvantages to this design, but is does work, and does have an EAL4+ 
certification on a Labeled Security Protection Profile.

> And you can still use pathnames under SELinux to locate an object to 
> label, just as you do with DAC.  You just don't put a security label on 
> the path itself.

SELinux _has_ to use pathnames to fix some ugly cases where new files
are created with the wrong label. It uses restorecond to fix the labels
for files such as resolv.conf, mtab, utab, and wtab, when they are 
created. The restorecond policy file is textual, and separate from the 
SELinux labels, which is somewhat inelegant.

RACF provides both labels and canonical paths for all files in one
location. There is no false dichotomy between path based and label 
based security. I don't know how to do this in Linux, with namespaces, 
mounts, and symlinks, but the concept is an interesting counterpoint 
in the discussion.

dave

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