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

[Joshua Brindle]

Tony Jones wrote:
> On Mon, Apr 24, 2006 at 11:16:25AM -0400, Joshua Brindle wrote:
>   
> > To make this much more real, the /usr/sbin/named policy that ships with 
> > apparmor has the following line:
> >     
>
> Ships with AppArmor where?  On SuSE?
>   
apparmor-profiles-2.0.tar.gz  available on the novell forge.
>   
> > /** 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.
> >     
>
> The d_path changes for absolute path mediation for chroot are not yet in any 
> SuSE release. Nor are they reflected in any developed profiles (yet).
>
>   
So you are currently not protecting this access vector and it was said 
pretty clearly that this patch wouldn't make it into mainline. I don't 
understand how you intend to address this. Are people running different 
distros out of luck with regard to Apparmor?

> Another direction is a new security_chroot hook together with appropriate 
> CLONE_FS tracking (inside AppArmor) to force chrooting confined tasks into a 
> subprofile (similar to change hat). We are evaluating the options based on 
> feedback here and from other places.  Hence the RFC.
>
> I hope this helps
Thats fine, what about private namespaces, which are better than chroots 
anyway in terms of flexibility. Are you going to be able to specify the 
precise namespace that an app may use in order to use these policies?

By the way, the fact that there is such a rule in the policy isn't the 
problem, its a symptom of the problem. All of these 'fixes' seem to be 
band-aiding the symptoms. Aren't these alot of hoops to jump through for 
the sake of using paths?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/