[apparmor] [PATCH 2/2] Default profiles to be chroot relative
John Johansen
john.johansen at canonical.com
Fri Feb 17 07:27:22 UTC 2012
On 02/16/2012 03:50 PM, Steve Beattie wrote:
> On Thu, Feb 16, 2012 at 08:26:10AM -0800, John Johansen wrote:
>> Due to changes in path looks and the work going forward default profiles
>> to resolve relative to the chroot instead of the namespace.
>
> Hrm, can you expand on why it's needed? The patch itself looks fine,
> just unclear on the motivation. Is this driven by the upcoming mount
> work?
>
No not the mount work. It was triggered by the lkml discussion around
the rework of __d_path and disconnected paths etc. Currently we can
maintain the behavior of chroot paths walking back to the namespace
root, however there are those who would like to see this go away.
And I can see their point, from the pov of the tasks such files are out
of its view, so why are we treating them different than disconnected
paths.
For disconnected paths its not safe to reattach them so we have been
relying on the small bit of label caching we do to avoid having to
re-lookup the path (which will result in access being denied).
Long term the goal has been to fix this fully with implicit labeling
and delegation.
So the goal is to move to treating chroot applications the same. It
provides consistency whether pivot root, bind mounts, or chroots are
used.
It also makes dealing with the policy inside and outside of a chroot
easier. Think stacked profiles, a system one and the one for the
OS is the chroot/container. In those cases the ones in the container
need to be chroot relative while system one of the host OS can be
either, but if they are both chroot relative, there is consistency
and things are easier to understand.
We don't have a lot of users of apparmor + chroots at the moment so
making the switch now makes a lot of sense. It won't break any thing
that isn't using chroot, and with the containers work, and stacking
that is coming, not making the switch now could lead to problems
> (Cue my usual note about noticing that we don't have tests around the
> behaviors here.)
>
hrmmm, /me wonders what happened to them, we did have somethings at
one point.
More information about the AppArmor
mailing list