In bf3a4140 "virt-aa-helper: fix libusb access to udev usb data" the
libusb access to properly detect the device/bus ids was fixed.

The path /run/udev/data/+usb* contains a subset of that information we
already allow to be read and are currently not needed for the function
qemu needs libusb for. But on the init of libusb all those files are
still read so a lot of apparmor denials can be seen when using usb host
devices, like:
  apparmor="DENIED" operation="open" name="/run/udev/data/+usb:2-1.2:1.0"
  comm="qemu-system-x86" requested_mask="r" denied_mask="r"

Today we could silence the warnings with a deny rule without breaking
current use cases. But since the data in there is only a subset of those
it can read already it is no additional information exposure. And on the
other hand a future udev/libusb/qemu combination might need it so allow
the access in the default apparmor profile.

Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
---
 examples/apparmor/libvirt-qemu | 1 +
 1 file changed, 1 insertion(+)

diff --git a/examples/apparmor/libvirt-qemu b/examples/apparmor/libvirt-qemu
index b341e31..97dd2d4 100644
--- a/examples/apparmor/libvirt-qemu
+++ b/examples/apparmor/libvirt-qemu
@@ -32,6 +32,7 @@
   # libusb needs udev data about usb devices (~equal to content of lsusb -v)
   /run/udev/data/c16[6,7]* r,
   /run/udev/data/c18[0,8,9]* r,
+  /run/udev/data/+usb* r,
 
   # WARNING: this gives the guest direct access to host hardware and specific
   # portions of shared memory. This is required for sound using ALSA with kvm,
-- 
2.7.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Wed, 2017-10-25 at 14:42 +0200, Christian Ehrhardt wrote:
> In bf3a4140 "virt-aa-helper: fix libusb access to udev usb data" the
> libusb access to properly detect the device/bus ids was fixed.
> 
> The path /run/udev/data/+usb* contains a subset of that information
> we
> already allow to be read and are currently not needed for the
> function
> qemu needs libusb for. But on the init of libusb all those files are
> still read so a lot of apparmor denials can be seen when using usb
> host
> devices, like:
>   apparmor="DENIED" operation="open" name="/run/udev/data/+usb:2-
> 1.2:1.0"
>   comm="qemu-system-x86" requested_mask="r" denied_mask="r"
> 
> Today we could silence the warnings with a deny rule without breaking
> current use cases. But since the data in there is only a subset of
> those
> it can read already it is no additional information exposure. And on
> the
> other hand a future udev/libusb/qemu combination might need it so
> allow
> the access in the default apparmor profile.
> 
> Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
> ---
>  examples/apparmor/libvirt-qemu | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/examples/apparmor/libvirt-qemu
> b/examples/apparmor/libvirt-qemu
> index b341e31..97dd2d4 100644
> --- a/examples/apparmor/libvirt-qemu
> +++ b/examples/apparmor/libvirt-qemu
> @@ -32,6 +32,7 @@
>    # libusb needs udev data about usb devices (~equal to content of
> lsusb -v)
>    /run/udev/data/c16[6,7]* r,
>    /run/udev/data/c18[0,8,9]* r,
> +  /run/udev/data/+usb* r,

This read-only access seems perfectly fine to me. +1

-- 
Jamie Strandboge             | http://www.canonical.com--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On 10/25/2017 02:42 PM, Christian Ehrhardt wrote:
> In bf3a4140 "virt-aa-helper: fix libusb access to udev usb data" the
> libusb access to properly detect the device/bus ids was fixed.
> 
> The path /run/udev/data/+usb* contains a subset of that information we
> already allow to be read and are currently not needed for the function
> qemu needs libusb for. But on the init of libusb all those files are
> still read so a lot of apparmor denials can be seen when using usb host
> devices, like:
>   apparmor="DENIED" operation="open" name="/run/udev/data/+usb:2-1.2:1.0"
>   comm="qemu-system-x86" requested_mask="r" denied_mask="r"
> 
> Today we could silence the warnings with a deny rule without breaking
> current use cases. But since the data in there is only a subset of those
> it can read already it is no additional information exposure. And on the
> other hand a future udev/libusb/qemu combination might need it so allow
> the access in the default apparmor profile.
> 
> Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
> ---
>  examples/apparmor/libvirt-qemu | 1 +
>  1 file changed, 1 insertion(+)
> 

ACKed and pushed.

Michal

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list