Hello, I am trying to get strict confinement to work in Revenge OS, which is based on Arch Linux. I would like to ship snap support by default in Revenge OS, and I really want it to work as intended, with strict confinement out of the box. In testing, I have compiled an Apparmor enable kernel (version 4.13.3), and I do have Apparmor running. I then built the package for Arch Linux from the Github release page (version 2.27.5-1). When building the snapd package, I removed the --disable-apparmor option.
However, when I try to run any snap package with this setup, I receive an error stating “snap-confine has elevated permissions and is not confined but should be …” From looking up others who have had this error it appears that there is no apparmor profile for snap-confine? I am seeking advice about how to proceed from here.
I forgot to mention, that without apparmor running snaps work as expected, running in devmode as in Arch Linux. Thank you for the work that you guys have done here!
To get strict confinement you need to get apparmor enabled on boot but also synchronize your /security/apparmor directory. You can look at @ikey’s work on Solus on how this can be done.
Snapd will detect the confinement at runtime. Running snap debug confinement should tell you strict rather than partial if you got that part right.
Unless you want to deviate from our recommended default location of the snap mount directory (/snap directory) you don’t have to change anything in snapd proper.
In packaging however you have to still do a few more things (those are not done by the arch package). You need to install the apparmor profile of snap-confine to /etc/apparmor.d and load it after installing the package. The profile should also automatically load on boot assuming that apparmor is doing its thing.
You may also need to (I don’t know really) look at changing apparmor to load generated profiles from /var/lib/snapd/apparmor/profiles. I know Ubuntu does this but I don’t know if this is in the upstream apparmor init system integration.
I wanted to introduce myself. I’m Jody James, lead developer of Revenge OS. Again, thank you so much for pointing me in the right direction and for all you guys have done here!
@zyga-snapd I’m now seeing this error when trying to run a snap:
/usr/lib/snapd/snap-confine: error while loading shared libraries: libudev.so.1: failed to map segment from shared object
I double checked that apparmor is loading the profiles from /var/lib/snapd/apparmor/profiles and we are using the default location of /snap for the mount directory. Do you happen to know what might be causing this error?
This sounds likes snap-confine's own apparmor profile not letting it load the libudev.so.1 shared library. There is a rule in the profile that should allow this, but perhaps the library is somewhere else on your system?
Ok, I’m sure that the issue is with the apparmor profiles. I fixed the issues with the shared libraries (it applied to all of them) by changing the paths in the snap-confine apparmor profile. Now I am getting this error:
cannot perform readlinkat() on the mount namespace file descriptor of the init process: Permission denied
The last entry in the log for the apparmor denial shows:
type=AVC msg=audit(1506612383.468:55): apparmor=“DENIED” operation=“capable” profile="/usr/lib/snapd/snap-confine" pid=1289 comm=“snap-confine” capability=19 capname=“sys_ptrace”
I’m sorry to keep bothering you guys. I will keep working to remedy the errors. Thanks again.
So, I’m curious, did you take the Ubuntu kernel apparmor patches and add them to Revenge OS or are you using the vanilla upstream kernel? EDIT: Because the profile is written for the patched kernel and will probably not work without some changes.
I’ve a very easy patch here you can nick for the 4.13 series kernel to apply to a stock kernel which will introduce the full AppArmor confinement required by snapd:
You can check our git history there and we also had 4.12 syncs that worked fine. They’re always in our files/security directory. You’ll need to make oldconfig && make menuconfig after to ensure all the relevant AppArmor options are now enabled.
No worries We also stripped down our apparmor package basically to purely serve snapd for now, feel free to prod (just search for apparmor from the same dev site I linked earlier)
Good luck - nice to see more distros embracing snaps
