Hi All, I’m trying to set a linux capability on a binary that I’d like to ship as part of a ubuntu snap package.
I was able to run setcap as part of the override-prime step of the snap package generation, but observe that the capabilities aren’t persisted after installation. 
I also tried modifying the install hook to run the setcap command but that command wasn’t successful as the /snap/ directory is mounted read-only.
Any advise is helpful, thanks!
Capabilities give binaries a subset of roots power. The problem is, a lot of caps provide so much power that you can effectively become root with certain capabilities. This would weaken the sandboxing principles of snaps and so they’re philosophically incompatible to some degree.
What is definitely a blocker for snaps however is the fact that if a binary has a capability attached, ld; the system linker will not honour $LD_PRELOAD and $LD_LIBRARY_PATH (and presumably any libraries in the same location as the binary); this is because it would be trivial to create privilege escalation issues. The vast vast majority of snaps would simply break if they had capabilities set then as a result, unless they were entirely statically linked.
Because of the ld issues, it’s just not something that’s feasible. It might be worth asking if theres a way to do whatever you were using capabilities for to see if there’s any better way, but getting capabilities to work in snaps is something that is likely impossible on a technical level and undesirable on a design philosophy level.
@James-Carroll is correct in that setting capabilities on binaries in a snap is not allowed by policy/design in addition to technically speaking for squashfs implementation.
What is the specific capability your snap requires? Snaps can be granted capabilities via AppArmor profiles, etc. which correspond to interfaces that your snap can use.
@ijohnson, I’m only looking to enable CAP_DAC_OVERRIDE. My binary needs the ability to peek/poke files on system at root level (including $HOME). Is that possible via AppArmor?
Is there a reason you cannot use your snap with sudo, i.e. if your snap is called mysnap, just do sudo snap run mysnap?
Prefer not to run as root, or as sudoer with full root capabilities.
RPM’s supports preserving linux capabilities actually so surprised that snapcraft isn’t keeping parity.
Can you be more specific about what kind of file access your application needs?
I understand that RPM’s and traditional linux packaging may allow setting capabilities for executables, however that in and of itself is not a justification for allowing it in snaps, so we don’t currently allow binaries to have their capabilities set with xattrs.
Running a snap as root is not the same as running a traditional linux application as root (provided there is strict confinement with your distro) since the snap is confined by various Linux Security Modules like AppArmor. As such, there is a stronger security around running a snap via sudo than you would have otherwise, and as such we don’t recommend usage of CAP_DAC_OVERRIDE within snaps and instead just recommend the snap be run as root via sudo or otherwise.
This is a fine question, but I’d like to clarify that AppArmor cannot, by intentional design, give a process capabilities it does not already have. It allows/denies use of capabilities the process already has. Typically use of fscaps is to avoid the setuid/setgid bits being set (which gives the process all capabilities) but still allowing non-root users (ie, those who don’t normally have any capabilities) the ability to run something with the fscaps-specified capabilities. Put another way, today if a snap needs capabilities, it must start as root (to have the capabilities in the first place) and also plugs any interfaces it requires (to be allowed to use those capabilities).
So if I’m understanding this correctly, you are recommend that I deploy from snap as sudo BUT setup AppArmor to reduce my capabilities to only what’d be allotted to me under CAP_DAC_OVERRIDE?
Yes, you’ll need to use sudo for now and then use an interface that granted access to the files you need and CAP_DAC_OVERRIDE. You can use ‘snappy-debug’ to help you determine which interfaces to use. That said, there is only one interface that grants this that could be recommended: log-observe.
