[apparmor] KVM + AppArmor
jeroen.ooms at stat.ucla.edu
Mon Feb 27 08:20:33 UTC 2012
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 188.8.131.52-rscloud #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
[ 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...
More information about the AppArmor