Linux 5.17 Patch Can Help With Systemd-Less System Security, May Break Some Old Drivers

[phoronix]

Phoronix: Linux 5.17 Patch Can Help With Systemd-Less System Security, May Break Some Old Drivers

A decade old patch is set to be mainlined in the upcoming Linux 5.17 that has been carried by Google's Chrome OS kernel build for years and can help with security on Linux systems not relying upon systemd's udev...

https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.17-Devtmpfs-Change

[zbyszek]

systemd does NOT use noexec on /dev. It did for a while, but it stopped in 2020 because /dev/sgx requires PROT_EXEC to function.
See https://github.com/systemd/systemd/p...627664a8fd2b27 for details.
Quote from that commit:

pid1: stop making /dev noexec

Quoting Andy Lutomirski:
> The upcoming Linux SGX driver has a device node /dev/sgx. User code opens
> it, does various setup things, mmaps it, and needs to be able to create
> PROT_EXEC mappings. This gets quite awkward if /dev is mounted noexec.

We already didn't use noexec in spawn, and this extends this behaviour to other systems.

Afaik, the kernel would refuse execve() on a character or block device anyway. Thus noexec on /dev matters only for actual binaries copied to /dev, which requires root privileges in the first place. We don't do noexec on either /tmp or /dev/shm (because that causes immediate problems with stuff like Java and cffi). And if you have those two at your disposal anyway, having noexec on /dev doesn't seem important. So the 'noexec' attribute on /dev doesn't really mean much, since there are multiple other similar directories which don't require root privileges to write to.

[Vorpal]

This also breaks some old versions of yap (a prolog interpreter). I tried to get it working to reproduce an old scientific result a few months ago. It was mmaping /dev/zero as exec instead of using anonymous mmap (apparently that is a thing you could do!). So really this is a userspace abi break. But since it is behind an option I guess it is fine?

[trek]

We don't do noexec on either /tmp or /dev/shm. And if you have those two at your disposal anyway, having noexec on /dev doesn't seem important.

caveats on top of other caveats