[apparmor] KVM + AppArmor
john.johansen at canonical.com
Mon Feb 27 03:20:52 UTC 2012
On 02/26/2012 03:27 PM, Seth Arnold wrote:
> AppArmor works exactly the same inside a KVM as outside -- there are no crazy kernel-sharing tricks ala OpenVZ so it looks just like booted on raw iron from AppArmor's perspective.
> I've used it both for testing debug versions of AppArmor as well as confining applications that required newer OS installs.
> There's even some clever work done via libvirt to provide confinement to the qemu _process_ that runs in the host, at least if you use the virt-manager tool. (Nice work there.)
I'll add another note to this. As Seth said full virtualization solutions just work with apparmor because they don't share the kernel. Container solutions (that share the kernel) like OpenVz, and lxc can also work with apparmor but it requires some setup that needs to be done manually.
Currently there is an either or situation where, either the system has policy or the container has policy.
For the system defining and enforcing policy on the container case
Define a profile(s), that apply to the container, and disallow capability mac_admin. This prevents the container from loading its own policy. The system policy, The policy setup by the system continues to be applied. If you wish to have a system policy set that applies to the individual applications within the container. That is have two different profiles for applications of the same name one in the container and one out (ie. /usr/bin/bind, etc.) Then you setup a Policy namespace and load the container policy into that, and change into it before starting the container (again if you want the container to not be able to load policy capability mac_admin must be denied, and this also applies to the unconfined case so that there needs to be a default profile /**, otherwise this is just the system preseeding the containers policy namespace).
For the container to have its own policy,
Define a new policy namespace without loading profiles (well you can preseed like above), and switch into it before starting the container. This allows the container to use the policy namespace as its own.
As You noted unless a policy namespace is used, the container technologies share the kernel and profiles, which can be problematic and confusing. There has been work on a third case
where both the system and container can have separate policies on the container (policy stacking) but this won't be available for another release or two and will still require that the container scripts setup a policy namespace for the container first.
More information about the AppArmor