There is a well-known trade-off between security lockdowns and a user's abiliy todebug/inspect a system. The Linux kernel is finally fixing an old proc/mem securitybug 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, torestrict 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 policiesfor plugging the long-standing hole for different use-cases, without breakingdebuggers or container supervisors.This talk is based the Linux patch series [1] which is extending the /proc/*/mem accesscontrols beyond the normal file-based permissions, to restrict various access duringkernel builds (Kconfig level) or early boot via static/read-only key parameters. Itis 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 treessince 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/about this event: https://cfp.all-systems-go.io/all-systems-go-2024/talk/9UVMR7/