[apparmor] Handling chroot, pivotroot, and file system namespaces

[Ángel González]

On 08/12/11 00:54, John Johansen wrote:
> (snip)
> However,
> The variable is going to be a bit more problematic.  If we use a
> userspace variable then @{root} would be currently doable.  But
> may not give you the value you want when you do
> 
> chroot /** {
> 
> }
> 
> as it wouldn't be able to pickup the dynamic value of where you
> actually chroot.  It possible we could add a kernel var that would
> get updated, but that presupposes having kernel vars (which we don't
> yet.

They should probably be added anyway. Rules like /proc/* make me a bit
nervous. I'd very much prefer /proc/@{PID}/whatever
(yes, I know you proposed the same on June last year).



> Also part of the point of this switch is that using the namespace
> root in the chroot is problematic at best so using @{root} within
> the chroot would not get you what you want as the paths are actually
> relative to the new root. Nor would you be able to open new files
> outside the scope of the chroot, though you could inherit access
> from an already open fd.

I don't follow you, if apparmor is expanding the path to the real root,
you would need the @{root} (or its expansion eg. /var/chroot/foo) to
make them work.

Part of my point is that seeing /var/foochroot/etc/passwd rw gives a
more secure feeling than /etc/passwd rw.

> I suppose it would be possible to add something to say that the rules
> should be relative to @{root}, but then all your file rules would
> have to be prefixed with @{root}, and I not sure that is what you want.

There could be a flag noting that the profile rules are relative to the
root, for the benefits of normal profiles loaded inside the chroot. I
think they are better explicit in profiles of process doing chroot
changes, though.


> Part of this comes from chroots and namespaces being allowed to
> load their own profile sets (eg they are being used as a light vm).
> And you want the profiles they load to have rules relative to their
> own root.  And accessing files outside of that root makes no sense,
> except maybe in the case of stacking, where the earlier profiles in
> the stack may want to access something that was opened before the
> transition.

I'm not sure what't the right way to handle namespaces.
What's the current status of profile loading inside chroots? It would
apparently break the apparmor isolation, once you allow processes
confined in the chroot to load their own profiles.
And if you loaded the chrooted processes with the system wide profiles,
that would allow /home/eve/usr/bin/passwd (chrooted to /home/eve/) with
the profile for the *real* passwd. So you would be left with the
_traditional_ measures: the chroot and the DAC.