There is a well-known trade-off between security lockdowns and a user's abiliy to
debug/inspect a system. The Linux kernel is finally fixing an old proc/mem security
bug which illustrates this trade-off nicely. The kernel will provide a mechanism,
so distros need to implement a policy according to their own security needs, to
restrict proc/mem access (it gives userspace RW access to processes memory).
This talk goes into the what, why and how of getting this bug fixed, with some policies
for plugging the long-standing hole for different use-cases, without breaking
debuggers or container supervisors.
This talk is based the Linux patch series [1] which is extending the /proc/*/mem access
controls beyond the normal file-based permissions, to restrict various access during
kernel builds (Kconfig level) or early boot via static/read-only key parameters. It
is expected to land in kernel v6.11, to be released in late Q3 / early Q4 2024.
The author is looking for opinions whether this should be backported to stable trees
since the patch is somewhere between a bugfix and a new feature.
[1] https://patchwork.kernel.org/project/linux-fsdevel/patch/20240613133937.2352724-2-adrian.ratiu@collabora.com/
Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/