Re: [RFC][PATCH 0/11] security: AppArmor - Overview

[Tony Jones <tonyj@suse.de>]

On Tue, Apr 25, 2006 at 01:12:37PM -0400, Valdis.Kletnieks@vt.edu wrote:
> On Mon, 24 Apr 2006 11:16:25 EDT, Joshua Brindle said:
> 
> > To make this much more real, the /usr/sbin/named policy that ships with 
> > apparmor has the following line:
> > /** r,
> > Thats right, named can read any file on the system, I suppose this is 
> > because the policy relies on named being chrooted. So if for any reason 
> > named doesn't chroot its been granted read access on the entire 
> > filesystem.
> 
> Somebody *please* tell me I hallucinated the posting that said AppArmor
> restricts the use of chroot by confined processes...

Nope. I don't believe you've been chomping on any 'shrooms. The profile must 
grant the confined task 'capability sys_chroot', even if the task already has 
that capability in it's effective set.

> In any case, the incredibly brittle behavior of this policy in the face
> of chroot() failure (from the people who should *know* how to write AppArmor
> policy, no less) is just proof of why making it simple for non-experts to
> write policy is a Bad Idea....

I believe this was addressed in another post in this thread.

But yes, without the ability to either generate an absolute pathname or to
force a chrooted task into a distinct subprofile there currently exists (as 
mentioned in the overview and patch descriptions) an issue of name collision
within the one profile.  

Improvements clearly need to be made. This was the purpose of posting for 
feedback, but it's quite the claim to go from this to your above assertion of 
"proof".

Tony