[apparmor] KVM + AppArmor

Jeroen Ooms jeroen.ooms at stat.ucla.edu
Mon Feb 27 08:20:33 UTC 2012

Hi John,

Thank you for your elaborate answer. An additional problem I would like to
avoid which am experiencing on slicehost is that the version of the kernel
is incompatible with the version of apparmor on the guest. I am running
Ubuntu 11.10 on the guest, but the kernel that I am getting is old and I
can't update is :-/ Looks like they're using Xen:

jeroen at opencpu-beta2:~$ uname -a
Linux opencpu-beta2 #8 SMP Mon Sep 20 15:54:33 UTC 2010
x86_64 x86_64 x86_64 GNU/Linux

jeroen at opencpu-beta2:~$ dmesg | grep -i xen
[    0.000000] Command line: root=/dev/sda1 ro xencons=tty console=tty1
[    0.000000]  Xen: 0000000000000000 - 00000000000a0000 (usable)
[    0.000000]  Xen: 00000000000a0000 - 0000000000100000 (reserved)
[    0.000000]  Xen: 0000000000100000 - 0000000020000000 (usable)
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 3.3.0 (preserve-AD)
[    0.000000] Xen: using vcpu_info placement
[    0.000000] Kernel command line: root=/dev/sda1 ro xencons=tty
console=tty1 clocksource=acpi_pm
[    0.000000]   #1 [00025e2000 - 00025f9000]  XEN PAGETABLES
[    0.000000]   #4 [00024df000 - 00025e2000]  XEN START INFO
[    0.000000] Xen: using vcpuop timer interface
[    0.000000] installing Xen timer for CPU 0
[    0.030297] installing Xen timer for CPU 1
[    0.054663] installing Xen timer for CPU 2
[    0.054883] installing Xen timer for CPU 3
[    0.060178] xen_balloon: Initialising balloon driver.
[    0.070325] Switching to clocksource xen
[    0.151720] Initialising Xen virtual ethernet driver.
[    0.280072] XENBUS: Device with no driver: device/console/0

On Sun, Feb 26, 2012 at 7:20 PM, John Johansen
<john.johansen at canonical.com>wrote:

> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20120227/a1b6308b/attachment-0001.html>

More information about the AppArmor mailing list