Snap on 41 beta had issue (selinux policy I believe). Last time I checked after upgrade, it was still not resolved. Thoughts, in case I missed anything?
Thanks
Snaps rely purely on Apparmor for sandboxing. This makes them incompatible with distros not using AppArmor but SELinux, like Fedora and its downstreams.
There might be compatibility tools to make them work, but as not many devs work on Snaps here, I can imagine that issues occur here.
If you want to use Snaps, maybe use Ubuntu? Kinda bad tip I know
Thanks. It works great on RHEL 9.x and Fedora 40 for me. But yes, Ubuntu is always an option but I am sure I won’t have to switch to it as snap is not that critical but good to have.
Apparmor provides mandatory access control and not sandboxing, the same with SELinux. I don’t know much about snap except that it depends on systemd, and I don’t use it on Fedora, but I can exclude that it depends on the provision of any apparmor/selinux/mac.
Technologies like SELinux and AppArmor can break such sandboxing technologies when active, but not when disabled or absent at all 
SELinux (and I assume also AppArmor) can create an environment that achieves the same outcome (in terms of isolation/separation) as some types of sandboxing (I am a known lobbyist for that : ) , but it is not related to what we call today sandboxing.
But the emphasis of Fedora is obviously flatpak, and we don’t officially support snap.
That said, someone provides the package for fedora: it is in our default repo, including a selinux policy file. So I assume there is a way to use it. You might browse snap for incentives about comparable issues, maybe that already contains a solution.
Before assuming it is SELinux, you might try to disable SELinux permanently, reboot, and then test if the behavior is changed during the boot with SELinux disabled: if so, yeah, then we might file a bug to adjust the SELinux policy.
In any case, we need more data, logs, and/or behavior elaborations in order to help 
1 Like
I would rather set SELinux to permissive in /etc/selinux/config, or temporary by running sudo setenforce permissive. Running audit2why -b would then give the log information needed for further analysis.
1 Like
Don’t do that in this case. Especially with technologies that have deeply embedded dependencies and that are at the same time not officially supported (and thus not included in our massive testing), it is realistic that (if SELinux is the origin of the problem) SELinux has broken some dependency of snap earlier while no further denial is logged at the time snap breaks. This also means that if SELinux has broken something earlier, it will not make a difference to disable enforcing later in that boot: that data will thus be not reliable.
E.g., we had that with confinement in earlier versions of Plasma, in which SELinux broke something in plasma at the time of login while all buttons in plasma no longer worked: the only denial logged was at the time of logging in. Just an example. But if we want to ensure that this is really not related to SELinux without deep analysis of logs, we need a boot that is guaranteed to be free of unintended denials at all times.
If we find out that snap works fine when SELinux is not enforcing and not when SELinux is enforcing, then we have a strong indication and can go ahead with checking out related logs. But for now, I would just take the easiest way that gives a reliable feedback about SELinux relations.
That said, this can be achieved with disabling or permissive mode, but yeah, you are right that in case of a doubt permissive is the preferred practice.
I would prefer if we directly collect data as we can use it in the bug reports. The maintainer prefers the ausearch outputs, and I got used to them too. It’s generic for establishing a context for understanding of the issue. We might need to set them in contrast to journalctl outputs before filing a report, but for now, I would not emphasize any of that but just check out if SELinux is involved at all.
1 Like
It provides very similar output
[root@newbox ~]# ausearch -c '(r-launch)'
----
time->Thu Nov 7 13:01:45 2024
type=AVC msg=audit(1730980905.070:46): avc: denied { nnp_transition } for pid=935 comm="(r-launch)" scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tclass=process2 permissive=1
[root@newbox ~]# audit2why -b
type=AVC msg=audit(1730980905.070:46): avc: denied { nnp_transition } for pid=935 comm="(r-launch)" scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tclass=process2 permissive=1
Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to allow this access.
[root@newbox ~]#
and audit2why is easier for me to remember.
Snap documentation says that AppArmor (LSM) is one of the few things required for strong application confinement and isolation.
When a snap is installed, its metadata is examined and is used to derive AppArmor profiles, Seccomp filters and device cgroup rules, alongside traditional permissions. This combination provides strong application confinement and isolation
https://snapcraft.io/docs/security-policies#heading--permissions
Strict confinement uses security features of the Linux kernel, including AppArmor, seccomp and namespaces, to prevent applications and services accessing the wider system.
Snap confinement | Snapcraft documentation
That paragraph refers to maximizing security, so requirement for maximum possible security and not a requirement for snap to work. Snap is close to Ubuntu, and since Ubuntu and many other distributions use AppArmor, it refers to AppArmor rather than MAC in general. By the way, SELinux also uses LSM
Let’s assume there is a reason why someone maintains snap with selinux policies on Fedora, and that the user has already used it on F40. Therefore, it makes sense to verify if SELinux is the origin of the issue or not. Maybe the policies have not been updated for F41.
Supplement: I assume the issue is already known and solved: FEDORA-2024-27b46a426a — bugfix update for snapd — Fedora Updates System
The update - pushed to stable 3 days ago - contains this fix:
Cherry pick fix for SELinux timedatex problem from upstream
… and several people thanking for making snap finally work again
So dnf update --refresh & then a reboot should fix the problem. If not, the user is free to provide the asked information to work on the issue (along with dnf info snapd --installed output). Otherwise, I assume the issue is solved.
2 Likes
Nobody said anything about this, unless I misunderstood. It was said that AppArmor is necessary for sandbox, for application isolation.
The issue seems to be solved, but I would like to clarify the SELinux subject, if there is something I misunderstand or don’t know, it will be beneficial for me to correct it or learn something new.
https://wiki.archlinux.org/title/Snap#Confinement
As far as I understand from the figure above and the information at the links, for each snap package installed, an AppArmor profile is also generated for the installed package. This profile is loaded complain mode if the package is installed classic, or enforce mode if it is installed by default (that’s strict if I understand correctly). If the system’s LSM is not AppArmor or no LSM is available, the installed snap packages are unconfined, i.e. they have full system resource access like traditional RPM packages.
If the system has SELinux set as LSM and not AppArmor, does snapd create SELinux policies for each user application installed on the system?