SDL support broken when using apparmor

[Ancoron Luziferis]

Although SDL works perfectly with QEMU/KVM itself the appropriate support using libvirt is completely broken.

System info:

$ lsb_release -rd
Description: Ubuntu lucid (development branch)
Release: 10.04

$ uname -a
Linux workstation 2.6.32-16-generic #25-Ubuntu SMP Tue Mar 9 16:33:12 UTC 2010 x86_64 GNU/Linux

$ apt-cache policy libvirt0
libvirt0:
  Installed: 0.7.5-5ubuntu13
  Candidate: 0.7.5-5ubuntu13
  Version table:
 *** 0.7.5-5ubuntu13 0
        500 http://de.archive.ubuntu.com/ubuntu/ lucid/main Packages
        100 /var/lib/dpkg/status

Example domain XML excerpt:

$ virsh -c qemu:///system dumpxml aria | grep graphics
    <graphics type='sdl' display=':0.0' xauth='/home/myself/.Xauthority'/>

...virsh invocation:

$ sudo virsh -c qemu:///system start aria
error: Failed to start domain aria
error: monitor socket did not show up.: Connection refused

Contents of /var/log/libvirt/qemu/aria.log:

LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin XAUTHORITY=/home/myself/.Xauthority DISPLAY=:0.0 /usr/bin/kvm -S -M pc-0.12 -enable-kvm -m 2048 -smp 4 -name aria -uuid a4294a0d-a75a-a377-ddcd-7e35d5720815 -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/aria.monitor,server,nowait -monitor chardev:monitor -localtime -boot c -drive file=/srv/virtual/aria-win2k3.img,if=ide,index=0,boot=on,format=raw -drive file=/srv/virtual/win2003-x64.iso,if=ide,media=cdrom,index=2,format=raw -net nic,macaddr=52:54:00:76:e9:1d,vlan=0,name=nic.0 -net tap,fd=49,vlan=0,name=tap.0 -chardev pty,id=serial0 -serial chardev:serial0 -parallel none -usb -usbdevice tablet -vga std
char device redirected to /dev/pts/7
pci_add_option_rom: failed to find romfile "pxe-rtl8139.bin"
No protocol specified
No protocol specified

   ~~~~~~~~~~~~~~~~~~~~~~~~~~| DirectFB 1.2.8 |~~~~~~~~~~~~~~~~~~~~~~~~~~
        (c) 2001-2008 The world wide DirectFB Open Source Community
        (c) 2000-2004 Convergence (integrated media) GmbH
      ----------------------------------------------------------------

(*) DirectFB/Core: Single Application Core. (2010-02-03 18:27)
(*) Direct/Memcpy: Using libc memcpy()
(!) Direct/Util: opening '/dev/fb0' failed
    --> Permission denied
(!) DirectFB/FBDev: Error opening framebuffer device!
(!) DirectFB/FBDev: Use 'fbdev' option or set FRAMEBUFFER environment variable.
(!) DirectFB/Core: Could not initialize 'system_core' core!
    --> Initialization error!
Could not initialize SDL - exiting

Taking that logged command-line and executing it in a terminal works perfectly (at least the X window shows up and without parameter "-S" the VM boots fine).

[Jamie Strandboge (jdstrand)]

Can you please attach the output of the following command:
$ dmesg | grep audit

[Ancoron Luziferis (ancoron)]

$ dmesg | grep audit
[ 6046.037322] type=1505 audit(1269377190.495:54): operation="profile_load" pid=17852 name="libvirt-a4294a0d-a75a-a377-ddcd-7e35d5720815"
[ 6046.144800] type=1503 audit(1269377190.606:55): operation="open" pid=17858 parent=1 profile="libvirt-a4294a0d-a75a-a377-ddcd-7e35d5720815" requested_mask="::r" denied_mask="::r" fsuid=0 ouid=1000 name="/home/myself/.Xauthority"
[ 6046.145062] type=1503 audit(1269377190.606:56): operation="open" pid=17858 parent=1 profile="libvirt-a4294a0d-a75a-a377-ddcd-7e35d5720815" requested_mask="::r" denied_mask="::r" fsuid=0 ouid=1000 name="/home/myself/.Xauthority"
[ 6046.145147] type=1503 audit(1269377190.606:57): operation="open" pid=17858 parent=1 profile="libvirt-a4294a0d-a75a-a377-ddcd-7e35d5720815" requested_mask="rw::" denied_mask="rw::" fsuid=0 ouid=0 name="/dev/fb0"
[ 6046.145190] type=1503 audit(1269377190.606:58): operation="open" pid=17858 parent=1 profile="libvirt-a4294a0d-a75a-a377-ddcd-7e35d5720815" requested_mask="r::" denied_mask="r::" fsuid=0 ouid=0 name="/proc/17858/cmdline"
[ 6046.147198] type=1503 audit(1269377190.606:59): operation="open" pid=17858 parent=1 profile="libvirt-a4294a0d-a75a-a377-ddcd-7e35d5720815" requested_mask="rw::" denied_mask="rw::" fsuid=0 ouid=0 name="/dev/fb0"
[ 6076.374039] type=1505 audit(1269377220.835:60): operation="profile_remove" pid=18209 name="libvirt-a4294a0d-a75a-a377-ddcd-7e35d5720815" namespace="root"

So the first step would be to add the xauth="XXX" path to the domains profile definition. And additionally /dev/fb* for DirectFB fallback, if no X environment is available.

[Ancoron Luziferis (ancoron)]

There's also a bug upstream that looks related (although with SELinux): https://bugzilla.redhat.com/show_bug.cgi?id=536693

[Jamie Strandboge (jdstrand)]

I'm uncomfortable adding the /dev/fb* rule by default, but can add it to the profile in a commented fashion. While I can reproduce the apparmor denied errors for ~/.Xauthority, the VM starts up. I guess you are trying to start the VM without an X session?

Another alternative to adding '/dev/fb* rw' and '@{HOME}/.Xauthority' to the profile is to add these rules only when sdl is in use. This is probably the proper fix.

[Ancoron Luziferis (ancoron)]

Regarding the /dev/fb* rule: me too!

We wouldn't need that as long as KVM wouldn't choose the DirectFB fallback. It seems that the X-stuff required for KVM doesn't get set up correctly by libvirt.

I already thought of just adding the rules if required. But this would mean another patch for .../src/security/virt-aa-helper.c to update the domain specific profile.

[Ancoron Luziferis (ancoron)]

No, I'm not starting without an X session.

But it seems to me that libvirt isn't X-session aware at all.

[Marc Deslauriers (mdeslaur)]

/dev/fb* probably shouldn't be in the apparmor profile. I don't think setting up a graphical VM interface on a server without X is appropriate.

@Ancoron: What graphical environment are you using? If you do "sudo gedit", does gedit display on your screen?

[Ancoron Luziferis (ancoron)]

@Marc: please, let us not think for others. If someone has a reason to do so it should be completely up to him/her.

I'm using KDE4 currently, and yes, running anything with sudo inside a terminal does get it displayed on the screen just like expected. Also I can run the KVM command line directly on the terminal with sudo and SDL gets set up correctly.

[Marc Deslauriers (mdeslaur)]

Could you please attach your /etc/libvirt/qemu.conf and /etc/libvirt/libvirtd.conf files?

[Jamie Strandboge (jdstrand)]

Uploaded 0.7.5-5ubuntu18. This adjusts virt-aa-helper to add the xauth path and a comment in libvirt-qemu for access to /dev/fb*. Upload just needs to be approved.

[Steve Langasek (vorlon)]

libvirt 0.7.5-5ubuntu21 is accepted into lucid, but some of the intermediate versions were bounced out of the queue for simplicity's sake - so this didn't get autoclosed. Changelog entry:

libvirt (0.7.5-5ubuntu18) lucid; urgency=low

  * handle SDL graphics (LP: #545426). This can be dropped in 0.7.8
    - 9019-apparmor-fix-xauth.patch: adjust virt-aa-helper to handle SDL
      graphics, specifically Xauthority. Also remove a couple redundant
      checks.
    - debian/apparmor/libvirt-qemu: add comment about /dev/fb*
  * handle backingstore (LP: #470636). This can be dropped in 0.7.8
    - debian/patches/9020-apparmor-fix-backingstore.patch: adjust
      virt-aa-helper to handle disks with backing stores
    - debian/apparmor/usr.lib.libvirt.virt-aa-helper: allow access to
      user-tmp, non-hidden files in @{HOME} and storage pools

 -- Jamie Strandboge <email address hidden> Mon, 05 Apr 2010 16:56:25 -0500

[Ancoron Luziferis (ancoron)]

Just tested it with kernel 2.6.32-20-generic (amd64) and libvirt0 0.7.5-5ubuntu21.

$ sudo virsh -c qemu:///system define /srv/virtual/aria.xml
Domain aria defined from /srv/virtual/aria.xml

$ sudo virsh -c qemu:///system start aria
error: Failed to start domain aria
error: internal error unable to start guest: libvir: Security Labeling error : error calling aa_change_profile()

[ 1445.385111] type=1503 audit(1271092691.039:30): operation="open" pid=4883 parent=1224 profile="/usr/lib/libvirt/virt-aa-helper" requested_mask="r::" denied_mask="r::" fsuid=0 ouid=0 name="/srv/virtual/aria-win2k3.img"
[ 1445.385453] type=1503 audit(1271092691.039:31): operation="open" pid=4883 parent=1224 profile="/usr/lib/libvirt/virt-aa-helper" requested_mask="r::" denied_mask="r::" fsuid=0 ouid=0 name="/srv/virtual/win2003-x64.iso"
[ 1445.407237] device vnet0 entered promiscuous mode
[ 1445.408771] virbr0: topology change detected, propagating
[ 1445.408780] virbr0: port 1(vnet0) entering forwarding state
[ 1445.453859] virbr0: port 1(vnet0) entering disabled state
[ 1445.482558] device vnet0 left promiscuous mode
[ 1445.482568] virbr0: port 1(vnet0) entering disabled state
[ 1445.608828] type=1505 audit(1271092691.259:32): operation="profile_remove" info="profile does not exist" error=-2 pid=4898 name="libvirt-a4294a0d-a75a-a377-ddcd-7e35d5720815" namespace="root"

The mentioned profile doesn't get loaded (libvirt-a4294a0d-a75a-a377-ddcd-7e35d5720815) although it exists:

$ ls -1 /etc/apparmor.d/libvirt/libvirt-a4294a0d-a75a-a377-ddcd-7e35d5720815*
/etc/apparmor.d/libvirt/libvirt-a4294a0d-a75a-a377-ddcd-7e35d5720815
/etc/apparmor.d/libvirt/libvirt-a4294a0d-a75a-a377-ddcd-7e35d5720815.files

...and has appropriate lines in it:

$ grep '/srv/virtual/' /etc/apparmor.d/libvirt/libvirt-a4294a0d-a75a-a377-ddcd-7e35d5720815.files
  "/srv/virtual/aria-win2k3.img" rw,
  "/srv/virtual/win2003-x64.iso" r,
  deny "/srv/virtual/win2003-x64.iso" w,

So I just added appropriate lines into "/etc/apparmor.d/usr.lib.libvirt.virt-aa-helper" for my custom storage pool (should I open a bug for that?):

$ grep '/srv/virtual' /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper
  /srv/virtual/ r,
  /srv/virtual/** r,

...reloaded the apparmor service and now it works. Now I'm waiting for a resolution to Bug #513273 to finally get an SDL VM running out of the virt-manager.

Thanx a lot so far! Fix confirmed! :-)

[Jamie Strandboge (jdstrand)]

Ancoron, I'm going to add read access to /mnt, /media and /srv vir virt-aa-helper.

[Ancoron Luziferis (ancoron)]

Well, to be correct we should read the domain configuration as well as the storage pool definitions to correctly set up apparmor rules (just open them as required and by demand, not by foresight).

Additionally what if someone decides to have an iscsi mounted filesystem on /opt or using some NFS storage on /net? Even /var/local or some complete custom paths are possible. So opening read access to all those things just vanishes the benefit of using apparmor.

Call me paranoid but I think such a quick hack is not appropriate here, also it is for an LTS release that gets used on servers where security is of top level priority.

[Jamie Strandboge (jdstrand)]

Ancoron, this isn't a 'quick hack'. The /mnt, /media and /srv read permissions are for virt-aa-helper, not the virtual machines. virt-aa-helper is used by the libvirtd daemon to dynamically update the profiles for individual VM definitions, and uses the libvirt API extensively. While virt-aa-helper itself has an AppArmor profile, it is mostly just to make sure that it can't execute other programs or write to anywhere other than /etc/apparmor.d/libvirt. The profile needs to allow reading of ISOs and VM disk images (so it can check for backing store via the libvirt API), and so (limited) read access to the standard storage pool location, $HOME and removable media and filesystems is given. Not including /srv, /mnt and /media was an oversight. If an administrator saves files in other locations, he/she is expected to update the AppArmor profile accordingly.

For more on how the AppArmor security driver for libvirt works, please see /usr/share/doc/libvirt-bin/README.Debian.gz.

[Ancoron Luziferis (ancoron)]

Oh well, I see. Sorry I misunderstood some things here.