Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
cmd/snapd-apparmor: only skip WSL without securityfs
Normally securityfs is mounted by systemd on startup. This is done on non-container systems. People that experiment with WSL and apparmor using a custom kernel would like to continue to use snapd this way, and to allow that we need to make our checks tighter. Earlier this code was refactored to do nothing on all WSL systems. With this change the behavior on default WSL kernels (with WSL2) is exactly the same. When non-default kernel is used, and when the user explicitly mounts securityfs by hand, then snapd.apparmor.service will load the profiles into the kernel as it does on typical systems. There's a known issue where this is not using apparmor namespaces, so one distribution container can load a profile that is visible and effective in another, but this is outside of the scope of snapd to configure. I've tested this with a locally-built Linux kernel from the Microsoft WSL kernel tree https://github.com/microsoft/WSL2-Linux-Kernel, with the following configuration: ``` CONFIG_SECURITY_APPARMOR=y CONFIG_DEFAULT_SECURITY_APPARMOR=y CONFIG_LSM="landlock,lockdown,yama,loadpin,safesetid,integrity,apparmor,selinux,tomoyo" ``` I've copied the resulting image to my Windows home directory and created `%USERPROFILE%/.wslconfig` file with the following contents: t ``` [wsl2] kernel=C:\\Users\\me\\bzImage ``` Then I've shut down and restarted WSL. Note that normally the released kernel version is 5.15.something. In the test below you can see 6.6.36 from my local build. ``` zyga@falka:/mnt/c/Users/me$ uname -a Linux falka 6.6.36.6-microsoft-standard-WSL2+ #2 SMP PREEMPT_DYNAMIC Mon Sep 23 16:06:53 CEST 2024 x86_64 x86_64 x86_64 GNU/Linux zyga@falka:/mnt/c/Users/me$ sudo mount -t securityfs securityfs /sys/kernel/security/ [sudo] password for zyga: zyga@falka:/mnt/c/Users/me$ sudo systemctl restart snapd.apparmor.service zyga@falka:/mnt/c/Users/me$ sudo systemctl restart snapd zyga@falka:/mnt/c/Users/me$ systemctl status snapd.apparmor.service ● snapd.apparmor.service - Load AppArmor profiles managed internally by snapd Loaded: loaded (/usr/lib/systemd/system/snapd.apparmor.service; enabled; preset: enabled) Active: active (exited) since Mon 2024-09-23 18:15:54 CEST; 10s ago Process: 523 ExecStart=/usr/lib/snapd/snapd-apparmor start (code=exited, status=0/SUCCESS) Main PID: 523 (code=exited, status=0/SUCCESS) Sep 23 18:15:54 falka systemd[1]: Starting snapd.apparmor.service - Load AppArmor profiles managed internally by snapd... Sep 23 18:15:54 falka snapd-apparmor[523]: main.go:141: Loading profiles [/var/lib/snapd/apparmor/profiles/snap-confine.snapd.x1 /var/lib/snapd/apparmor/pr> Sep 23 18:15:54 falka systemd[1]: Finished snapd.apparmor.service - Load AppArmor profiles managed internally by snapd. zyga@falka:/mnt/c/Users/me$ sudo snap install hello-world hello-world 6.4 from Canonical✓ installed zyga@falka:/mnt/c/Users/me$ hello-world Hello World! zyga@falka:/mnt/c/Users/me$ hello-world.evil Hello Evil World! This example demonstrates the app confinement You should see a permission denied error next /snap/hello-world/29/bin/evil: 9: /snap/hello-world/29/bin/evil: cannot create /var/tmp/myevil.txt: Permission denied ``` I've also adjusted unit tests to make the various cases clearer to understand. Fixes: https://bugs.launchpad.net/snapd/+bug/2081371 Signed-off-by: Zygmunt Krynicki <[email protected]>
- Loading branch information