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;
*** Bug 684697 has been marked as a duplicate of this bug. ***
*** Bug 684696 has been marked as a duplicate of this bug. ***
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;
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
Is this actually blocking anything? IE Can you access your IPHONE?
Also your bug is totally different then the one you have attached too.
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.
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.
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
@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;
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.
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?
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.
Ok Miroslav I have updated Rawhide to dontaudit this access.
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?
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
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