Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 790526 - qemu-system-arm denied execmem when run through libvirt
Summary: qemu-system-arm denied execmem when run through libvirt
Keywords:
Status: CLOSED DUPLICATE of bug 885837
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: 17
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: ARMTracker
TreeView+ depends on / blocked
 
Reported: 2012-02-14 18:47 UTC by Garrett Holmstrom
Modified: 2012-12-16 23:39 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-12-16 23:39:08 UTC
Type: ---
Embargoed:

Attachments (Terms of Use)

Description Garrett Holmstrom 2012-02-14 18:47:33 UTC 
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
Comment 1 Stefan Becker 2012-03-23 16:28:49 UTC 
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?
Comment 2 Daniel Walsh 2012-03-27 19:48:24 UTC 
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
Comment 3 Daniel Walsh 2012-03-27 19:51:23 UTC 
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.
Comment 4 Stefan Becker 2012-03-28 05:20:19 UTC 
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.
Comment 6 Cole Robinson 2012-12-16 23:39:08 UTC 
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 ***
Note You need to log in before you can comment on or make changes to this bug.