kernel.sysrq = 0 with CL9

[oceanwave]

A long time ago I added the line to
/etc/sysctl.conf
# Disables the magic-sysrq key
kernel.sysrq = 0

On a new default CL9 system, this value appears to be 16 ?
/sbin/sysctl -a
shows
...
kernel.sysrq = 16
...

Should this still be added to /etc/sysctl.conf kernel.sysrq = 0 for best security of CL9 cpanel server?

[bogdan.sh]

The sysrq is not about the security, it's more on allowing various low-level commands regardless of the current state of the system. It can help debugging kernel side if something crashing or so.

The kernel.sysrq = 16 is default setting which allows 'some' sysrq functions.
Setting it to 1 will allow all functions which is very useful if server is crashing.

The sysrq = 0 disable all of them and you might do that.

[bogdan.sh]

The sysrq is not about the security, it's more on allowing various low-level commands regardless of the current state of the system. It can help debugging kernel side if something crashing or so.

The kernel.sysrq = 16 is default setting which allows 'some' sysrq functions.
Setting it to 1 will allow all functions which is very useful if server is crashing.

The sysrq = 0 disable all of them and you might do that.

[oceanwave]

Thanks very much.

Does this setting matter when you are looking at securing a server in a datacenter with a remote console where if the remote console is somehow compromised or someone plugs in a console even, setting this to 16 would allow them to bypass other security measures?

Beginner question: what would be a scenario where you would need to have kernel.sysrq set to 16 instead of 0 to recover? Would this only be important for example if you only had one kernel in the system (whereas CL by default will always maintain at least 1 previous kernel in case a kernel update goes badly)

[bogdan.sh]

The SYNC operation itself (value 16) only forces a filesystem sync - it doesn't allow for system reboots, dumps, or other potentially more dangerous operations.


Having kernel.sysrq = 16 (SYNC) would be most valuable in scenarios where you're experiencing system issues that prevent normal filesystem synchronization, but the system is still responsive enough to accept keyboard commands. Something like:

- You're experiencing heavy I/O load or filesystem issues
- The system is sluggish but still responding
- You want to ensure all cached writes are committed to disk before attempting other recovery steps