Closed cerebrate closed 2 years ago
Sorry about the delay in getting to this. I will try to work on implementing this tomorrow in a Twitch stream. Thanks for letting me and others know about the issue. 💜
Notes for self during stream:
Hi Alistair,
I've implemented the changes as close as I could determine from reading the genie source. I'm not sure I've got it right, as profiles still seem to be leaking. Could you check my code and see if you can see any problems with my implementation that are causing it to not be correct?
https://github.com/diddledani/one-script-wsl2-systemd/tree/apparmor-namespace
The code looks fine to me on first look, alas.
This is probably too obvious, but how are you detecting the leakage? If I look at AppArmor profiles from outside the bottle, or from another distro, I can still see them --
pallas:/proc# aa-status
apparmor module is loaded.
113 profiles are loaded.
77 profiles are in enforce mode.
:genie-Debian:/snap/core/13308/usr/lib/snapd/snap-confine
:genie-Debian:/snap/core/13308/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
:genie-Debian:/usr/bin/evince
:genie-Debian:/usr/bin/evince-previewer
:genie-Debian:/usr/bin/evince-previewer//sanitized_helper
:genie-Debian:/usr/bin/evince-thumbnailer
...
etc., etc., but none of those profiles will be enforced in that distro because they're inside the genie-Debian
AA namespace and only affect things explicitly placed into it with aa-exec
(or those processes' children), so if that's what you're seeing, that's expected behavior.
It's only the ones that look like:
apparmor module is loaded.
113 profiles are loaded.
77 profiles are in enforce mode.
/snap/core/13308/usr/lib/snapd/snap-confine
/snap/core/13308/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
/usr/bin/evince
/usr/bin/evince-previewer
/usr/bin/evince-previewer//sanitized_helper
/usr/bin/evince-thumbnailer
...
without a namespace prefix (as reported from inside the systemd bottle which we aa-exec
ed into that namespace) that'll actually be enforced.
Sorry if you knew all that, but it wasn't obvious to me on first cut, so I had to ask.
I installed a separate Ubuntu instance and checked the aa-status
there - it was identical to the one inside the Systemd namespace.
Hm. That's odd. I'll poke at it some more.
Looks like I was wrong. The profiles aren't leaking - the issue was I already had leaked profiles before I restarted the distro with the patch so they stayed leaked. After a full shutdown of wsl2 everything is hunky dory :-)
Just a quick note to let you know that I've had a patch accepted into AppArmor (and have a similar one awaiting review for snapd) to support running under WSL:
https://gitlab.com/apparmor/apparmor/-/merge_requests/812
As suggested in the comments there, there's a potential issue with AppArmor profiles leaking from distro to distro and/or from container to container because of WSL's architecture, so to avoid this problem in genie, I've arranged for it to create an AppArmor namespace before starting systemd (if AppArmor support is detected in the kernel) to prevent potential leakage.
Thought I'd let the other authors of WSL systemd hacks know in case you wish to take similar measures. In case it might be useful, my implementation of this can be found here, called from here.
Regards,
Alistair genie developer