SDL support broken when using apparmor

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

$ 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.

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

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.

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.

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

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

/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?

@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.

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

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.

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

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! :-)

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

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.

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.

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