Documentation and examples for SVirt Apparmor driver

* docs/drvqemu.html.in: include documentation for AppArmor sVirt
  confinement
* examples/apparmor/TEMPLATE examples/apparmor/libvirt-qemu
  examples/apparmor/usr.lib.libvirt.virt-aa-helper
  examples/apparmor/usr.sbin.libvirtd: example templates and
  configuration files for SVirt Apparmor when using KVM/QEmu
This commit is contained in:
Jamie Strandboge 2009-10-08 16:42:05 +02:00 committed by Daniel Veillard
parent bbaecd6a8f
commit 624a7927f0
5 changed files with 217 additions and 0 deletions

View File

@ -296,6 +296,73 @@
file can be used to change the setting to <code>security_driver="none"</code>
</p>
<h3><a name="securitysvirtaa">AppArmor sVirt confinement</a></h3>
<p>
When using basic AppArmor protection for the libvirtd daemon and
QEMU virtual machines, the intention is to protect the host OS
from a compromised virtual machine process. There is no protection
between guests.
</p>
<p>
The AppArmor sVirt protection for QEMU virtual machines builds on
this basic level of protection, to also allow individual guests to
be protected from each other.
</p>
<p>
In the sVirt model, if a profile is loaded for the libvirtd daemon,
then each <code>qemu:///system</code> QEMU virtual machine will have
a profile created for it when the virtual machine is started if one
does not already exist. This generated profile uses a profile name
based on the UUID of the QEMU virtual machine and contains rules
allowing access to only the files it needs to run, such as its disks,
pid file and log files. Just before the QEMU virtual machine is
started, the libvirtd daemon will change into this unique profile,
preventing the QEMU process from accessing any file resources that
are present in another QEMU process or the host machine.
</p>
<p>
The AppArmor sVirt implementation is flexible in that it allows an
administrator to customize the template file in
<code>/etc/apparmor.d/libvirt/TEMPLATE</code> for site-specific
access for all newly created QEMU virtual machines. Also, when a new
profile is generated, two files are created:
<code>/etc/apparmor.d/libvirt/libvirt-&lt;uuid&gt;</code> and
<code>/etc/apparmor.d/libvirt/libvirt-&lt;uuid&gt;.files</code>. The
former can be fine-tuned by the administrator to allow custom access
for this particular QEMU virtual machine, and the latter will be
updated appropriately when required file access changes, such as when
a disk is added. This flexibility allows for situations such as
having one virtual machine in complain mode with all others in
enforce mode.
</p>
<p>
While users can define their own AppArmor profile scheme, a typical
configuration will include a profile for <code>/usr/sbin/libvirtd</code>,
<code>/usr/lib/libvirt/virt-aa-helper</code> (a helper program which the
libvirtd daemon uses instead of manipulating AppArmor directly), and
an abstraction to be included by <code>/etc/apparmor.d/libvirt/TEMPLATE</code>
(typically <code>/etc/apparmor.d/abstractions/libvirt-qemu</code>).
An example profile scheme can be found in the examples/apparmor
directory of the source distribution.
</p>
<p>
If the sVirt security model is active, then the node capabilities
XML will include its details. If a virtual machine is currently
protected by the security model, then the guest XML will include
its assigned profile name. If enabled at compile time, the sVirt
security model will be activated if AppArmor is available on the host
OS and a profile for the libvirtd daemon is loaded when libvirtd is
started. To disable sVirt, and revert to the basic level of AppArmor
protection (host protection only), the <code>/etc/libvirt/qemu.conf</code>
file can be used to change the setting to <code>security_driver="none"</code>.
</p>
<h3><a name="securityacl">Cgroups device ACLs</a></h3>

View File

@ -0,0 +1,9 @@
#
# This profile is for the domain whose UUID matches this file.
#
#include <tunables/global>
profile LIBVIRT_TEMPLATE {
#include <abstractions/libvirt-qemu>
}

View File

@ -0,0 +1,71 @@
# Last Modified: Wed Jul 8 09:57:41 2009
#include <abstractions/base>
#include <abstractions/consoles>
#include <abstractions/nameservice>
# required for reading disk images
capability dac_override,
capability dac_read_search,
capability chown,
network inet stream,
network inet6 stream,
/dev/net/tun rw,
/dev/kvm rw,
/dev/ptmx rw,
/dev/kqemu rw,
# WARNING: uncommenting these gives the guest direct access to host hardware.
# This is required for USB pass through but is a security risk. You have been
# warned.
#/sys/bus/usb/devices/ r,
#/sys/devices/*/*/usb[0-9]*/** r,
#/dev/bus/usb/*/[0-9]* rw,
/usr/share/kvm/** r,
/usr/share/qemu/** r,
/usr/share/bochs/** r,
/usr/share/openbios/** r,
/usr/share/openhackware/** r,
/usr/share/proll/** r,
/usr/share/vgabios/** r,
# the various binaries
/usr/bin/kvm rmix,
/usr/bin/qemu rmix,
/usr/bin/qemu-system-arm rmix,
/usr/bin/qemu-system-cris rmix,
/usr/bin/qemu-system-i386 rmix,
/usr/bin/qemu-system-m68k rmix,
/usr/bin/qemu-system-mips rmix,
/usr/bin/qemu-system-mips64 rmix,
/usr/bin/qemu-system-mips64el rmix,
/usr/bin/qemu-system-mipsel rmix,
/usr/bin/qemu-system-ppc rmix,
/usr/bin/qemu-system-ppc64 rmix,
/usr/bin/qemu-system-ppcemb rmix,
/usr/bin/qemu-system-sh4 rmix,
/usr/bin/qemu-system-sh4eb rmix,
/usr/bin/qemu-system-sparc rmix,
/usr/bin/qemu-system-sparc64 rmix,
/usr/bin/qemu-system-x86_64 rmix,
/usr/bin/qemu-alpha rmix,
/usr/bin/qemu-arm rmix,
/usr/bin/qemu-armeb rmix,
/usr/bin/qemu-cris rmix,
/usr/bin/qemu-i386 rmix,
/usr/bin/qemu-m68k rmix,
/usr/bin/qemu-mips rmix,
/usr/bin/qemu-mipsel rmix,
/usr/bin/qemu-ppc rmix,
/usr/bin/qemu-ppc64 rmix,
/usr/bin/qemu-ppc64abi32 rmix,
/usr/bin/qemu-sh4 rmix,
/usr/bin/qemu-sh4eb rmix,
/usr/bin/qemu-sparc rmix,
/usr/bin/qemu-sparc64 rmix,
/usr/bin/qemu-sparc32plus rmix,
/usr/bin/qemu-sparc64 rmix,
/usr/bin/qemu-x86_64 rmix,

View File

@ -0,0 +1,22 @@
# Last Modified: Mon Jul 06 17:22:37 2009
#include <tunables/global>
/usr/lib/libvirt/virt-aa-helper {
#include <abstractions/base>
# needed for searching directories
capability dac_override,
capability dac_read_search,
# needed for when disk is on a network filesystem
network inet,
deny @{PROC}/[0-9]*/mounts r,
@{PROC}/filesystems r,
/usr/lib/libvirt/virt-aa-helper mr,
/sbin/apparmor_parser Ux,
/etc/apparmor.d/libvirt/* r,
/etc/apparmor.d/libvirt/libvirt-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]* rw,
}

View File

@ -0,0 +1,48 @@
# Last Modified: Wed Sep 23 23:23:58 2009
#include <tunables/global>
@{LIBVIRT}="libvirt"
/usr/sbin/libvirtd {
#include <abstractions/base>
capability kill,
capability net_admin,
capability net_raw,
capability setgid,
capability sys_admin,
capability sys_module,
capability sys_ptrace,
capability sys_nice,
capability sys_chroot,
capability setuid,
capability dac_override,
capability dac_read_search,
capability fowner,
capability chown,
capability setpcap,
capability mknod,
network inet stream,
# Very lenient profile for libvirtd since we want to first focus on confining
# the guests. Guests will have a very restricted profile.
/** rwmkl,
/bin/* Ux,
/sbin/* Ux,
/usr/bin/* Ux,
/usr/sbin/* Ux,
# force the use of virt-aa-helper
audit deny /sbin/apparmor_parser rwxl,
audit deny /etc/apparmor.d/libvirt/** wxl,
audit deny /sys/kernel/security/apparmor/features rwxl,
audit deny /sys/kernel/security/apparmor/matching rwxl,
audit deny /sys/kernel/security/apparmor/.* rwxl,
/sys/kernel/security/apparmor/profiles r,
/usr/lib/libvirt/virt-aa-helper Pxr,
# allow changing to our UUID-based named profiles
change_profile -> @{LIBVIRT}-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*,
}