From john.johansen at canonical.com  Sun Nov  1 16:05:27 2009
From: john.johansen at canonical.com (John Johansen)
Date: Sun Nov  1 16:05:35 2009
Subject: [Apparmor-dev] AppArmor and chroots
In-Reply-To: <4AE84C15.2020803@canonical.com>
References: <4AE84C15.2020803@canonical.com>
Message-ID: <4AEE1437.3080104@canonical.com>

John Johansen wrote:
> There is a new chroot path permission hook going upstream so now is a very good
> time to reevaluate how AppArmor deals with chroots.
> 
I have been working on chroot documentation so here are a few more ideas to
throw out.

Currently the combination of AppArmor and chroots is a real pita, as the same
set of profiles gets applied both inside and outside the chroot.  Generally the
outside of chroot profiles won't be applied because of the chroot path being
prepended to executable names.
  so you need two profiles, eg.
  /bin/foo
  /var/chroot/bin/foo

But this makes reusing profiles and keeping them up to date difficult, and
messes up the namespace with two or more sets of profiles.

Currently the chroot profiles can be manually placed in another namespace and
entered using the change_profile API.  There is no automated way to do this yet.
Also once in the chroot+namespace the profiles loaded don't automatically apply
to the namespaces profiles set.

I would like to make this whole process more transparent.  This can be done in a
couple ways.

1. Providing an attachment specification for chroots.
  This would apply to unconfined processes, where the chroot rule would apply to
confined, similar to how profile names and x rules are currently applied.

When an unconfined process does a chroot, it is considered for a namespace
transition.

This could be done when defining a namespace or on a profile to be considered
for attachment.
Currently AppArmor does directly define namespaces and relies on them being
defined as part of the profile, but this could be updated for namespace
directories or we could just do it for the default namespace profile.  Which
would either be
  :<namespace>:/** { }  or  :<namespace>:unconfined { }

2. Making namespaces hierarchical
  So that when a process is in a namespace, profile loads are applied to that
namespace and if a new namespace is defined in that namespace it is added within
that namespace only.

Also reporting of profiles and namespaces should be senstative to the namespace
they are in.

3. On the tool side, they need to become aware of namespaces, and namespace
directories and do what ever is required to automatically make a profile valid
for the namespace, be prepending chroot paths or what ever else is required.

In general I would like to be able to set up namespace directories and have
symlinks out of the directory to share profiles.
  eg.
    /etc/apparmor.d/usr.bin.foo
    /etc/apparmor.d/ns_example/usr.bin.foo -> /etc/apparmor.d/usr.bin.foo

john