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

[Joshua Brindle <method@gentoo.org>]

Joshua Brindle wrote:
> Andi Kleen wrote:
>> On Monday 24 April 2006 15:11, Joshua Brindle wrote:
>>
>>  
>>> Sure but if, instead, it's able to open /var/chroot/etc/shadow which 
>>> is a hardlink to /etc/shadow you've bought nothing. You may filter 
>>> out worms and script kiddies this way but in the end you are using 
>>> obscurity (of filesystem layout, what the policy allows, how the 
>>> apps are configured, etc) for security, which again, leads to a 
>>> false sense of security.
>>>     
>>
>> AppArmor disallows both chroot and name space changes for the 
>> constrained
>> application so the scenario you're describing cannot happen. What 
>> happens
>> with unconstrained applications it doesn't care about by design.
>>
>> This has been covered several times in this thread already - please pay
>> more attention.
> I was paying attention, thank you. Can apparmor force an application 
> to only start within a certain chroot? So it may not be able to chroot 
> during runtime but if you can't be sure that it starts in the chroot 
> the argument still applies. Particularly since the app may not even 
> fail to run outside the chroot given that it will have access to all 
> the same libraries, etc it did inside (due to the paths being the same).

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. If I'm misunderstanding this policy please correct me but I 
believe this shows the problem very loudly and clearly.