We will ship apparmor 5 in snapd snap when we have confidence that there are no regressions. We are working on this together with the apparmor team.
2 Likes
ah just saw apparmor 4.1.6 got release, but i now understand it is waiting on apparmor 5ā got it appreciate yāall are ironing things out as much as possible <3
Just in answer to this. The snapd snap needs to be somewhat cautious about shipping apparmor versions. There are two main reasons for this. Firstly, since the same snapd snap is released across many versions of Ubuntu in support, so we need to ensure there arenāt regressions caused by version combinations between the kernel, the host distro, and snaps. Secondly, our install base includes very low-end IoT devices on Core, so we have to be careful about performance.
Our plan was somewhat delayed by some issues fixed in 4.1.3/4. Weāre now pushing to vendor 4.1.x into snapd 2.75, and v5 into snapd 2.76.
2 Likes
This is great news! I also saw apparmor 5 is at alpha-6 (although resolute still claims alpha-1; maybe its only the package name?).
Thank you so much for that update!
JFYI apparmor released its first beta for apparmor 5 (after 6 alpha releases; https://gitlab.com/apparmor/apparmor/-/wikis/Release_Notes_5.0.0-beta1). It has a caveat to distros using 5.0 vs 5.1
I am not sure if it is also directed towards Ubuntu OS usage and usage in the snap or not. Canonical people probably know.
Apparmor 4 seems to shake out bugs, 4.1.5 fixes python compatibility and regressions still related to getting unprivileged user namespaces right (4.1.6 fixes an regression introduced by 4.1.5).
Could someone explain what this and above requests mean in practice? Could these changes allow other than Ubuntu Linux distribution finally use snapd and snap packages on same confinement and security / OOTB convenience levels as in Ubuntu? Something else entirely?
I am actively working on integrating both 4.x and 5.x into snapd. This is complex as apparmor 4.x has had some regression (now mostly fixed) and apparmor 5 is neither ready upstream nor downstream in snapd.
In the end we should have good sandboxing on any system using upstream kernels but this is likely a 26.10 goal.
So simply put, this will mean that distros that recently dropped the snapd and sna snap packaging entirely recently (Solus, KDE Linux and so on) because of messy structure, permissions, AppArmor problems and so on, can reconsider snapd in future?
It is unbelievable to me that even though Snapcraft page has comprehensive instructions on how to add snapd to use snap packages on a chose distro other than Ubuntu, the experience is sub par and filled with warning, error messages and so on to this date.
Shipping snapd is not very difficult. We are working on making it more consistent across distributions by improving snapd.mk and calligraphy that from packaging scripts.
As for confinement this has been a long running quest to improve the state of apparmor in the upstream kernel and in distributions using it.
Now about removal or re-intrroduction it is hard for me to say. I donāt have the bandwidth to keep a close eye on all of the distributions (big and small).
We spent some time on the ability to reuse the language of appamror profiles on non-apparmor systems (e.g. selinux) but this effort is long and slow.
The bottom one is that anyone can ship or not ship snapd whenever they want. At most we can improve the code to make technical decisions easier.
1 Like
Speaking of KDE Linux, Iām sad that they dropped Snap mainly because itās in AUR and not in the official repos. Any ideas if itāll ever get there?
It seems it would need a Arch repo packager to invest the time into maintenance.
the only criterion for introducing new (redistributable) packages in the Arch repos is having a packager willing to maintain it. And I highly doubt any of them would find a third party distro needing a package a compelling reason to invest their time in maintaining it, particularly for packages which are not useful in Arch (calamares, steam-devices-git) or are frowned upon (snapd).
https://invent.kde.org/kde-linux/kde-linux-packages/-/merge_requests/69
Packaging snapd as a flatpak might work instead?
FWIW, I maintain snapd in AUR, but Iām not sure Iād be willing to invest time and energy in getting it into extra. Iāve been using Arch long enough (since 2003/2004) to have my own reasons for not getting involved or trying to become a maintainer even for the extra repository.
Just an update to those subscribed. The information we got was that apparmor 5 will be included in snap 2.76 which is supposed to arrive May 18th in beta.
What is certain is that AppArmor 5.0 got released and Zyga has some snapd branches using apparmor 5. It did not arrive in the official snapd repository though.
There is cleanup/polishing work going on on AppArmor 5 (e.g. reenabling features, updated profiles) and AppArmor 4.1 (which gets vendored in snapd currently). To me it seems that AppArmor 5 might be stable enough to rely on it in snapd
There is no commitment to content for snapd 2.76 in the roadmap (content will be shared closer to release), so just lets hope for the best. The followup snapd milestones (>=2.77) seem to be syncing milestones with the ubuntu 26.10 release.
thereās been a lot of discussion about vendoring the user space AppArmor utilities into the snapd snap, but this topic was originally about the requirement for kernel-side patches that arenāt in the upstream kernel.org source tree. I still donāt think any of the mentions of vendoring have even come close to actually resolving that, and the only, question posed at the top of the thread.
edit to fix autocorrect errors (Iām on my Mac right now)
Hi OP, I guess you have been out of the loop for a while? Or I misunderstood. As far as I know all necessary kernel changes have been upstreamed (its somewhere in the thread) a while ago. But for non-ubuntu distributions, the user space and policies need to be adapted to the upstreamed changes (using a new ABI). We got the information from the snapd team that would be the case with AppArmor 5.
So regarding the original topic, my understanding it this is solved, but it does not help anybody (yet).
1 Like
I saw that 4.1.7 made it into 2.75, now 2.76 seems to be frozen with just a minor apparmor update. Anyway i thought that would be just a good way to fast track apparmor 5 usage.
But as resolute already ships with apparmor 5, I guess switching snap to use the system apparmor and checking the sandbox capabilities on a resolute with stock kernel should prove or disprove that this issue is solved. Could anybody try? I probably wont be able to check for the next two months.
On the other hand maybe the ubuntu kernel on resolute does not have the special sauce anymore? That should be also enough proof for Solus and others.
Indeed, if you use the deb version of snapd on resolute, you get the 7.0 kernel, and apparmor v5.
We continue to vendor 4.1.x in the snap. There is a v5 point release with fixes for regressions due out shortly. Sadly it missed the train for 2.76.
@zyga plans to begin testing this for inclusion in snapd 2.77 in the next few weeks. Weāre also expecting a small amount of work to update profiles for the new v5 ABI.
However, there are some major features which we gain access to in v5 which will require more substantial work to support nicely in our security model, which would follow later.
2 Likes
With snap 2.77 apparmor 5 is vendored in the snap and the new API gets used in both the snap and the debian package, does that mean everything is in place now that other distributions (like solus) are able to provide full confinement with mainline kernel?
Even if the kernel bits are all in, Solus does not enable AppArmor support in DBus:
Just tested snap v2.77 with Solus, I managed to make it do strict confinement:
$ snap version
snap 2.77
snapd 2.77
series 16
solus 4.9
kernel 7.1.8-352.current
architecture amd64
$ snap debug confinement
strict
$ snap run hello-world
Hello World!
$ snap debug sandbox-features
apparmor: kernel:caps kernel:dbus kernel:domain kernel:domain:attach_conditions kernel:file kernel:io_uring kernel:mount kernel:namespaces kernel:network_v8 kernel:network_v9 kernel:policy kernel:policy:permstable32:prompt kernel:policy:unconfined_restrictions kernel:policy:versions kernel:ptrace kernel:query kernel:query:label kernel:rlimit kernel:signal parser:allow-all parser:cap-audit-read parser:cap-bpf parser:include-if-exists parser:io-uring parser:mqueue parser:mqueue-posix parser:prompt parser:qipcrtr-socket parser:unconfined parser:unsafe parser:userns parser:xdp policy:default support-level:full
configfiles: mediated-configfiles
confinement-options: classic devmode strict
dbus: mediated-bus-access
kmod: mediated-modprobe
ldconfig: mediated-ldconfig
mount: layouts mount-namespace per-snap-persistency per-snap-profiles per-snap-updates per-snap-user-profiles stale-base-invalidation
seccomp: bpf-actlog bpf-argument-filtering kernel:allow kernel:errno kernel:kill_process kernel:kill_thread kernel:log kernel:trace kernel:trap kernel:user_notif
symlinks: mediated-symlinks
udev: device-cgroup-v2 device-filtering tagging
Unfortunately, I did have to add one patch (which Iām not sure is correct) to make it work, otherwise Snap still complains:
AppArmor status: apparmor is enabled but some kernel features are missing: network
So it seems like snapd still wants the old kernel:network feature for some reason?
1 Like