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: <462D5644.2090103@novell.com>
Date:	Mon, 23 Apr 2007 17:58:44 -0700
From:	Crispin Cowan <crispin@...ell.com>
To:	David Wagner <daw-usenet@...erner.cs.berkeley.edu>
CC:	linux-kernel@...r.kernel.org,
	LSM ML <linux-security-module@...r.kernel.org>
Subject: Re: AppArmor FAQ

David Wagner wrote:
> James Morris  wrote:
>   
>> [...] you can change the behavior of the application and then bypass 
>> policy entirely by utilizing any mechanism other than direct filesystem 
>> access: IPC, shared memory, Unix domain sockets, local IP networking, 
>> remote networking etc.
>>     
> [...]
>   
>> Just look at their code and their own description of AppArmor.
>>     
> My gosh, you're right.  What the heck?  With all due respect to the
> developers of AppArmor, I can't help thinking that that's pretty lame.
> I think this raises substantial questions about the value of AppArmor.
> What is the point of having a jail if it leaves gaping holes that
> malicious code could use to escape?
>
> And why isn't this documented clearly, with the implications fully
> explained?
>
> I would like to hear the AppArmor developers defend this design decision.
>   
It was a simplicity trade off at the time, when AppArmor was mostly
aimed at servers, and there was no HAL or DBUS. Now it is definitely a
limitation that we are addressing. We are working on a mediation system
for what kind of IPC a confined process can do
http://forge.novell.com/pipermail/apparmor-dev/2007-April/000503.html

When our IPC mediation system is code instead of vapor, it will also
appear here for review. Meanwhile, AppArmor does not make IPC security
any worse, confined processes are still subject to the usual Linux IPC
restrictions. AppArmor actually makes the IPC situation somewhat more
secure than stock Linux, e.g. normal DBUS deployment can be controlled
through file access permissions. But we are not claiming AppArmor to be
an IPC security enhancement, yet.

The proposed set of patches is a self-contained access control system
for file system access, and we would like it reviewed as such. Current
AppArmor docs are quite explicit that AppArmor only mediates file access
and POSIX.1e capabilities.

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
Director of Software Engineering   http://novell.com

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