systemd (enabled the new way) does not mount securityfs filesystem even if AppArmor, etc., are enabled in the kernel

[cerebrate]

Version

Microsoft Windows [Version 10.0.22000.856]

WSL Version

• WSL 2
• WSL 1

Kernel Version

5.15.62.1-20220904-1-microsoft-custom-WSL2+ (from WSL2-Linux-Kernel source, adding AppArmor to .config and snapd AppArmor patches)

Distro Version

Debian bookworm/sid

Other Software

No other software.

Repro Steps

1. If present, remove existing systemd-enabling solutions.
2. Enable systemd in WSL as per blog post, adding to /etc/wsl.conf:

[boot]
systemd=true

3. Shut down and restart WSL.
4. Observe that AppArmor is not operative and no filesystem is mounted at /sys/kernel/security

Expected Behavior

Securityfs should be mounted at /sys/kernel/security, thus (output from mount):

securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)

as it is automatically mounted if any LSM is present in the kernel by current systemd releases.

Actual Behavior

No filesystem is mounted at /sys/kernel/security.

Diagnostic Logs

No response

[benhillis]

@cerebrate - I was wondering how long it would be until you filed your first issue on our systemd support :). Thanks for being a great member of the community!

With native Linux, who is responsible for doing this? Is this getting skipped because we're launching systemd in "container mode?"

[cerebrate]

Heh. Always happy to contribute relentlessly, and I'll probably have a couple more to file on the morrow. :)

In native Linux, systemd itself takes responsibility for mounting an assortment of "API filesystems". There's a table of them here in the systemd source:

https://cgit.freedesktop.org/systemd/systemd/tree/src/core/mount-setup.c#n70

And it does look like this is because of container mode; a variety of these filesystems are flagged as MNT_IN_CONTAINER and securityfs is notably not one of those. Also, now that I look at the table and check, it's also stopping the pstore filesystem from auto-mounting for me.

It's a slightly irritating one to work around, as systemd also prevents you from having a mount unit for any of those API filesystems, but at least in securityfs's and AppArmor's case, I can fake it with a service unit that runs early enough:

[Unit]
Description=Kernel Security File System
DefaultDependencies=no
Before=sysinit.target
Before=apparmor.service
ConditionSecurity=apparmor
ConditionPathIsMountPoint=!/sys/kernel/security

[Service]
Type=oneshot
ExecStart=/bin/mount -t securityfs -o nosuid,nodev,noexec securityfs /sys/kernel/security

[Install]
WantedBy=sysinit.target

I don't know if other LSMs would let me get away with this, though.

[cerebrate]

Still occurs under 0.68.2. Same workarounds work.

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!