Udev backend in snapd


#1

Hi guys
I didn’t find something related to udev backend in the doc, so I wrote it down here. Please correct me if I was mistaken at some point below.
We have several security backends implemented in snapd, including apparmor, seccomp, kmod. And udev is one of those backends that provides most interfaces the capabilities of access restrictions for some sort of devices(/dev/tty, /dev/fb0, /dev/video0, etc). When a plug and a slot with the same interface name are connected, a udev rule will be added to ‘/etc/udev/rules.d/70-snap.[snap-name].[app].rules’ and corresponding udev devices will be tagged and recorded in udev rule entries. An example of udev tagging for framebuffer is

 const udevRule = `KERNEL=="fb[0-9]*", TAG+="snap_<snap_name>_<app>"

When launching an app, the context(snap-confine) it runs will search the udev database for any devices with matching tag, setup device cgroup and add device nodes to it.

Here is a bug filed on launchpad that currently we have tagged udev devices for a few snapd interfaces(A) but for many other snapd interfaces(B), we don’t. When a snap contains a combination of an interface from A and an interface from B, a device access denial issue occurs since we only have tagged device nodes for the interface from A in the generated udev ruls.

I started working on this recently. A PR can be found here. There are still a few remaining interfaces that need to be done. They will be covered in a separated PR.

Thanks
Gary.Wzl


#2

Udev backend is slightly different from say apparmor or seccomp is that the effective confinement is optional and depends on the number of devices that are actually associated with the snap in question.

If the number of devices is zero then no device control group is created or joined and all access to /dev is mediated by apparmor based on the path alone. If any devices are tagged a cgroup is created and appropriate devices are placed into it. At that stage apparmor is not really the main confinement machine as kernel will prevent the process from using any other device major:minor numbers even if apparmor would allow it in the first place.

There is a problem today that some interfaces allow device access by apparmor paths alone and those interfaces break when used in conjunction with any udev-tagging interface.

As for your branch I will review it along with @jdstrand, thank you for taking the effort!


#3

As @zyga said, the udev backend is a little different and it isn’t detailed that doc (maybe it should be). It is documented here: https://github.com/snapcore/snapd/wiki/snap-confine-Overview