public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Joshua Brindle <jbrindle@tresys.com>
To: Crispin Cowan <crispin@novell.com>
Cc: David Wagner <daw-usenet@taverner.cs.berkeley.edu>,
	linux-kernel@vger.kernel.org,
	LSM ML <linux-security-module@vger.kernel.org>
Subject: Re: AppArmor FAQ
Date: Tue, 24 Apr 2007 21:03:37 -0400	[thread overview]
Message-ID: <462EA8E9.6050700@tresys.com> (raw)
In-Reply-To: <462D5644.2090103@novell.com>

Crispin Cowan wrote:
> 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
>
>   
Also, things like:

    share_mem /usr/bin/firefox r,        # /bin/foo can share memory with /usr/bin/firefox for read only

clearly show that you aren't using native abstractions for IPC. The 
native abstraction for shared memory would be the key used when creating 
the shared memory segment. The same goes for message queues which are 
noticeably missing from the "simplified" IPC model.

This, of course, begs the question of whether you are using native 
abstractions for profiles at all, processes have nothing to do with the 
binary they started from after they've been started. The binary on disk 
could be something entirely different than the process from which it ran.

  parent reply	other threads:[~2007-04-25  1:03 UTC|newest]

Thread overview: 68+ 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 21:51                   ` David Wagner
2007-04-17 22:17                     ` Alan Cox
2007-04-18  1:34                     ` James Morris
2007-04-18  1:55                       ` David Wagner
2007-04-18  2:20                         ` James Morris
2007-04-18  2:31                           ` David Wagner
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
2007-04-18 21:14                       ` James Morris
2007-04-19 16:35                         ` David Wagner
2007-04-19 17:39                           ` Stephen Smalley
2007-04-19 20:47                             ` David Wagner
2007-04-24  0:58                               ` Crispin Cowan
2007-04-24  2:03                                 ` Joshua Brindle
2007-04-25  1:03                                 ` Joshua Brindle [this message]
2007-04-19 17:14                       ` Stephen Smalley
2007-04-19 20:08                         ` David Wagner
2007-04-19 21:03                           ` Stephen Smalley
2007-04-19 21:08                             ` James Morris
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-19 18:19                     ` Bernd Eckenfels
2007-04-19 20:19                       ` James Morris
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-17 23:53         ` David Wagner
2007-04-18  1:56           ` James Morris
2007-04-18  2:08             ` David Wagner
2007-06-09 19:38               ` Pavel Machek
2007-04-19 17:56       ` Stephen Smalley
2007-04-19 20:54         ` David Wagner
2007-04-19 21:17           ` 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=462EA8E9.6050700@tresys.com \
    --to=jbrindle@tresys.com \
    --cc=crispin@novell.com \
    --cc=daw-usenet@taverner.cs.berkeley.edu \
    --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