3 ms·

Ah, thank you! I use SysRq to REISUB my machine — but I haven't found the SysRq key on Macbook keyboards; and haven't had the nerve to enable SysRq on friend's

Ah, thank you! I use SysRq to REISUB my machine — but I haven't found the SysRq key on Macbook keyboards; and haven't had the nerve to enable SysRq on friend's computers (which I often end up troubleshooting), since I didn't know much about it, what the security implications are, and whether 1 is an advisable value for kernel.sysrq Those sysctl options could make a big difference; I've wondered about something like that, but assumed the optimal default was built in. Thank you! I'll try tinkering with those values.

LinuxBender 4y ago
There was a time I found some organizations to be paranoid about enabling it because it was mentioned in either CIS or NIST hardening but it ignores the fact that the same information can be gathered with other tools so I suppose it depends on if you have to follow a standard that still says sysrq is a risk and if your SOC1/SOC2 documentation refers to those standards as part of your audits. But in reality if that were a risk then there are a myriad of other things that would have to be disabled as well and some of those things require recompiling the kernel to disable. I am referring to the attack vector of root applications sending magic sysrq codes into /proc/sysrq-trigger From a physical access attack vector sysrq specifically involves the Evil Maid attacks. Disk encryption, signed UEFI installations, BIOS/Firmware passwords and disabling booting from USB ports can reduce this risk a little if that is a concern. It depends on how one manages their systems and what remote management cards they have either built into the motherboard or added to the system. If disks are not encrypted then people can just power off the system and boot up on a USB drive or just steal the disks.