lucyllewy / one-script-wsl2-systemd

The one-script variant of the systemd hack for WSL2
MIT License
231 stars 38 forks source link

A note on AppArmor and WSL #25

Closed cerebrate closed 2 years ago

cerebrate commented 2 years ago

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

lucyllewy commented 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:

lucyllewy commented 2 years ago

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

cerebrate commented 2 years ago

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-execed 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.

lucyllewy commented 2 years ago

I installed a separate Ubuntu instance and checked the aa-status there - it was identical to the one inside the Systemd namespace.

cerebrate commented 2 years ago

Hm. That's odd. I'll poke at it some more.

lucyllewy commented 2 years ago

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 :-)