Bug 537227 - libvirt does not support vendor/product based USB device passthrough with QEMU
Summary: libvirt does not support vendor/product based USB device passthrough with QEMU
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: 12
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Daniel Berrangé
QA Contact: Fedora Extras Quality Assurance
Whiteboard: setroubleshoot_trace_hash:8fbd7b36950...
: 504444 542450 550951 (view as bug list)
Depends On:
Blocks: F13VirtTarget 542450
TreeView+ depends on / blocked
Reported: 2009-11-12 21:17 UTC by Bradley
Modified: 2019-01-09 12:33 UTC (History)
19 users (show)

Fixed In Version: libvirt-0.7.1-16.fc12
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 549841 (view as bug list)
Last Closed: 2010-05-28 17:56:42 UTC
Type: ---

Attachments (Terms of Use)

Description Bradley 2009-11-12 21:17:45 UTC

SELinux is preventing /usr/bin/qemu-kvm "read write" access on 006.

Detailed Description:

[qemu-kvm has a permissive type (svirt_t). This access was not denied.]

SELinux denied access requested by qemu-kvm. It is not expected that this access
is required by qemu-kvm and this access may signal an intrusion attempt. It is
also possible that the specific version or configuration of the application is
causing it to require additional access.

Allowing Access:

You can generate a local policy module to allow this access - see FAQ
(http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Please file a bug

Additional Information:

Source Context                system_u:system_r:svirt_t:s0:c409,c463
Target Context                system_u:object_r:usb_device_t:s0
Target Objects                006 [ chr_file ]
Source                        qemu-kvm
Source Path                   /usr/bin/qemu-kvm
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           qemu-system-x86-0.11.0-11.fc12
Target RPM Packages           
Policy RPM                    selinux-policy-3.6.32-41.fc12
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   catchall
Host Name                     (removed)
Platform                      Linux (removed) #1 SMP
                              Sat Nov 7 21:11:14 EST 2009 x86_64 x86_64
Alert Count                   1
First Seen                    Fri 13 Nov 2009 08:15:54 EST
Last Seen                     Fri 13 Nov 2009 08:15:54 EST
Local ID                      ac6c44ec-27bc-4bbb-95f2-b5be91fcca91
Line Numbers                  

Raw Audit Messages            

node=(removed) type=AVC msg=audit(1258060554.674:24435): avc:  denied  { read write } for  pid=6889 comm="qemu-kvm" name="006" dev=tmpfs ino=37975 scontext=system_u:system_r:svirt_t:s0:c409,c463 tcontext=system_u:object_r:usb_device_t:s0 tclass=chr_file

node=(removed) type=SYSCALL msg=audit(1258060554.674:24435): arch=c000003e syscall=2 success=yes exit=4294967424 a0=7fff50bc5ce0 a1=802 a2=7fff50bc5cf4 a3=fffffff4 items=0 ppid=1 pid=6889 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:c409,c463 key=(null)

Hash String generated from  selinux-policy-3.6.32-41.fc12,catchall,qemu-kvm,svirt_t,usb_device_t,chr_file,read,write
audit2allow suggests:

#============= svirt_t ==============
allow svirt_t usb_device_t:chr_file { read write };

Comment 1 Bradley 2009-11-12 21:19:10 UTC
[root@plum ~]# getsebool -a | grep ^virt
virt_manage_sysfs --> on
virt_use_comm --> off
virt_use_nfs --> off
virt_use_samba --> off
virt_use_usb --> on

Trying USB passthrough for my iPhone - it doesn't work even if I turn selinux to permissive mode, but this presumably isn't helping...

Comment 2 Bradley 2009-11-12 21:26:46 UTC
virt_use_comm doesn't help either

Comment 3 Daniel Walsh 2009-11-12 22:23:48 UTC
looks like a libvirt bug since the device does not have the proper label on it.

Comment 4 Bradley 2009-11-12 22:34:53 UTC
Its a usb device (my iPhone) that I've plugged in. Not sure why libvirt would be setting the label? Its:

[bbaetz@plum ~]$ ls -lZ /dev/bus/usb/002/006 
crw-rw-rw-+ root root system_u:object_r:usb_device_t:s0 /dev/bus/usb/002/006

which looks right - what should it be?

Comment 5 Daniel Berrangé 2009-11-12 23:38:41 UTC
What is the XML for the libvirt guest you have assigned this device to ?

There is a current limitation in libvirt that means it will only correctly label USB devices that are assigned based on bus+device address. It won't correctly handle vendor+product ID assignment. We need to hook into libusb to fix the latter properly by resolving the vendor/product against currently present devices.

Comment 6 Bradley 2009-11-12 23:42:36 UTC
Yes, its vendor+product - I get a new device number every time I plug it in. XML is:

    <hostdev mode='subsystem' type='usb' managed='no'>
        <vendor id='0x05ac'/>
        <product id='0x1294'/>

(manually created to the XML)

Comment 7 Daniel Berrangé 2009-11-13 11:27:03 UTC
Ok, for the time being you'll have to put SELinux in permissive mode. We are working on getting product/vendor based assignment correctly with SELinux in enforcing mode, but its not going to be  a quick fix.

Comment 8 Bradley 2009-11-14 01:48:11 UTC
I also have to manually change the acls, since the 'qemu' user didn't have access. But it doesn't work anyway, apparently because the iphone requires ehci support, which qemu doesn't yet have.

Comment 9 Mark McLoughlin 2009-11-19 13:36:36 UTC

        if (dev->source.subsys.u.usb.bus && dev->source.subsys.u.usb.device) {
            usbDevice *usb = usbGetDevice(conn,

            if (!usb)
                goto done;

            ret = usbDeviceFileIterate(conn, usb, SELinuxSetSecurityUSBLabel, vm);
            usbFreeDevice(conn, usb);

        } else {
            /* XXX deal with product/vendor better */
            ret = 0;

in src/security/security_selinux.c

Comment 10 Adam Williamson 2010-01-20 19:49:48 UTC
adjusting summary to be more clear and searchable (I also have observed this problem and was about to file a dupe). For quick reference, if you're hitting this problem, do:

setenforce Permissive

as root, and then restart libvirtd. Then passthrough should work.

Comment 11 Daniel Berrangé 2010-01-20 20:21:31 UTC
This isn't actually a SELinux issue. It is libvirt not being able to resolve the vendor+product IDs into a bus+device address. This impacts several areas of libvirt, including the inability to relabel the device for SELinux


Comment 12 Adam Williamson 2010-01-20 20:37:08 UTC
Still, it manifests as an SELinux issue and people are likely to search for it that way (that's what I did), which is why I wanted to add that word to the summary.

Comment 13 Daniel Berrangé 2010-02-11 14:44:25 UTC
Patch was included upstream in the 0.7.6 release


Comment 14 Adam Williamson 2010-02-11 18:00:21 UTC
thanks. 'POST' status isn't used in Fedora (see https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow ) - up until the fix actually lands in a Fedora package for the appropriate release it's still ASSIGNED. For a stable release, it goes to MODIFIED once you have it in updates-testing, and CLOSED once it's in updates. Setting back to ASSIGNED for now.

Fedora Bugzappers volunteer triage team

Comment 15 Daniel Berrangé 2010-02-11 18:09:57 UTC
Please don't change the status. To quote the very link you gave

  "POST: This state is primarily used by developers working on virtualization and the kernel. "

Comment 16 Adam Williamson 2010-02-11 18:58:56 UTC
oops, sorry, early morning.

(I don't remember putting that in there!)

Fedora Bugzappers volunteer triage team

Comment 17 Cole Robinson 2010-03-16 16:05:43 UTC
*** Bug 550951 has been marked as a duplicate of this bug. ***

Comment 18 Cole Robinson 2010-03-16 18:17:54 UTC
*** Bug 574136 has been marked as a duplicate of this bug. ***

Comment 19 Cole Robinson 2010-05-17 20:09:02 UTC
*** Bug 504444 has been marked as a duplicate of this bug. ***

Comment 20 Fedora Update System 2010-05-18 16:55:57 UTC
libvirt-0.7.1-16.fc12 has been submitted as an update for Fedora 12.

Comment 21 Fedora Update System 2010-05-19 19:13:56 UTC
libvirt-0.7.1-16.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update libvirt'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/libvirt-0.7.1-16.fc12

Comment 22 Cole Robinson 2010-05-27 19:31:54 UTC
*** Bug 542450 has been marked as a duplicate of this bug. ***

Comment 23 Fedora Update System 2010-05-28 17:56:11 UTC
libvirt-0.7.1-16.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 24 Jiri Kastner 2010-09-20 08:33:25 UTC
just noticed selinux message - 'SELinux is preventing /usr/bin/qemu-kvm "read write" access on /dev/bus/usb/006/002.' on fedora 13.

Comment 25 Frank Casper 2010-11-16 03:04:36 UTC
This is still an issue in Fedora 14. Is this ever gonna get fixed? The only reason for me to run Linux is to do virtualization, but I can't do that without a fix to this.

Comment 26 Daniel Berrangé 2010-11-16 11:09:58 UTC
This bug is already fixed. If you have further issues, please file new BZs, rather than commenting on existing resolved bugs.

Comment 27 Sandro Janke 2010-12-16 13:21:04 UTC
What about re-opening this bug? I get SELinux denials when trying to attach USB devices to VMs. Reporting the alert as a bug leads me to closed duplicate bugs #579744, #580333. Following the chain, I end up here. In addition there is bug #638801 which is related, but not yet closed.

Since others might end up here as well, I'd rather see this bug reopened and updated.

Comment 28 Daniel Berrangé 2010-12-16 13:25:45 UTC
Re-opening old bugs is very bad because even if the end result looks similar, you can't assume the root cause bug is the same. Always file a new bug, or find one that's still unresolved that shows the same symptoms.

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