Comment 4 for bug 1552241

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