AppArmor Support

[amartin3225]

Is your feature request related to a problem? Please describe.
I cannot launch applications which rely heavily on AppArmor (particularly snaps). Attempts to start AppArmor fail as follows (e.g. on Ubuntu 22.04):

# aa-status
apparmor module is not loaded.
# systemctl status snapd.apparmor.service
● snapd.apparmor.service - Load AppArmor profiles managed internally by snapd
     Loaded: loaded (/lib/systemd/system/snapd.apparmor.service; enabled; vendor preset: enabled)
     Active: inactive (dead)
  Condition: start condition failed at Tue 2022-08-09 14:56:30 CDT; 49s ago
             └─ ConditionSecurity=apparmor was not met

Describe the solution you'd like
Now that this MR has been merged into AppArmor, it should have native support for running in WSL. What needs to be done on the WSL side to enable AppArmor?

Describe alternatives you've considered
The only alternative is to use apps that do not rely on AppArmor which is not ideal.

Additional context
Is there an ETA for when AppArmor will be supported in WSL2 or a workaround until it will be ready? Thanks!

[logan9t8]

The Microsoft built kernel isn't compiled with AppArmor support enabled.

# CONFIG_SECURITY_APPARMOR is not set

A workaround would be to compile it yourself with AppArmor support enabled

CONFIG_AUDIT=y
CONFIG_SECURITY_APPARMOR=y

and AppArmor enabled. Either in the kernel itself

CONFIG_LSM="landlock,lockdown,yama,integrity,apparmor,bpf"

or in the userland as a kernel parameter.

lsm=landlock,lockdown,yama,integrity,apparmor,bpf

Or you could simply acquire a kernel compiled with AppArmor support.

Either way, the configuration for using custom kernel and kernel parameters is set at C:\Users\<UserName>\.wslconfig.

kernel=C:\\path\\myCustomKernel
kernelCommandLine = lsm=landlock,lockdown,yama,integrity,apparmor,bpf

[WSLUser]

You'll find that snap still won't work with enabling AppArmor as Ubuntu has custom kernel patches which aren't getting included in the WSL2 kernel repo. See https://github.com/diddlesnaps/WSL2-Linux-Kernel or even better https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/jammy/commit/security/apparmor/, which has more up to date code you can copy over into the WSL2 kernel before compiling. Keep in mind @diddlesnaps hasn't created a 5.15 branch yet so if you use his custom kernel, you'll still be on 5.10.

[amartin3225]

Thanks for the guidance. Is there an explanation for why the Microsoft kernel is compiled without AppArmor support, and if that is planned to change at some point in the future?

[tyhicks]

Thanks for the guidance. Is there an explanation for why the Microsoft kernel is compiled without AppArmor support, and if that is planned to change at some point in the future?

Because major Linux Security Module (LSM) stacking and LSM namespacing is not supported in the Linux kernel. Enabling AppArmor would prevent SELinux or SMACK from being enabled, in the future, until LSM stacking is available. A lack of LSM namespacing would mean that the security policy would have to be implemented within the WSL management environment.

AppArmor alleviates the lack of LSM namespacing by implementing its own internal namespacing but AppArmor cannot be stacked with another LSM.

[amartin3225]

Thanks for the clarification. It seems like progress is being made, albeit slowly, on LSM stacking support, but it may still be quite some time before a solution is fully implemented.

In the interim, would it be possible to offer multiple official kernels, one with each major LSM enabled, and then users could choose in their wslconfig which one they want? This way if a user has a specific use case for AppArmor in their WSL, they could enable it, and similar for SELinux and SMACK. This would be parallel to how it works on a native Linux installation, where you choose which LSM to use (or the distribution developers choose for you).

[iavael]

@amartin3225 it's not required to have multiple kernels, since all LSM can be compiled in. The problem that some of them cannot be enabled simultaneously, so different distros have to be launch with different kernel cmdlines.

@tyhicks maybe it will be a good enough solution to compile in apparmor and selinux support, but not enable them at boot time automatically so that users can enable them manually via existing kernelCommandLine option in wslconfig.

[amartin3225]

@tyhicks maybe it will be a good enough solution to compile in apparmor and selinux support, but not enable them at boot time automatically so that users can enable them manually via existing kernelCommandLine option in wslconfig.

That sounds ideal

[WSLUser]

Ideally the WSL2 kernel will gain official module support so it can support the use of =m. This would solve the problem here (along with other ones). You are capable yourself of doing this yourself when you compile but MS does not support it officially.

[tyhicks]

@tyhicks maybe it will be a good enough solution to compile in apparmor and selinux support, but not enable them at boot time automatically so that users can enable them manually via existing kernelCommandLine option in wslconfig.

Even then, the security policy will be loaded from within the containers themselves, which isn't likely to work well and will break the container manager.

Ideally the WSL2 kernel will gain official module support so it can support the use of =m. This would solve the problem here (along with other ones). You are capable yourself of doing this yourself when you compile but MS does not support it officially.

The module support topic is orthogonal to LSM stacking. LSMs can't be compiled as modules today.

[WSLUser]

LSMs can't be compiled as modules today.

I didn't realize that. Hope that changes so we can have more than one at our disposal to switch between on the fly. Obviously ideally we'd be able to enable them all without any conflicts through priority levels or something.

[soredake]

@kelsey-steele Hi! I've seen that you've fixed #8302, can you look at this issue too, please?