[apparmor] Changing how chroots are handled
John Johansen
john.johansen at canonical.com
Sun Dec 4 01:18:07 UTC 2011
So recently I have been asked if we can remove our use of mnt_ns->root for
some vfs cleanups. However being backwards compatible is turning into
a pain.
We use the mnt_ns->root for two things, to detect that we are in a chroot
and if we are, it determines the visibility of the returned path.
Removing access to mnt_ns->root will remove our ability to detect that
we are in a chroot, and to determine path visibility when in a chroot.
So the question arises of why do we want to detect that we are in a chroot?
This allows resolving paths to the file system namespace root (ie. the
path before the chroot was done).
This makes it so that all accesses done within the chroot to apparmor
look like accesses prechroot. ie. if we chroot to /var/chroot/
then accesses with in the chroot to /etc/ still look like /var/chroot/etc
Doing this was a way of avoiding path aliasing of pre and post chroot paths
within a profile. The alternative was changing profile for pre and post
chroot mediation, which is a better solution as outline in
https://lists.ubuntu.com/archives/apparmor/2011-December/001776.html
However requiring profile transitions does not provide compatibility with
older policy. I have not been able to come up with a viable solution that
matches the old semantics. I think we are just going to have to require
that older profiles be modified, or use an older kernel.
The semantics of mediating the path outside of the chroot are dubious at
best, so from a security stand point making the move makes sense.
john
More information about the AppArmor
mailing list