Description of problem: While attempting to work around bug #517304, I had adjusted /etc/libvirt/qemu.conf so that qemu runs as root:root and restarted libvirtd. When creating a new guest I got AVC messages and an error dialog: ==> Unable to complete install '<class 'libvirt.libvirtError'> internal error unable to start guest: bind(unix:/var/run/libvirt/qemu/F11.monitor): Permission denied qemu: could not open monitor device 'unix:/var/run/libvirt/qemu/F11.monitor,server,nowait' Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/create.py", line 1489, in do_install dom = guest.start_install(False, meter = meter) File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line 628, in start_install return self._do_install(consolecb, meter, removeOld, wait) File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line 726, in _do_install self.domain = self.conn.createLinux(install_xml, 0) File "/usr/lib64/python2.6/site-packages/libvirt.py", line 1077, in createLinux if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self) libvirtError: internal error unable to start guest: bind(unix:/var/run/libvirt/qemu/F11.monitor): Permission denied qemu: could not open monitor device 'unix:/var/run/libvirt/qemu/F11.monitor,server,nowait' ' <== ==> node=worm.elk type=AVC msg=audit(1250326486.552:31325): avc: denied { transition } for pid=3571 comm="libvirtd" path="/usr/bin/qemu-kvm" dev=dm-1 ino=105692 scontext=unconfined_u:system_r:virtd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:svirt_t:s0:c224,c1013 tclass=process node=worm.elk type=SYSCALL msg=audit(1250326486.552:31325): arch=c000003e syscall=59 success=yes exit=0 a0=7fb08800b6c0 a1=7fb088007330 a2=7fb08800b560 a3=7fb09c815e30 items=0 ppid=3570 pid=3571 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="qemu-kvm" exe="/usr/bin/qemu-kvm" subj=system_u:system_r:svirt_t:s0:c224,c1013 key=(null) <== Version-Release number of selected component (if applicable): libvirt-0.7.0-4.fc12.x86_64 selinux-policy-targeted-3.6.26-11.fc12.noarch qemu-0.10.91-0.5.rc1.fc12.x86_64 How reproducible: 100% Steps to Reproduce: 1.Attempt to create guest while libvirt runs qemu as root:root.
Actually even with the default qemu.conf I get these same AVC messages. The boot screen appears but it fails to read the boot disk (a qemu:qemu owned file with virt_content_t label).
Okay, here's what I can reproduce: 1) change /etc/libvirt/qemu.conf to user=root/group=root and restart libvirtd now guests fail to start with the "could not open monitor device" error because the qemu process is failing to transition to svirt_t as the AVC shows 2) change it back to user=qemu/group=qemu and restart libvirtd now guests appear to work fine, the process is running as qemu and transitioning correctly, but the AVCs still appear when starting a guest 4) leave it as user=qemu/group=qemu and reboot now everything is fine again with no AVCs
I think the confusion here is because it is not sufficient to merely change the user/group to root/root in the config file. The directory permissions will not allow QEMU to create its monitor socket, since even with the user set to root/root, the QEMU instance is still unprivileged, so can only access files which are explicitly owned by root. ie it lacks CAP_DAC_OVERRIDE. So you'd also need to at least chown /var/run/libvirt/qemu to root:root IIRC. I cant explain the failure to transition SElinux domains though - that shouldn't be at all related to the QEMU process' UID/GID. We certainly need to document this better - the config file is misleading in suggesting you can simply change the user/group and nothing else
dwalsh: any idea what's causing the transition AVCs ?
Confirm that chowning the dirs to root:root is enough to make things work (modulo these weird transition AVCs) We're going to make libvirtd do this chowning automatically, see: http://www.redhat.com/archives/libvir-list/2009-August/msg00402.html
I recently changed all unconfined_domains to permissive domains to see what AVC's are around if you removed the unconfined policy package. In Fedora 11 libvirt is running as an unconfined_domain. If you look closely at the AVC, you will see success=yes, which means the kernel did not block anything. Setroubleshoot should tell you this. The AVC is because you have unconfined_u:system_r:virtd_t:s0-s0;c0.c1023 system_u:system_r:svirt_t:s0:c224,c1013 So the problem is a missing rule to allow libvirt to change the user of a process it is executing. Theoretically libvirt should have only changed the type and MLS/MCS portion of the context, But since it changed the user component I also need to allow this in policy. Fixed in selinux-policy-3.6.28-2.fc12.noarch
Thanks dwalsh That just leaves the dir chowning issue
Created attachment 358599 [details] Fix chowning of directories This patch addresses several problems - If chown's the /var/{lib,cache}/libvirt/qemu directories to match the configured qemu user/group - It sets /var/run/libvirt/qemu to always be root:root, since that contains security critical data that should not be writable by the guest - It moves the monitor socket out of /var/run and into /var/lib due to previous point - Fixes memory leak of monitor device data - Removes the monitor device at shutdown
Split up and posted upstream http://www.redhat.com/archives/libvir-list/2009-August/msg00482.html
We now correctly chown directories and this is in rawhide http://libvirt.org/git/?p=libvirt.git;a=commit;h=2a6825c393157fe476763565e94451bf78ccca8f