Raw-usb access to /sys/devices/platform/usb**

snapd
1

Good day.

I have a additional AppArmor rule to be added, I am running Ubuntu Core on a iMX8 device, with a USB3.0 controller. I have a udev rule that will disconnect/unbind the ftdi_sio driver from a FTDI device, that the FT2DXX library can access it.

I have connected the “raw-usb” interface on the respective snap app.

AppArmor is denying access through the /sys/devices/platform/usb@xxxx/… path. I have then manually modified the Apparmor rule file and added /sys/devices/platform/usb** r, which then the FTD2XX library have access to the FTDI device and do it’s stuff.

Some logs for details:

Sep 08 11:54:42 imx8dev1 audit[7962]: AVC apparmor="DENIED" operation="open" profile="snap.testapp.main" name="/sys/devices/platform/usb@38200000/38200000.dwc3/xhci-hcd.0.auto/usb1/busnum" pid=7962 comm="dotnet" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Sep 08 11:54:42 imx8dev1 audit[7962]: AVC apparmor="DENIED" operation="open" profile="snap.testapp.main" name="/sys/devices/platform/usb@38200000/38200000.dwc3/xhci-hcd.0.auto/usb1/1-1/1-1.3/busnum" pid=7962 comm="dotnet" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Sep 08 11:54:42 imx8dev1 audit[7962]: AVC apparmor="DENIED" operation="open" profile="snap.testapp.main" name="/sys/devices/platform/usb@38200000/38200000.dwc3/xhci-hcd.0.auto/usb1/1-1/1-1.1/busnum" pid=7962 comm="dotnet" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Sep 08 11:54:42 imx8dev1 audit[7962]: AVC apparmor="DENIED" operation="open" profile="snap.testapp.main" name="/sys/devices/platform/usb@38200000/38200000.dwc3/xhci-hcd.0.auto/usb1/1-1/busnum" pid=7962 comm="dotnet" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Sep 08 11:54:42 imx8dev1 audit[7962]: AVC apparmor="DENIED" operation="open" profile="snap.testapp.main" name="/sys/devices/platform/usb@38200000/38200000.dwc3/xhci-hcd.0.auto/usb2/busnum" pid=7962 comm="dotnet" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Sep 08 11:54:42 imx8dev1 audit[7962]: AVC apparmor="DENIED" operation="open" profile="snap.testapp.main" name="/sys/devices/platform/usb@38200000/38200000.dwc3/xhci-hcd.0.auto/usb1/1-1/1-1.1/1-1.1.1/busnum" pid=7962 comm="dotnet" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Sep 08 11:54:42 imx8dev1 audit[7962]: AVC apparmor="DENIED" operation="open" profile="snap.testapp.main" name="/sys/devices/platform/usb@38200000/38200000.dwc3/xhci-hcd.0.auto/usb2/2-1/busnum" pid=7962 comm="dotnet" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Sep 08 11:54:42 imx8dev1 audit[7962]: AVC apparmor="DENIED" operation="open" profile="snap.testapp.main" name="/sys/devices/platform/usb@38200000/38200000.dwc3/xhci-hcd.0.auto/usb1/busnum" pid=7962 comm="dotnet" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Sep 08 11:54:42 imx8dev1 audit[7962]: AVC apparmor="DENIED" operation="open" profile="snap.testapp.main" name="/sys/devices/platform/usb@38200000/38200000.dwc3/xhci-hcd.0.auto/usb1/1-1/1-1.3/busnum" pid=7962 comm="dotnet" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Sep 08 11:54:42 imx8dev1 audit[7962]: AVC apparmor="DENIED" operation="open" profile="snap.testapp.main" name="/sys/devices/platform/usb@38200000/38200000.dwc3/xhci-hcd.0.auto/usb1/1-1/1-1.1/busnum" pid=7962 comm="dotnet" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Sep 08 11:54:42 imx8dev1 audit[7962]: AVC apparmor="DENIED" operation="open" profile="snap.testapp.main" name="/sys/devices/platform/usb@38200000/38200000.dwc3/xhci-hcd.0.auto/usb1/1-1/busnum" pid=7962 comm="dotnet" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Sep 08 11:54:42 imx8dev1 audit[7962]: AVC apparmor="DENIED" operation="open" profile="snap.testapp.main" name="/sys/devices/platform/usb@38200000/38200000.dwc3/xhci-hcd.0.auto/usb2/busnum" pid=7962 comm="dotnet" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

Is there a way for maintainers to add this rule to the snapd apparmor ruleset, I believe that this will avoid further headaches with other USB3 devices on iMX8 and similiar.

BR

2

these errors are all for read operations, have you tried using and connecting the hardware-observe interface ?

# files in /sys pertaining to hardware (eg, 'lspci -A linux-sysfs')
/sys/{block,bus,class,devices,firmware}/{,**} r,
3

Hello,

Useful piece of information, I will test again with the hardware-observe interface and see if it resolves my issue.

BR

4

Hello, Turns out that adding the hardware-observe interface resolved my issue.

Thanks

1 Like