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: <462553A9.70504@novell.com>
Date:	Tue, 17 Apr 2007 16:09:29 -0700
From:	Crispin Cowan <crispin@...ell.com>
To:	David Safford <safford@...son.ibm.com>
CC:	James Morris <jmorris@...ei.org>,
	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

David Safford wrote:
> 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. 
>   
That depends on what you mean by "integrity." It is true that AppArmor
does not directly manage information flow. AppArmor assumes that if you
granted write permission to /etc/resolv.conf, that you meant to do that.
Whether any other process is permitted to access /etc/resolv.conf is
determined by those other process's respective profiles.

What AppArmor provides is a way for administrators to confine software
that they have to run but do not trust. The use of pathnames means that
the administrator can understand the exact meaning of the security
policy, without having to do a complete labeling of the file system. The
flip side of not managing information flow is that each profile is
independent of every other profile.

The meaning of a file is how other processes interpret it. Until then,
/etc/resolv.conf is just a quaint bag of bits. What makes it special is
that it is what each process gets when they open the well-known
"/etc/resolv.conf". Which is why it is useful to guard which processes
can read or write to /etc/resolv.conf; the name is what makes its
content special, not the other way around.

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
Director of Software Engineering   http://novell.com
"You cannot say anything that is both simple and complete."--Crispin on Goedel

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