libvirt-bin apparmor settings for usb host device

"The line is wrong:
  /sys/devices/**/usb[0-9]*/** r,
correct is:
  /sys/devices/*/*/usb[0-9]*/** r,"

'/sys/devices/**/usb[0-9]*/**' is a superset of '/sys/devices/*/*/usb[0-9]*/**', so this change should not be needed. '/run/udev/data/** r' grants a lot of information to all VMs and should not be added without more information.

Can you give steps to reproduce?

[Expired for libvirt (Ubuntu) because there has been no activity for 60 days.]

Affected by this as well. I have libvirt vms on a system that was upgraded from 14.04 that fail on 16.04 due to updated apparmor settings.

I'm trying to pass a USB dongle through to a windows instance:

    <hostdev mode='subsystem' type='usb' managed='yes'>
      <source>
        <vendor id='0x04b9'/>
        <product id='0x0300'/>
      </source>
    </hostdev>

This was added years ago, probably through the libvirt gui.

Relevant Logs:
Apr 24 04:24:46 phantom-ssd kernel: [682883.819567] audit: type=1400 audit(1493033086.602:277): apparmor="DENIED" operation="open" profile="libvirt-b702ed58-3a9c-77bc-7e52-bcc8053192a4" name="/run/udev/data/c189:1" pid=27849 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=119 ouid=0
Apr 24 04:24:46 phantom-ssd kernel: [682883.819697] audit: type=1400 audit(1493033086.602:278): apparmor="DENIED" operation="open" profile="libvirt-b702ed58-3a9c-77bc-7e52-bcc8053192a4" name="/run/udev/data/c189:129" pid=27849 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=119 ouid=0
Apr 24 04:24:46 phantom-ssd kernel: [682883.819815] audit: type=1400 audit(1493033086.602:279): apparmor="DENIED" operation="open" profile="libvirt-b702ed58-3a9c-77bc-7e52-bcc8053192a4" name="/run/udev/data/c189:0" pid=27849 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=119 ouid=0
Apr 24 04:24:46 phantom-ssd kernel: [682883.819934] audit: type=1400 audit(1493033086.602:280): apparmor="DENIED" operation="open" profile="libvirt-b702ed58-3a9c-77bc-7e52-bcc8053192a4" name="/run/udev/data/c189:128" pid=27849 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=119 ouid=0
Apr 24 04:24:46 phantom-ssd kernel: [682883.820120] audit: type=1400 audit(1493033086.602:281): apparmor="DENIED" operation="open" profile="libvirt-b702ed58-3a9c-77bc-7e52-bcc8053192a4" name="/run/udev/data/c189:256" pid=27849 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=119 ouid=0

I've tried being selective about what's allowed, e.g. /run/udev/data/c189*, but then windows fails when it tries to enumerate the USB entries, /run/udev/data/+usb*

I can confirm the issue, but due to the fact that opening up all of /run/udev/data/** (actually I tested and it would only need /run/udev/data/*) is a big whole that was not done yet.

I updated the hints to [1] which already held similar hints for older releases which are in the meantime fixed and in the shipped profile (which is why it worked on trusty).

We added various rules over the past to allow this to work, but have to adapt to qemu changes over time. There is a full section in the profile for udev access already - but newer qemu seems to parse this differently to select the device to pass through.

What we need to do to really fix it is a bit more complex thou and therefore takes a bit of work.
For other cases where a guest is not supposed to see "too much" libvirt-aa-helper generates the custom per-guest apparmor bits. You can see them in e.g.
/etc/apparmor.d/libvirt/libvirt-<uuid>
On hot add/remove it already generates an entry like "/dev/bus/usb/003/003" it will also have to detect which udev path that will need and add this as well.

So for now we have a workaround by the users who need it opening up the profile, never the less IMHO it is a regression and I want to thank you for reporting it.
Even more I want to thank as while debugging and confirming I found that the non-hotplug libvirt-aa-helper path is broken as well :-/ Instead of /dev/bus/usb/003/003 it generates /dev/bus/usb/000/000 and fails. I forked bug 1686324 for that.

[1]: https://help.ubuntu.com/community/KVM/Managing#Adding_USB_Device_Pass-through

Glad to see that the problem is confirmed. I'm uncomfortable about the blanket allow for /run/udev/data/* as a general solution, as you've said, there's a lot there.

I had found the /etc/apparmor.d/libvirt/libvirt-<uuid>[.files] sections, it looks like I must have edited it to allow the usb passthrough in 14.04 from the entry there.

There is currently a full set of tasks that will need virt-aa-helper upstream development and SRUing from there then.
For some fort of overview I'll be tagging them all "virt-aa-helper" [1] for now and hope that myself or anyone else (volunteers show up :-) ) will find some time for it.

[1]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bugs?field.tag=virt-aa-helper

Hmm, I had the same issue passing an USB dongle.

But today saw same system, same USB port but other device works fine.
$ cat cellphone.xml
<hostdev mode='subsystem' type='usb'>
    <source>
        <vendor id='0x22b8'/>
        <product id='0x2e82'/>
    </source>
</hostdev>

Generated correctly
   "/dev/bus/usb/002/018" rw

So when getting to develop something to upstream for virt-aa-helper in that regard I need to make sure I find the difference between the two.

Hi, Christian

Is there any workaround for 17.10? Workaround from #4 seems like not help anymore.

Hi,

<Imagine a rant at my bad personal time allocation to fix this properly at some point>

Checking on 17.04 case now ...
On 17.04 it even seems to work for me as I mentioned in comment #7 - never the less that seems to depend on static vs hot add/remove.

@RussianNeuroMancer - could you share the following to find where we need to adapt the workaroudn steps for you:
1. the XML snippet describing the USB device
2. the lsusb output matching those
<if using static add that is in the guest xml all the time>
3. dmesg while starting the guest (for apparmor denials)
4. after the guest started (or even failed to start) check the UUID (e.g. via virsh edit) and then fetch the generated apparmor file from /etc/apparmor.d/libvirt/libvirt-<uuid>.files
<if you use hot add via virsh attach>
3. dmesg while hot attaching the device (for apparmor denials)
4. after the attach (even if it failed) check the UUID (e.g. via virsh edit) and then fetch the generated apparmor file from /etc/apparmor.d/libvirt/libvirt-<uuid>.files

Hello, Christian!

I tested this issue again today and find that half of my problem was in /etc/apparmor.d/abstractions/libvirt-qemu add that was overwritten by package update. So I applied both workarounds once again:

Workaround 1: https://help.ubuntu.com/community/KVM/Managing#Adding_USB_Device_Pass-through
Workaround 2: from bug description.

However, this does not help:
error: Failed to start domain usbtesting
error: внутренняя ошибка: qemu unexpectedly closed the monitor: 2017-09-10T16:49:42.791870Z qemu-system-x86_64: -chardev pty,id=charserial0: char device redirected to /dev/pts/13 (label charserial0)
libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/002/002: Permission denied
libusb: error [_get_usbfs_fd] libusb requires write access to USB device nodes.
2017-09-10T16:49:42.856467Z qemu-system-x86_64: -device usb-host,hostbus=2,hostaddr=2,id=hostdev0,bus=usb.0,port=4: failed to open host usb device 2:2

So looks like in my case real issue is bug 1686324

1.
<hostdev mode='subsystem' type='usb' managed='yes'>
  <source>
    <vendor id='0x13fe'/>
    <product id='0x3e00'/>
  </source>
  <address type='usb' bus='0' port='4'/>
</hostdev>
2.
Bus 002 Device 002: ID 13fe:3e00 Kingston Technology Company Inc. Flash Drive
3.
[289497.500034] audit: type=1400 audit(1505062322.005:294): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="libvirt-57e625bc-be94-4d72-a03f-954babffb79f" pid=18312 comm="apparmor_parser"
[289497.598622] audit: type=1400 audit(1505062322.103:295): apparmor="DENIED" operation="open" profile="libvirt-57e625bc-be94-4d72-a03f-954babffb79f" name="/dev/bus/usb/002/002" pid=18322 comm="qemu-system-x86" requested_mask="wr" denied_mask="wr" fsuid=102 ouid=102
4.
"/var/log/libvirt/**/usbtesting.log" w,
"/var/lib/libvirt/qemu/domain-usbtesting/monitor.sock" rw,
"/var/lib/libvirt/qemu/domain-34-usbtesting/*" rw,
"/var/lib/libvirt/qemu/channel/target/domain-34-usbtesting/*" rw,
"/var/run/libvirt/**/usbtesting.pid" rwk,
"/run/libvirt/**/usbtesting.pid" rwk,
"/var/run/libvirt/**/*.tunnelmigrate.dest.usbtesting" rw,
"/run/libvirt/**/*.tunnelmigrate.dest.usbtesting" rw,
"/var/lib/libvirt/images/usbtesting.img" rwk,
"/dev/bus/usb/000/000" rw,
/dev/vhost-net rw,
"/dev/net/tun" rw,

For now I get things working by adding
/dev/bus/usb/*/* rw,
after Workaround 2, but this probably very bad idea. What is proper solution for this?

Hi NeuroMancer,
what you now have hit is a case I sometimes have seen.
It is described in bug 1686324 and to fix it "right" is part of the same virt-aa-helper effort.
To keep things separate - this issue here about the /run/udev rules - the other one about /dev/bus/usb/... I will post the rest of the comment there.

Hi,
I was working on a fix for the "other" usb bug 1686324 (and have a preliminary fix).
With that out of the way I now reproduced this bug and will see if I can find something how virt-aa-helper could know about these paths.

It is interesting that it seems to do so only once.
So if a qemu process is started then
1. the first attach like:
    virsh attach-device artful-pidstat hot-add-usb.xml
   Triggers the denies:
2. but subsequent attach-device calls just fail without new denies

That explains to some extend why in some cases people don't see the deny.
It happened in the past but is cached.

It is also important to consider that when debugging as we will hit it only once.

The first step is to understand what/why qemu actually reads those.

I've found that on a system with the most recent stack libvirt-3.6 + qemu 2.10 this does no more show up. So it is either fixed and we need to find what to backport or that system is special.

So on that given system I stepped back to libvirt 2.5/qemu 2.8 which I know to show the issue on another system. And it turns out that it is the device that does not trigger the issue there.
So no good place to debug and probably still not fixed on newer versions.

So back to debugging where/why qemu actually calls these.
On that a note: I was made aware that the paths in /run/udev/data are rather unpredictable as they base on minor/major numbers - well maybe they are runtime predictable. But in any case reading there can be racy it seems.

While attaching:
$ perf record -e syscalls:sys_enter_open -R --pid 24846 --call-graph dwarf sleep 10
Gives:
            7fc9f16d8160 __opendir (/lib/x86_64-linux-gnu/libc-2.23.so)
            7fc9f665455c [unknown] (/lib/x86_64-linux-gnu/libudev.so.1.6.4)
            7fc9f664a5ac udev_enumerate_scan_devices (/lib/x86_64-linux-gnu/libudev.so.1.6.4)
            7fc9f2a4ab25 [unknown] (/lib/x86_64-linux-gnu/libusb-1.0.so.0.1.0)
            7fc9f2a486e1 [unknown] (/lib/x86_64-linux-gnu/libusb-1.0.so.0.1.0)
            7fc9f2a40b1d libusb_init (/lib/x86_64-linux-gnu/libusb-1.0.so.0.1.0)
              bd11d7a0f2 [unknown] (/usr/bin/qemu-system-x86_64)
              bd11d7b952 [unknown] (/usr/bin/qemu-system-x86_64)
              bd11d4c7e1 [unknown] (/usr/bin/qemu-system-x86_64)
              bd11c94bb5 [unknown] (/usr/bin/qemu-system-x86_64)
              bd11dd8e4e [unknown] (/usr/bin/qemu-system-x86_64)
              bd11ddccc1 object_property_set_qobject (/usr/bin/qemu-system-x86_64)
              bd11ddab60 object_property_set_bool (/usr/bin/qemu-system-x86_64)
              bd11c1544d qdev_device_add (/usr/bin/qemu-system-x86_64)

There were a lot, but it seems to be a loop within libusb.
So qemu uses libusb and libusb on udev_enumerate_scan_devices uses libudev.
That is on libusb_init called from qemu within the scope of a qdev_device_add.

This is in qemu's "usb_host_init" to initialize "static libusb_context *ctx;"
The apparmor denies kill it's internal representation of the devices and thereby make the attach fail.

The following test confirms all that:
$ cat test.c
#include <stdio.h>
#include <libusb-1.0/libusb.h>

int main()
{
    int rc=0;

    rc = libusb_init(NULL);
    if (rc != 0) {
        printf("Fail");
        return -1;
    }
    printf("Initialized");
}

$ gcc -Wall test.c -lusb-1.0 -o test

$ strace -e open ./test 2>&1 | grep '/run'
open("/run/udev/data/c189:1", O_RDONLY|O_CLOEXEC) = 8
open("/run/udev/data/c189:129", O_RDONLY|O_CLOEXEC) = 8
open("/run/udev/data/c189:130", O_RDONLY|O_CLOEXEC) = 8
open("/run/udev/data/c189:135", O_RDONLY|O_CLOEXEC) = 8
open("/run/udev/data/c189:136", O_RDONLY|O_CLOEXEC) = 8
open("/run/udev/data/c189:137", O_RDONLY|O_CLOEXEC) = 8
open("/run/udev/data/c189:257", O_RDONLY|O_CLOEXEC) = 8
open("/run/udev/data/c189:0", O_RDONLY|O_CLOEXEC) = 8
open("/run/udev/data/c189:128", O_RDONLY|O_CLOEXEC) = 8
open("/run/udev/data/c189:256", O_RDONLY|O_CLOEXEC) = 8
open("/run/udev/data/c189:131", O_RDONLY|O_CLOEXEC) = 8
open("/run/udev/data/c189:132", O_RDONLY|O_CLOEXEC) = 8
open("/run/udev/data/c189:133", O_RDONLY|O_CLOEXEC) = 8
open("/run/udev/data/c189:134", O_RDONLY|O_CLOEXEC) = 8
open("/run/udev/data/+usb:3-0:1.0", O_RDONLY|O_CLOEXEC) = 8
open("/run/udev/data/+usb:3-2:1.0", O_RDONLY|O_CLOEXEC) = 8
open("/run/udev/data/+usb:2-1.1:1.0", O_RDONLY|O_CLOEXEC) = 8
open("/run/udev/data/+usb:2-1.2:1.0", O_RDONLY|O_CLOEXEC) = 8
open("/run/udev/data/+usb:2-1.2:1.1", O_RDONLY|O_CLOEXEC) = 8
open("/run/udev/data/+usb:2-1.3:1.0", O_RDONLY|O_CLOEXEC) = 8
open("/run/udev/data/+usb:2-1.3:1.1", O_RDONLY|O_CLOEXEC) = 8
open("/run/udev/data/+usb:2-1.4:1.0", O_RDONLY|O_CLOEXEC) = 8
open("/run/udev/data/+usb:2-1.4:1.1", O_RDONLY|O_CLOEXEC) = 8
open("/run/udev/data/+usb:2-1.4:1.2", O_RDONLY|O_CLOEXEC) = 8
open("/run/udev/data/+usb:2-1.4:1.3", O_RDONLY|O_CLOEXEC) = 8
open("/run/udev/data/+usb:1-0:1.0", O_RDONLY|O_CLOEXEC) = 8
open("/run/udev/data/+usb:1-1:1.0", O_RDONLY|O_CLOEXEC) = 8
open("/run/udev/data/+usb:2-0:1.0", O_RDONLY|O_CLOEXEC) = 8
open("/run/udev/data/+usb:2-1:1.0", O_RDONLY|O_CLOEXEC) = 8
open("/run/udev/data/+usb:2-5:1.0", O_RDONLY|O_CLOEXEC) = 8
open("/run/udev/data/+usb:2-6:1.0", O_RDONLY|O_CLOEXEC) = 8
open("/run/udev/data/+usb:2-7:1.0", O_RDONLY|O_CLOEXEC) = 8
open("/run/udev/data/+usb:2-7:1.1", O_RDONLY|O_CLOEXEC) = 8
open("/run/udev/data/+usb:2-8:1.0", O_RDONLY|O_CLOEXEC) = 8
open("/run/udev/data/+usb:2-8:1.1", O_RDONLY|O_CLOEXEC) = 8

We might be safe to say /run/udev/data/+usb* but for the c189 we would need to know major/minor number.
Yes it is 189 mostly, but we need to do it right which is a dynamic check.
Non dynamic according to [1] that would be:
c - for char
and IDs 166,167,180,188,189
So something like the following:
/run/udev/data/c16[6,7]* r,
/run/udev/data/c18[0,8,9]* r,

That already is much safer than the full blanket that users use as workaround atm.
Need to think what we could do dynamically to track down just the device needed.

Mabye "only" allowing the one we need is sufficient for libusb to work correctly?
Lets take my case, I know I'm going to insert: "0781:5580".

$grep -l 5580 $(grep -lr 0781 /run/udev/data/c16[6,7]* /run/udev/data/c18[0,8,9]* 2>/dev/null | xargs)
/run/udev/data/c189:257

So I'd be able to (much harder in C that is sure) to know which one we need.
Experiment with only allowing that...

Ok, so that (to allow only the selected device) would even work, but that isn't complete.
As I found before libusb_init is only called "once" per qemu.
Which I think might be an issue in general as USB devices are supposed to come and go right?

But with a solution that only allows the one passed what happens if a user wants to attach another device.
There will be no new init and due to that it will fail?
Need to test that as well...

A second device to add which would be in:
/run/udev/data/c189:134
But only allow the first device in the apparmor rules.
Only if that would trigger a deny on the second attach it would help to add the second rule later.
And it does not show up, so a new rule on the second attach would not have helped.

Maybe libusb tries to be smart and only rescan if devices where plugged/unplugged.
So I retested
1. second device physically detached
2. attach first device to guest
3. attach second device physically to machine
4. attach second device to guest

Still no re-read.
So there is a qemu issue related to all of it that libusb context would have to be refreshed.
Until that is fixed we can only go for ther static rules.

Need to spawn a few discussions in both upstreams about that.

P.S. the [1] of comment #16 should have been:
[1]: http://elixir.free-electrons.com/linux/latest/source/Documentation/admin-guide/devices.txt

This was a lot of debugging and analysis for a patch that looks all too easy afterwards :-/
But it is now ready part of the patch queue that I intend to submit for the virt-aa-helper bugs.

Going on to the next bug in this queue (I'll submit them together at the end) and come back to fix & backport as needed then.

Related changes upstream now, will be picked no next merge.
Likely consider picking in advance as soon as BB opens up.

Prepped the SRU Template for Artful as it is released now.
Also passed (the now fully running, due to the fixes) regression tests - so ready for SRU review.

Note: Bionic Beaver is not yet around, so uploading to Artful with a normal version increment should still be the right thing to do - if there was a race with BB, please let me know so that I upload it there asap to fix it in Artful.

SRU +1 for what is currently in the queue.

Hello Josef, or anyone else affected,

Accepted libvirt into artful-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/libvirt/3.6.0-1ubuntu6 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-artful to verification-done-artful. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-artful. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

root@ubuntu:~#
root@ubuntu:~# virsh define testguest.xml
Domain testguest defined from testguest.xml

root@ubuntu:~# virsh start testguest
Domain testguest started

root@ubuntu:~# cat <<EOF >usb.xml
> <hostdev mode='subsystem' type='usb' managed='yes'>
> <source>
> <vendor id='0x046d'/>
> <product id='0x0825'/>
> </source>
> </hostdev>
> EOF

root@ubuntu:~# virsh attach-device testguest usb.xml
error: Failed to attach device from usb.xml
error: internal error: unable to execute QEMU command 'device_add': failed to find host usb device 2:10

Denies while USB was initialized the first time:
[ 1046.984694] audit: type=1400 audit(1508926280.712:48): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="libvirt-deadbeef-dead-beef-dead-beefdeadbeef" pid=6668 comm="apparmor_parser"
[ 1046.987757] audit: type=1400 audit(1508926280.715:49): apparmor="DENIED" operation="open" profile="libvirt-deadbeef-dead-beef-dead-beefdeadbeef" name="/run/udev/data/c189:133" pid=6638 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=64055 ouid=0
[ 1046.987831] audit: type=1400 audit(1508926280.715:50): apparmor="DENIED" operation="open" profile="libvirt-deadbeef-dead-beef-dead-beefdeadbeef" name="/run/udev/data/c189:256" pid=6638 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=64055 ouid=0
[ 1046.988143] audit: type=1400 audit(1508926280.715:55): apparmor="DENIED" operation="open" profile="libvirt-deadbeef-dead-beef-dead-beefdeadbeef" name="/run/udev/data/c189:129" pid=6638 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=64055 ouid=0
[ 1046.988263] audit: type=1400 audit(1508926280.715:57): apparmor="DENIED" operation="open" profile="libvirt-deadbeef-dead-beef-dead-beefdeadbeef" name="/run/udev/data/c189:0" pid=6638 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=64055 ouid=0

Due to the design of qemu (no rescan later) we need to restart the qemu process after the upgrade.

# Upgrade to Proposed (in other window)
# then start guest again and then attach the device (now working)

virsh attach-device testguest usb.xml

=> Verified

Note: since you likely came here for having issues with USB passthrough. While working on this I found related issues, please check the following bugs to be sure you not just have to add a config or so:
- bug 1727311
- bug 1727313

I just installed ubuntu desktop 17.10 and set up libvirt, and this is still a problem!

I run a Windows VM for some corporate tools, like a specific VOIP phone application and Webex, so pass through the USB headset supplied by IT for this purpose. Without a hack to /etc/apparmor.d/abstractions/libvirt-qemu I cannot start the Windows VM without the error
"error starting domain failed to find host usb device".

USB pass-through worked perfectly in Fedora, which I was using until I just switched to Ubuntu 17.1 desktop, so I knew my Windows VM was working perfectly!

This bug was fixed in the package libvirt - 3.6.0-1ubuntu6

---------------
libvirt (3.6.0-1ubuntu6) artful; urgency=medium

  * d/p/ubuntu-aa/0037-virt-aa-helper...: grant locking permission on append
    files (LP: #1726804)
  * d/p/ubuntu-aa/0038-virt-aa-helper-fix-paths-for-usb-hostdevs.patch:
    fix path generation for USB host devices (LP: #1552241)
  * d/p/ubuntu-aa/0039-virt-aa-helper-fix-libusb-access-to-udev-usb-data.patch:
    generate valid rules on usb passthrough (LP: #1686324)

 -- Christian Ehrhardt <email address hidden> Tue, 24 Oct 2017 14:30:34 +0200

The verification of the Stable Release Update for libvirt has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Hi Paul, if you still have an issue after this fix (check the version that was just released) please check out the two bugs I mentioned as reference in c#24. If still an issue after that please open a new bug.

This issue can appear in many aspects, the one this bug described is certainly fixed, but maybe you found another one - which then would be a new bug to track and solve properly.

This bug was fixed in the package libvirt - 3.6.0-1ubuntu6

---------------
libvirt (3.6.0-1ubuntu6) artful; urgency=medium

  * d/p/ubuntu-aa/0037-virt-aa-helper...: grant locking permission on append
    files (LP: #1726804)
  * d/p/ubuntu-aa/0038-virt-aa-helper-fix-paths-for-usb-hostdevs.patch:
    fix path generation for USB host devices (LP: #1552241)
  * d/p/ubuntu-aa/0039-virt-aa-helper-fix-libusb-access-to-udev-usb-data.patch:
    generate valid rules on usb passthrough (LP: #1686324)

 -- Christian Ehrhardt <email address hidden> Tue, 24 Oct 2017 14:30:34 +0200

Is fixed in Ubuntu 17.10 with latest patches.

I've upgraded my ubuntu desktop 17.10 machine and the apparmor file was indeed patched; I shut down my Windows VM, reloaded apparmor and restarted libvirtd, and it was able to pass through the USB audio device.

Aside: I use xfreerdp to connect to the machine and use the flag "/audio-mode:1" ; this causes the Windows VM to use local audio, and this is how I am able to use the Cisco Jabber VOIP application with the USB headset.

p.s. thanks for getting this fixed; it's one less post-install tweak/hack that's needed in our general deployment of ubuntu desktops!

Status changed to 'Confirmed' because the bug affects multiple users.