Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 598533 - selinux denies qemu access to monitor and vmchannel sockets
Summary: selinux denies qemu access to monitor and vmchannel sockets
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: vdsm
Version: 6.0
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Dan Kenigsberg
QA Contact:
URL:
Whiteboard:
Depends On: 601249
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-06-01 15:14 UTC by Dan Kenigsberg
Modified: 2011-12-06 06:57 UTC (History)
8 users (show)

Fixed In Version: vdsm-4.9-8.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-06 06:57:58 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2011:1782 normal SHIPPED_LIVE new packages: vdsm 2011-12-06 11:55:51 UTC

Description Dan Kenigsberg 2010-06-01 15:14:31 UTC
Description of problem:
With enforcing selinux, qemu fails to start with

internal error process exited while connecting to monitor: bind(unix:/var/lib/libvirt/qemu/barak-xp.monitor): Permission denied

/var/log/audit/audit.log has

type=AVC msg=audit(1275404944.816:21610): avc:  denied  { write } for  pid=18065 comm="qemu-kvm" name="qemu" dev=dm-0 ino=1966544 scontext=unconfined_u:system_r:qemu_t:s0-s0:c0.c1023 tcontext=system_u:object_r:svirt_var_run_t:s0 tclass=dir
type=AVC msg=audit(1275404944.816:21610): avc:  denied  { add_name } for  pid=18065 comm="qemu-kvm" name="barak-xp.monitor" scontext=unconfined_u:system_r:qemu_t:s0-s0:c0.c1023 tcontext=system_u:object_r:svirt_var_run_t:s0 tclass=dir
type=AVC msg=audit(1275404944.816:21610): avc:  denied  { create } for  pid=18065 comm="qemu-kvm" name="barak-xp.monitor" scontext=unconfined_u:system_r:qemu_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:svirt_var_run_t:s0 tclass=sock_file

`echo 0 > /selinux/enforce` "solved" the problem for me.

Version-Release number of selected component (if applicable):
libvirt-0.8.1-7

libvirt-0.8.1-7.el6.x86_64
qemu-kvm-0.12.1.2-2.68.el6.x86_64
selinux-policy-3.7.17-5.el6.noarch
selinux-policy-targeted-3.7.17-5.el6.noarch


How reproducible:
Seen on a fresh new installation of RHEL6.

Comment 1 RHEL Product and Program Management 2010-06-01 15:15:57 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Comment 2 Daniel Berrange 2010-06-01 16:12:48 UTC
When the SELinux is running in permissive mode, and the VM is running, can you show me

# ls -alZ /var/lib/libvirt/qemu/

And

# ps -axuwfZ | grep qemu-kvm

Comment 3 Dan Kenigsberg 2010-06-01 16:33:23 UTC
# ls -alZ /var/lib/libvirt/qemu/
drwxrwxrwx. vdsm kvm  system_u:object_r:svirt_var_run_t:s0 .
drwxr-xr-x. root root system_u:object_r:virt_var_lib_t:s0 ..
srwxr-xr-x. vdsm kvm  unconfined_u:object_r:svirt_var_run_t:s0 barak-xp.monitor
drwxr-xr-x. vdsm kvm  system_u:object_r:svirt_var_run_t:s0 save
drwxr-xr-x. vdsm kvm  system_u:object_r:svirt_var_run_t:s0 snapshot

# ps axuwfZ | grep qemu
unconfined_u:system_r:qemu_t:s0-s0:c0.c1023 vdsm 18065 10.4 17.3 2562664 2120728 ? Sl 18:09   8:43 /usr/libexec/qemu-kvm -S -M rhel6.0.0 -cpu qemu64,-svm,-nx -enable-kvm -m 2048 -smp 1,sockets=1,cores=1,threads=1 -name barak-xp -uuid 09abc572-d080-442e-a139-f70a817302b7 -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/barak-xp.monitor,server,nowait -mon chardev=monitor,mode=control -rtc base=2010-5-1T18:9:4 -boot cn -device virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x5 -drive file=/rhev/data-center/606d043c-ef9c-4c6f-848b-5bd89325c78d/d58d83c5-5008-4906-9c44-bb9915428327/images/056480d6-ea9a-4ee9-a678-d39f7a9713a3/0c936f3f-7d2e-4002-a136-3dd95408950d,if=none,id=drive-ide0-0-0,boot=on,format=qcow2,serial=e9-a678-d39f7a9713a3,cache=none -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,fd=20,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:23:71:0c,bus=pci.0,addr=0x4 -chardev socket,id=channel0,path=/var/run/vdsm/09abc572-d080-442e-a139-f70a817302b7.guest.socket,server,nowait -device virtserialport,chardev=channel0,name=org.linux-kvm.port.0 -usb -spice port=5900,tls-port=5901,addr=0,x509-dir=/etc/pki/libvirt-spice,tls-channel=main,tls-channel=inputs -k en-us -vga qxl -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3

Comment 4 Daniel Berrange 2010-06-01 16:40:45 UTC
It looks like the labelling on your /var/lib/libvirt/qemu directory is incorrect. The policy defines it as system_u:object_r:qemu_var_run_t:s0, rather than svirt_var_run_t. Please update to at least

  selinux-policy-targeted-3.7.19-21.el6.noarch

And then

  touch /.autorelabel 

and reboot the whole machine. Hopefully that should fix your host labelling.

Comment 5 Dan Kenigsberg 2010-06-02 05:38:55 UTC
Thanks. upgrade and relabeling solves the monitor socket issue, but not that of

# ls -lZ /var/run/vdsm/9ffe28b6-6134-4b1e-8804-1185f49c436f.guest.socket
srwxr-xr-x. vdsm kvm system_u:object_r:var_run_t:s0   /var/run/vdsm/9ffe28b6-6134-4b1e-8804-1185f49c436f.guest.socket

generated due to the device

<controller index="0" ports="16" type="virtio-serial"/>
<channel type="unix">
    <target name="org.linux-kvm.port.0" type="virtio"/>
    <source mode="bind" path="/var/run/vdsm/9ffe28b6-6134-4b1e-8804-1185f49c436f.guest.socket"/>
</channel>

Comment 6 Daniel Berrange 2010-06-02 10:20:30 UTC
The VM channel has the same problem - '/var/run/vdsm' is not labeled with 'qemu_var_run_t', so QEMU will be unable to create the channel's UNIX socket in that location. Unfortunately UNIX sockets cannot be pre-created by libvirt, so we can't label them ahead of time, thus the only option is to make sure they're in a directory labelled 'qemu_var_run_t'.

I see 3 options

 1. Have VDSM deploy an addon selinux policy module that labels '/var/run/vdsm' as 'qemu_var_run_t'
 2. Have VSDM set the vmchannel path to /var/lib/libvirt/qemu/...something...
 3. Have VSDM set the vmchannel path to /var/lib/libvirt/qemu/channels/...something...

My recommendation is for option 3, and to use the VM name  + channel target as the filename, eg

  /var/lib/libvirt/qemu/channels/barak-xp.org.linux-kvm.port.0


libvirt uses & recommends VM name for all files, since it is just as unique as a UUID, and much more friendly for admins. The use of the channel target also to make it clear what the socket is for.

Comment 7 Dan Kenigsberg 2010-06-02 13:05:08 UTC
Ok, I'll try to take your suggestion 3.

I wish everyone was as elaborate and helpful as you are. Much better than the approach taken in bug 594068 comment 7.

Comment 9 Haim 2010-08-19 07:12:14 UTC
verified, however, there is one exception; as I configured 'virt_use_nfs'=on manually, though it should be configured by vdsm. 
with this change, I am able to run vm with selinux on both iscsi and nfs. 

checked audid.log and there was no AVC.

Comment 10 errata-xmlrpc 2011-12-06 06:57:58 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHEA-2011-1782.html


Note You need to log in before you can comment on or make changes to this bug.