Description of problem: Attempting to run a VM using libvirt that relies on qemu-system-arm for emulation results in an AVC denial: time->Tue Feb 14 10:36:43 2012 type=VIRT_RESOURCE msg=audit(1329244603.781:428): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=cgroup reason=allow vm="arm1" uuid=8028f71a-1db8-40a4-94fa-5a4a42014273 cgroup="/sys/fs/cgroup/devices/libvirt/qemu/arm1/" class=path path=/dev/kqemu rdev=? acl=rw: exe=2F7573722F7362696E2F6C69627669727464202864656C6574656429 hostname=? addr=? terminal=? res=failed' ---- time->Tue Feb 14 10:36:44 2012 type=VIRT_CONTROL msg=audit(1329244604.213:439): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu op=start reason=booted vm="arm1" uuid=8028f71a-1db8-40a4-94fa-5a4a42014273: exe=2F7573722F7362696E2F6C69627669727464202864656C6574656429 hostname=? addr=? terminal=? res=failed' ---- time->Tue Feb 14 10:36:43 2012 type=SYSCALL msg=audit(1329244603.892:433): arch=c000003e syscall=9 success=no exit=-13 a0=0 a1=2000000 a2=7 a3=62 items=0 ppid=1 pid=23119 auid=4294967295 uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=107 sgid=107 fsgid=107 tty=(none) ses=4294967295 comm="qemu-system-arm" exe="/usr/bin/qemu-system-arm" subj=system_u:system_r:svirt_t:s0:c50,c207 key=(null) type=AVC msg=audit(1329244603.892:433): avc: denied { execmem } for pid=23119 comm="qemu-system-arm" scontext=system_u:system_r:svirt_t:s0:c50,c207 tcontext=system_u:system_r:svirt_t:s0:c50,c207 tclass=process Version-Release number of selected component (if applicable): selinux-policy-3.10.0-75.fc16.noarch libvirt-0.9.6-4.fc16.x86_64 How reproducible: Always Steps to Reproduce: 1. Define a libvirt domain that uses /usr/bin/qemu-system-arm as its emulator 2. Attempt to start that domain Actual results: # virsh start arm1 error: Failed to start domain arm1 error: internal error process exited while connecting to monitor: Could not allocate dynamic translator buffer Expected results: # virsh start arm1 Domain arm1 started
Reproduced also under F17: qemu-system-arm-1.0-9.fc17.x86_64 selinux-policy-3.10.0-104.fc17.noarch selinux-policy-targeted-3.10.0-104.fc17.noarch Mar 23 18:22:50 stefanb-lnx kernel: [69217.595416] type=1400 audit(1332519770.482:36): avc: denied { execmem } for pid=25968 comm="qemu-system-arm" scontext=system_u:system_r:svirt_t:s0:c242,c604 tcontext=system_u:system_r:svirt_t:s0:c242,c604 tclass=process This seems to be the only thing needed to get this working. I don't see any other AVCs when I use "setenforce 0". Should this be fixed in the policy or should qemu-system-arm install a SELinux module?
No what we want here is libvirt to launch qemu that requires an execmem, to use a different label. Maybe we could add this to cat /etc/selinux/targeted/contexts/virtual_domain_context system_u:system_r:svirt_t:s0 system_u:system_r:svirt_execmem_t:s0 Or fix the format of this file to contain both labels. standard system_u:system_r:svirt_t:s0 execmem system_u:system_r:svirt_execmem_t:s0
Or we could being to label the qemu executables differently and have libvirt ask how to execute them We could write rules that says virtd_t executeing qemu_exec_t runs it as svirt_t, virtd_t executing qemu_execmem_exec_t executes it as svirt_exec_t. Then libvirt could ask the kernel what type it should execute qemu with. That way we could start to get real fancy with the policy and the virtd would not need to change in the future.
Tested on F17: - the default "deny_execmem --> off" allows users to run qemu_system_arm from the command line. - the default "virt_use_execmem --> off" prevents virt-manager/libvirt to run qemu_system_arm. After "setsebool virt_use_execmem on" ARM VMs run OK in virt-manager, i.e. you don't have to use "setenforce 0" as suggested by the Wiki page.
We have libvirt support for this, but backporting it isn't a clean backport to F17. Since there is a workaround with selinux booleans, I'm just gonna say this is WONTFIX for F17. Duping to the F18 bug *** This bug has been marked as a duplicate of bug 885837 ***