Hi Matthew,
Thanks for joining this conversation. We’ve been investigating and gradually working our way through SELinux support, so it’ll be great to have more collaboration with someone that knows it inside out.
Although I’m much less experienced in SELinux than you are, my feeling is that the situation is brighter than it may feel – perhaps a side effect of being less bounded to the AppArmor details than you might imagine we are. In reality, the interface mechanism in snapd is meant to represent high-level intent, rather than file-level access information.
As a good example, we have that interface labeled network-control. That says nothing about which specific files will be accessible to that interface on a particular distribution. What’s represented there is the intent of handing to that application the needed access for manipulating the network stack of the system, whatever that turns out to mean locally.
As another good example, we have a serial-port interface which may be defined purely in terms of USB vendor and product IDs, and if you look purely from the apparmor perspective it allows quite a few options under /dev/tty*. But in fact this is restricted to a particular device via udev tagging and process cgroups, which resembles quite a bit the reality you’re describing where the process and the filesystem are tagged.
With those ideas in mind and as a preliminary suggestion of where to start, instead of trying to mimic perfectly the apparmor implementation, I’d suggest taking a higher level view of what each of these interface means and how the proper representation of them would look like in a SELinux universe. Yes, roles, domains, etc, may be different from distribution to distribution, but we should be able to easily map that out when really necessary, and in some cases we can use introspection techniques or other confinement mechanisms.
What gives me some assurance that this is not an unsurmountable amount of work is that we only need to that once for each interface, and the number of interfaces is orders of magnitude smaller than the number of applications. So, if is possible to map out application by application in the several distributions, we should be able to map out those interfaces too.
About it being fragile, yes, we need to be careful, and the infrastructure we have in place nowadays reflects that. Every single one of our PRs fires tests against 8 severs at the moment, on a matrix of Ubuntu 14.04, 16.04, 32bit, 64bit, and Ubuntu Core. We’re working right now to add Debian and Fedora to that set. Our interfaces have tests ensuring their high-level expectation is working across that matrix.
We can only claim SELinux support works on a particular distribution if that distribution is included in that suite, as that ensures we can keep them working over time both in terms of snapd changes and in terms of their own release cycles.
As a practical way forward, instead of bracing the world I suggest taking one interface at a time, and looking at how we might represent it in a particular distribution. It’s okay for it to not be a universal solution… we’ll get there eventually.