I just finished getting working a classic snap for my python3 ZFS boot environment manager zedenv. While it seems to be working fine, I was wondering what the options might be if I wanted to confine my application.
My application will need access to
/boot, as well as possibly some other locations depending on the way the users system is setup. In addition to this it will need to be able to run the
zpool binaries from the host system, since they can’t be located in the snap itself, being from a filesystem and all.
Is containment not really intended for this kind of application that needs access to so many system resources, and should I just stick with the classic confinement? Or is it a possibility to confine something like this. After looking at the interfaces I didn’t see anything that supported access to certain files and directories.
I’d suggest stick with the classic confinement until the required access is implemented as an interface someday.
IMO any kind of application is possible except those that require running arbitrary command from the host (like Git frontend applications)
So if it’s specific commands it’s doable? How would I go about interfacing with the commands I need?
Also, is there any way to get access to certain host locations, if I know at the time of creating the snap?
I thought as much that it might be best to stick with the classic confinement, but just for curiosity’s sake, if I wanted to implement it how would it be done?
If they are specific commands you can always pack all of them into the snap if it isn’t then it’s not possible via current means.
If that’s possible there are no security benefits from the confinement, which is essentially not allowing apps to access random locations. There’re some interfaces that can set attributes to tweak the access scope (like
With some knowledge on Go and Apparmor rules, https://github.com/snapcore/snapd/commits/master/interfaces/builtin
Strictly confining a snap like this would be possible, but the access would require writes to /dev files for disks I assume, and therefore give your snap device ownership. One issue with classic snaps is that they don’t exist on all-snaps systems like Ubuntu Core, but zfs isn’t supported there yet AFAIK.
If you were interested to understand what specific accesses are required, you could run your snap in ‘devmode’, connecting relevant existing interfaces and then seeing what security policy denials remain.