Kernel Hardening - security-misc

Patrick · October 3, 2025, 8:40pm

In context of Screen Locker (In)Security - Can we disable these at least 4 backdoors? - #14 by arraybolt3 :

Consider enabling `panic_on_oom`

opened 08:18PM - 03 Oct 25 UTC

Context: https://forums.whonix.org/t/screen-locker-in-security-can-we-disable-th…ese-at-least-4-backdoors/8128/14 > As covered in [XScreenSaver Manual](https://www.jwz.org/xscreensaver/man1.html#15), the OOM killer may take out a process like the screen locker even though Magic SysRq is disabled; all that has to happen is one must actually run out of memory. (This could happen if someone is using the system remotely over ssh while the screen is locked, or if the screen become locked while a lot of browser tabs were open and one of them is consuming more and more memory.) There is no good way to disable the OOM killer (the documented solution is to disable memory overcommit, but that’s a problem because some security features rely on it (in particular AddressSanitizer attempts to allocate somewhere around 20 terabytes of virtual memory, at least with the way it’s currently used in kloak). The other alternative is to enable panic_on_oom, which will cause the entire system to crash if it runs out of memory. I think the latter sounds like a good idea - it allows memory overcommit to work, and prevents unlocking the screen. The only real danger is that it could print out debugging details to a virtual terminal upon memory exhaustion, it’s unclear whether or not this may contain sensitive info or not. But I think we disable printing kernel messages to the display anyway… Should we enable `panic_on_oom` to make sure that security features such as the screen locker, kloak, emerg-shutdown, etc. are not arbitrarily terminated when the system starts running out of memory?