I assume you are referring to snippets such as this for the joystick interface: https://github.com/snapcore/snapd/blob/master/interfaces/builtin/joystick.go#L57-L63
To be clear, what you are suggesting is that AppArmor snippet would be removed entirely if used with an interface that disabled the device cgroup enablement? Do you think most applications would still work if that snippet was removed? Unfortunately I don’t have an explicit example I can run to see if a joystick container (for example) would still work properly if it didn’t have access to /dev/input/event[0-9]*
. I guess if the application is unlikely to work due to this denial then it doesn’t make much sense to do this kind of removal at all and we either would need another solution or just make the joystick interface entirely incompatible with this type of “device cgroup disabling” interface…
For reference, the initial list of interfaces for this snap that will be pluggable that currently enable udev tagging are:
- network-control
- bluetooth-control
- camera
- dvb
- gpio-memory-control
- gpio
- hardware-random-control
- i2c
- iio
- io-port-control
- joystick
- opengl
- optical-drive
- raw-usb
- serial-port
- spi
The interfaces I see that generic AppArmor /dev/...
snippets which also correspond to a stricter udev tagging rule seem to be:
- joystick (for
/dev/input/event[0-9]*
)
- serial-port
- raw-usb (for
/dev/tty{USB,ACM}[0-9]*
)
I don’t know how often these containers will read data from a joystick, so I’m okay with not connecting that interface for now if it’s not useful without the event access, however the serial-port interface is much more problematic as I don’t think you could use the interfaces at all without the access for /dev/tty...
patterns. What do you propose for handling those interfaces with this device cgroup “incompatibility” or “disabling” flag?
It seems that if the serial-port AppArmor snippet is only generic if the slot doesn’t specify usb attributes then a more specific path rule is used instead, which may be okay and in this case we could just require that:
if snap has device cgroup disabled
if slot doesn't have raw-usb attrs:
use specific device path in AppArmor
else:
fail
else:
do current logic
This would mean that the snap could only plug into certain serial-port slots rather than any serial-port slot which is undesirable. I think that ideally we would use hotplug here but my understanding is that work isn’t done yet.
As for the raw-usb, I don’t see a similar solution to reducing the coverage of /dev/tty{USB,ACM}[0-9]*
(because currently the udev rule restricts to only devices with ENV{ID_BUS}=usb
.