roddhjav
Please remove profiles affecting snapd
Snaps have a pretty elaborate and complex security subsystem and having a quick look at this repository, might be easily broken by uncoordinated changes. I think it's much better to remove the profiles in this repository (thank you for creating them) and submit them to the upstream snapd repository.
Snapd carries apparmor and selinux profiles for exactly the reason that maintaining them in separate repositories just doesn't work when you want to not break people in the wild.
I do agree that it would be better to simply upstream these profiles to snap directly. I even find it surprising that these profiles did not exist before.
Furthermore, there is currently an issue with snap and apparmor.d in general. As everything is confined, all dbus access works between confined processes (which is good). However, the generated profiles for snap app hardcore an unconfined peer label in dbus rules; breaking all dbus communication. The solution is to use variable for this. I should probably propose a PR on the snap project for this.
Meanwhile:
- While the profiles don't get merged in snap, I will not remove them from here, as it would break FSP.
- The snap profiles use a lot of resources developed in this project (abstractions & tunables, the dbus architecture, some directives. I am not sure if there is a will from upstream (both apparmor and snap) to move forward with it.
- Upstreaming these profiles would be the opportunity to improve them as well as the current internal resource; therefore, I am 100% behind this.
I think the shape of the profiles as they are now will change before they can be merged upstream. Snapd needs to continue to work on old debian and on future debian equally. I can help with that effort although I don't expect it to finish quickly.
Personally I don't quite see the value of FSP if it means software is just broken. It's a nice goal to strive for but it's always more realistic to say "it's not there yet". For as long as profiles live outside of the upstream projects, they will be both too wide and too narrow, allowing needless things and not allowing legitimately needed things.
One example is snap-repair, which periodically loads repair assertions and executes them as a last-resort fix for systems without human oversight and without human shell access. Right now that program is confined in a way that guarantees to break the tool. The tool is designed to authenticate and execute any payload. A shell script or a kernel module alike.
I don't intend to say everything about those profiles are wrong but I am trying to point out the level of complexity involved here. I think it'd be better not to ship any of those anywhere, as they are not used on the so-called "classic" distributions (as compared to the "core" ubuntu-core distribution).
It's entirely your project but I think a logical first step would be to see if we can move the more commonly used things, like the profile for "/usr/bin/snap" itself. I'm pretty sure it is also broken in subtle ways but having the discussion on https://github.com/snapcore/snapd/ would probably allow us to point out how and exercise it in our extensive test suite.
The current snap profile will work for all common snap operation (install, start, remove...). It even has tests for this (see tests/integration/snap.bats). However, I do agree that more advanced tasks have not been tested at all. I simply don't have the time nor the resources for more. I am planning to improve this shortly, but I agree working with upstream here the solution.
Meanwhile, you raised a good point regarding snap-repair and in general snap capabilities that mostly target Ubuntu Core (where we currently cannot install apparmor.d as it would require to change the core snap - I have tested this a while ago).
I will create an issue on the snapd project in launchpad to see where/how we can move forward with it.
Personally I don't quite see the value of FSP if it means software is just broken.
By design, FSP only applies to a well tested and validated system.
Thank you, please ping me with the issue you file on launchpad, I can help you out to make progress.
@zyga You can find the follow-up issue on https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/2103959. Btw, I am wondering either or not creating a "bug" is the best approach for this.