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

[John Johansen]

On 12/08/2011 11:01 AM, Ángel González wrote:
> 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.
> 
And what if apparmor isn't doing that?  This week we very nearly lost
that ability and we need to clean it up.

Access to open fds in the real root will still be allowed, but everything
opened or revalidated in the chroot will be agaist the chroot, or be
reported as a disconnect path.

I do understand your point about liking to see the chroot base prepended
for policy mediating the chroot.  However it doesn't work for policy
loaded from within a chroot, and it doesn't work for fs namespaces.

>> 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.
> 
well that is partly why I would like to do explicit profile change.  Here
is prechroot, here is post.  Putting post chroot rules that are relative
to the chroot in the same profile is completely insecure.  I do understand
where you are coming from, and this is what we have done in the past.

But we basically have a transition window, how long it will be or whether
it ends up being permanent I can't say for sure, so it is going to be better
to make this case use the flag, so that if it breaks we have a chance of
dealing with it sanely.

I do know this breaks current policy for this use case, and that can be
painful.

> 
>> 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.
They can do it now if you don't want to mediate the chroot, as you said
that breaks isolation.  A fake stacking where you let the chroot load
its own policy but it isn't enforced is coming this cycle (next release
after 2.7) with a true stack following in the release after that.

The first parts of the fake stack should be posted for review real soon.

> 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.
> 
close but we can actually do a little better than that.  The chroot isn't
secure but it and the system can have separate policy if you set it up
correctly.

What you do is you put the chroot in a separate policy namespace, and
that way its profiles get loaded to that namespace.  The chroot isn't
secure but the policy it is using separate from the rest of the system
policy and it can't manipulate the rest of the system policy.

Once we get true stacking you will be able to secure the chroot, and
allow the chroot to have its own policy.  The next step after that will
be to finally allow users to load their own policy into their own policy
namespace, which will only get applied to their own programs.