Bug 684695

Summary: SELinux is preventing /usr/bin/qemu-kvm from 'ioctl' accesses on the chr_file /dev/bus/usb/001/007.
Product: [Fedora] Fedora Reporter: Artur Szymczak <artur.szymczak>
Component: libvirtAssignee: Libvirt Maintainers <libvirt-maint>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 14CC: ajschult, berrange, clalance, crobinso, dwalsh, itamar, jforbes, kayvansylvan, laine, mgrepl, veillard, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: setroubleshoot_trace_hash:57fe1cdde1ca8dec235ed98675b97e186e89a6b05c6193c757ec062b8d954d60
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-01-24 16:53:38 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Artur Szymczak 2011-03-14 05:11:17 EDT
SELinux is preventing /usr/bin/qemu-kvm from 'ioctl' accesses on the chr_file /dev/bus/usb/001/007.

*****  Plugin catchall (100. confidence) suggests  ***************************

If you believe that qemu-kvm should be allowed ioctl access on the 007 chr_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep qemu-kvm /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:svirt_t:s0:c112,c574
Target Context                system_u:object_r:usb_device_t:s0
Target Objects                /dev/bus/usb/001/007 [ chr_file ]
Source                        qemu-kvm
Source Path                   /usr/bin/qemu-kvm
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           qemu-system-x86-0.13.0-1.fc14
Target RPM Packages           
Policy RPM                    selinux-policy-3.9.7-31.fc14
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 2.6.35.11-83.fc14.x86_64
                              #1 SMP Mon Feb 7 07:06:44 UTC 2011 x86_64 x86_64
Alert Count                   4
First Seen                    Mon 14 Mar 2011 10:08:45 AM CET
Last Seen                     Mon 14 Mar 2011 10:09:12 AM CET
Local ID                      a5b0a0bf-2c82-4c99-bfba-b4f1e6c2957f

Raw Audit Messages
type=AVC msg=audit(1300093752.32:40): avc:  denied  { ioctl } for  pid=2409 comm="qemu-kvm" path="/dev/bus/usb/001/007" dev=devtmpfs ino=43988 scontext=system_u:system_r:svirt_t:s0:c112,c574 tcontext=system_u:object_r:usb_device_t:s0 tclass=chr_file


type=SYSCALL msg=audit(1300093752.32:40): arch=x86_64 syscall=ioctl success=no exit=EACCES a0=14 a1=5514 a2=2129c90 a3=1 items=0 ppid=1 pid=2409 auid=4294967295 uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=107 sgid=107 fsgid=107 tty=(none) ses=4294967295 comm=qemu-kvm exe=/usr/bin/qemu-kvm subj=system_u:system_r:svirt_t:s0:c112,c574 key=(null)

Hash: qemu-kvm,svirt_t,usb_device_t,chr_file,ioctl

audit2allow

#============= svirt_t ==============
allow svirt_t usb_device_t:chr_file ioctl;

audit2allow -R

#============= svirt_t ==============
allow svirt_t usb_device_t:chr_file ioctl;
Comment 1 Miroslav Grepl 2011-03-14 08:42:34 EDT
*** Bug 684697 has been marked as a duplicate of this bug. ***
Comment 2 Miroslav Grepl 2011-03-14 08:43:09 EDT
*** Bug 684696 has been marked as a duplicate of this bug. ***
Comment 3 Kayvan Sylvan 2011-06-27 23:21:30 EDT
This seems to be related to this message I see when trying to attach a USB device (iPhone) to my Windows XP guest:

setroubleshoot: SELinux is preventing /usr/sbin/usbmuxd from read access on the chr_file /dev/bus/usb/001/004. For complete SELinux messages. run sealert -l a95476b2-ff82-447c-8875-880eea17c8e6

From sealert:

SELinux is preventing /usr/sbin/usbmuxd from read access on the chr_file /dev/bus/usb/001/004.

*****  Plugin restorecon (99.5 confidence) suggests  *************************

If you want to fix the label. 
/dev/bus/usb/001/004 default label should be usb_device_t.
Then you can run restorecon.
Do
# /sbin/restorecon -v /dev/bus/usb/001/004

*****  Plugin catchall (1.49 confidence) suggests  ***************************

If you believe that usbmuxd should be allowed read access on the 004 chr_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep usbmuxd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:usbmuxd_t:s0-s0:c0.c1023
Target Context                system_u:object_r:svirt_image_t:s0:c154,c991
Target Objects                /dev/bus/usb/001/004 [ chr_file ]
Source                        usbmuxd
Source Path                   /usr/sbin/usbmuxd
Port                          <Unknown>
Host                          heidegger
Source RPM Packages           usbmuxd-1.0.7-1.fc15
Target RPM Packages           
Policy RPM                    selinux-policy-3.9.16-30.fc15
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     heidegger
Platform                      Linux heidegger 2.6.38.8-32.fc15.x86_64 #1 SMP Mon
                              Jun 13 19:49:05 UTC 2011 x86_64 x86_64
Alert Count                   14
First Seen                    Mon 27 Jun 2011 08:07:12 PM PDT
Last Seen                     Mon 27 Jun 2011 08:20:12 PM PDT
Local ID                      934c0f2f-fec2-4f62-b1c0-42f509d7f383

Raw Audit Messages
type=AVC msg=audit(1309231212.728:243): avc:  denied  { read } for  pid=2341 comm="usbmuxd" path="/dev/bus/usb/001/004" dev=devtmpfs ino=34501 scontext=system_u:system_r:usbmuxd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:svirt_image_t:s0:c154,c991 tclass=chr_file


type=SYSCALL msg=audit(1309231212.728:243): arch=x86_64 syscall=ioctl success=no exit=EACCES a0=9 a1=8038550a a2=11aca50 a3=1 items=0 ppid=1 pid=2341 auid=4294967295 uid=113 gid=113 euid=113 suid=113 fsuid=113 egid=113 sgid=113 fsgid=113 tty=(none) ses=4294967295 comm=usbmuxd exe=/usr/sbin/usbmuxd subj=system_u:system_r:usbmuxd_t:s0-s0:c0.c1023 key=(null)

Hash: usbmuxd,usbmuxd_t,svirt_image_t,chr_file,read

audit2allow

#============= usbmuxd_t ==============
allow usbmuxd_t svirt_image_t:chr_file read;

audit2allow -R

#============= usbmuxd_t ==============
allow usbmuxd_t svirt_image_t:chr_file read;
Comment 4 Kayvan Sylvan 2011-06-27 23:22:52 EDT
Some further info from my case:

# getsebool -a | grep virt
virt_use_comm --> off
virt_use_fusefs --> off
virt_use_nfs --> off
virt_use_samba --> off
virt_use_sysfs --> off
virt_use_usb --> on
virt_use_xserver --> off


# ls -ltZ /dev/bus/usb/001
crw-rw-r--+ qemu qemu system_u:object_r:svirt_image_t:s0:c154,c991 004
crw-rw-r--. root root system_u:object_r:usb_device_t:s0 001
Comment 5 Daniel Walsh 2011-06-28 07:04:32 EDT
Is this actually blocking anything?  IE Can you access your IPHONE?
Comment 6 Daniel Walsh 2011-06-28 07:09:01 EDT
Also your bug is totally different then the one you have attached too.
Comment 7 Daniel Berrange 2011-06-28 07:14:56 EDT
NB, regardless of SELinux, attaching your iPhone to a KVM guest will not work. KVM's USB support is not good enough to work with an iPhone.
Comment 8 Kayvan Sylvan 2011-06-28 09:06:33 EDT
Yes, it's blocking my being able to access the iPhone from the Windows XP guest.
Regarding the KVM/USB support not being good enough, what can I do to help? All the pieces are there, it's just a matter of debugging.
Comment 9 Daniel Walsh 2011-06-28 12:59:35 EDT
From an SELinux point of view, I would just put the usbmuxd_t in to permissive mode and gather all AVC's

# semanage permissive -a usbmuxd_t
Run the test

Put usbmuxd_t back into enforcing.
# semanage permissive -d usbmuxd_t
Comment 10 Kayvan Sylvan 2011-06-29 16:27:50 EDT
@Daniel. Thanks. Okay, I did the above and still can't get the iPhone to show up on the guest OS. The messages are:

Jun 29 13:23:17 heidegger setroubleshoot: SELinux is preventing /usr/sbin/usbmuxd from write access on the chr_file /dev/bus/usb/001/006. For complete SELinux messages. run sealert -l f5f01c13-b59b-40e1-af20-ab0b17d1e485
Jun 29 13:23:17 heidegger setroubleshoot: SELinux is preventing /usr/sbin/usbmuxd from read access on the chr_file /dev/bus/usb/001/006. For complete SELinux messages. run sealert -l dc082657-fc41-4302-9982-625ed1f244ee

And from sealert:

SELinux is preventing /usr/sbin/usbmuxd from read access on the chr_file /dev/bus/usb/001/006.

*****  Plugin restorecon (99.5 confidence) suggests  *************************

If you want to fix the label. 
/dev/bus/usb/001/006 default label should be usb_device_t.
Then you can run restorecon.
Do
# /sbin/restorecon -v /dev/bus/usb/001/006

*****  Plugin catchall (1.49 confidence) suggests  ***************************

If you believe that usbmuxd should be allowed read access on the 006 chr_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep usbmuxd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:usbmuxd_t:s0-s0:c0.c1023
Target Context                system_u:object_r:svirt_image_t:s0:c758,c1008
Target Objects                /dev/bus/usb/001/006 [ chr_file ]
Source                        usbmuxd
Source Path                   /usr/sbin/usbmuxd
Port                          <Unknown>
Host                          heidegger
Source RPM Packages           usbmuxd-1.0.7-1.fc15
Target RPM Packages           
Policy RPM                    selinux-policy-3.9.16-30.fc15
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     heidegger
Platform                      Linux heidegger 2.6.38.8-32.fc15.x86_64 #1 SMP Mon
                              Jun 13 19:49:05 UTC 2011 x86_64 x86_64
Alert Count                   1
First Seen                    Wed 29 Jun 2011 01:23:14 PM PDT
Last Seen                     Wed 29 Jun 2011 01:23:14 PM PDT
Local ID                      dc082657-fc41-4302-9982-625ed1f244ee

Raw Audit Messages
type=AVC msg=audit(1309378994.634:251): avc:  denied  { read } for  pid=23049 comm="usbmuxd" path="/dev/bus/usb/001/006" dev=devtmpfs ino=14448631 scontext=system_u:system_r:usbmuxd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:svirt_image_t:s0:c758,c1008 tclass=chr_file


type=SYSCALL msg=audit(1309378994.634:251): arch=x86_64 syscall=ioctl success=yes exit=0 a0=9 a1=8038550a a2=1eb3710 a3=f27e items=0 ppid=1 pid=23049 auid=4294967295 uid=113 gid=113 euid=113 suid=113 fsuid=113 egid=113 sgid=113 fsgid=113 tty=(none) ses=4294967295 comm=usbmuxd exe=/usr/sbin/usbmuxd subj=system_u:system_r:usbmuxd_t:s0-s0:c0.c1023 key=(null)

Hash: usbmuxd,usbmuxd_t,svirt_image_t,chr_file,read

audit2allow

#============= usbmuxd_t ==============
allow usbmuxd_t svirt_image_t:chr_file read;

audit2allow -R

#============= usbmuxd_t ==============
allow usbmuxd_t svirt_image_t:chr_file read;
Comment 11 Laine Stump 2011-06-29 17:59:09 EDT
Kayvan,

It's good that you're working out all these SELinux problems, but as Daniel says, the USB support in qemu is not adequate to support connecting an iPhone to a guest OS; it isn't just a matter of working out bugs. iPhones require USB 2.0 support, and qemu only has USB 1. There are qemu patches to support this, but I don't think they've even all been applied upstream yet, much less been put into a release.

If you really believe that SELinux is the reason your iPhone isn't connecting to your WinXP guest, run "setenforce permissive" at a root shell prompt, then retry your test - the results of SELinux operations will then be ignored. If your operation then succeeds, SELinux really is the root of the problem; if it still fails, your problem is elsewhere.
Comment 12 Kayvan Sylvan 2011-06-29 19:40:26 EDT
Thanks VERY MUCH to Laine and Daniel Walsh and Daniel Berrange.

I now understand.

I found the relevant qemu stuff here http://www.kraxel.org/cgit/qemu/tree/docs/usb2.txt?h=usb.15

Are there any qemu packages out there for this yet? Anything I can try out?
Comment 13 Daniel Berrange 2011-06-30 05:04:40 EDT
As Dan Walsh says, Kayvan has basically reported a completely different problem to the original bug reporter.

The original bug report AVC was

Raw Audit Messages
type=AVC msg=audit(1300093752.32:40): avc:  denied  { ioctl } for  pid=2409
comm="qemu-kvm" path="/dev/bus/usb/001/007" dev=devtmpfs ino=43988
scontext=system_u:system_r:svirt_t:s0:c112,c574
tcontext=system_u:object_r:usb_device_t:s0 tclass=chr_file

This is saying that QEMU is not being allowed access to /dev/bus/usb/001/007, because it hasn't been labelled correctly. The label of the device is 'usb_device_t' which is wrong, because libvirt should have changed it to 'svirt_image_t:s0:c112,c574'. I believe this most likely a bug in the version of libvirt used by the original reporter, incorrectly labelling the USB device.
In my tests this works correctly, so I believe the original reporter's problem is solved by newer libvirt.

The different problem Kayvan reported in comment #3 has an AVC

type=AVC msg=audit(1309231212.728:243): avc:  denied  { read } for  pid=2341
comm="usbmuxd" path="/dev/bus/usb/001/004" dev=devtmpfs ino=34501
scontext=system_u:system_r:usbmuxd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:svirt_image_t:s0:c154,c991 tclass=chr_file

This is saying that 'usbmuxd' is not being allowed access to /dev/bus/usb/001/004. The label of the device is 'svirt_image_t:s0:c154,c991' which shows that the device has been assigned to QEMU and correctly relabelled by libvirt. 

'usbmuxd' is a program completely unrelated to libvirt, that is running in the host OS. It is launched by udev due to /lib/udev/rules.d/85-usbmuxd.rules. Whenever an iPhone/iPod Touch is installed, usbmuxd is launched and tries to open the USB device.  Since this USB device has been re-assigned to QEMU, SELinux is *correctly* denying  usbmuxd any further access to the USB device. 

So IMHO, there is no SELinux policy bug here.

At most, perhaps we want a 'dontaudit' rule for usbmuxd if it tries to use a device labelled svirt_image_t, since this is an expected harmless scenario that I don't see a way to avoid aside from uninstalling usbmuxd.
Comment 14 Daniel Walsh 2011-06-30 07:24:50 EDT
Ok Miroslav I have updated Rawhide to dontaudit this access.
Comment 15 Kayvan Sylvan 2011-06-30 10:45:05 EDT
Thanks, guys. I totally agree with Dan Walsh's assessment. I added to an unrelated bug. Sorry.

Is there a bug that tracks the USB 2.0 support integration into libvirt/virt-manager?
Comment 16 Fedora Admin XMLRPC Client 2011-09-22 13:58:39 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 17 Fedora Admin XMLRPC Client 2011-09-22 14:02:22 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 18 Fedora Admin XMLRPC Client 2011-11-30 14:58:26 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 19 Fedora Admin XMLRPC Client 2011-11-30 14:59:32 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 20 Fedora Admin XMLRPC Client 2011-11-30 15:04:39 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 21 Fedora Admin XMLRPC Client 2011-11-30 15:05:03 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 22 Cole Robinson 2012-01-24 16:53:38 EST
Kayvan, F16 should have USB2.0 support so I suggest moving to that.

I think the selinux issue is fixed by recent libvirt anyways. Closing this since F14 is EOL