Sorry for taking so long to get back to you on this. > Alistair Young (2021-05-07): > > Specifically, systemd-detect-virt detects WSL as a container, > > technically accurately, but this then causes the apparmor.systemd > > script to decline to start apparmor. > > I'm trying to understand what's, at the end of the day, the desirable behavior > here, and why. > > I understand you would like apparmor.service to start in a WSL environment, > i.e. you would like the AppArmor policy to be loaded. > Correct so far?
Yes, exactly. > May I infer that a container run under WSL can actually load and enforce > AppArmor policy? Well, what I'm thinking of isn't containers under WSL so much as WSL being a container-but-not-really itself. To elaborate a bit on the WSL architecture, the ability to run multiple distributions (or instances of distributions) at the same time (and indeed later their support for GUI applications) is implemented through namespaces (mount, pid, and UTS); the root-level namespace runs whatever special code is responsible for starting up and shutting down the distributions-as-containers and we don't get access to that, and every distribution runs in a pid/mount/UTS namespace below that. Since running systemd (as pid 1) inside WSL requires yet another namespace, technically by the time we get to the systemd that's trying to initialize apparmor, we're about three namespaces deep. However, it definitely can load and enforce AppArmor policy, empirically speaking - I'm doing it. The thing that set me off down this road was trying to get snapd to run under WSL, as it uses AppArmor for confinement, and it's operating properly in this respect, as are other apparmor policies supplied in the relevant Debian packages. More, I think it makes sense to load and enforce AppArmor policies under WSL (as if it were not a container), because while it may technically fit the definition, namespace-wise, that's not how it's used. > In that case, IMO it would make much more sense to have > is_container_with_internal_policy return true (0) for WSL containers, rather > than tweaking apparmor.systemd to treat them as non-containers. I'm not familiar enough with the AppArmor code (or the securityfs that that function uses) to trust that I properly understand the nuances one way or another; what would be the difference in ultimate effect be, if any? For reference, having examined the function and what it checks, in "raw" WSL without a pid 1 systemd running or "outside" its namespace, the .ns_stacked and .ns_name files do not exist under /sys/kernel/security/apparmor; inside the systemd namespace, the .ns_stacked file contains "no" and the .ns_name file "root". Regards, Alistair
