11

While troubleshooting a Oracle Linux 6.3 server (RHEL Derivative) I tried to use some of the Magic SysRq Key commands for the first time. No such luck so I had to hard reboot. When it came back up I checked if SysRq was enabled...

> sysctl kernel.sysrq
kernel.sysrq = 0

But on our Oracle Linux 7.2 (RHEL Derivative) systems...

> sysctl kernel.sysrq
kernel.sysrq = 16

Looking at the Kernel Documentation for sysrq:

0 - disable sysrq completely
1 - enable all functions of sysrq
>1 - bitmask of allowed sysrq functions (see below for detailed function
description):
     2 =   0x2 - enable control of console logging level
     4 =   0x4 - enable control of keyboard (SAK, unraw)
     8 =   0x8 - enable debugging dumps of processes etc.
    16 =  0x10 - enable sync command
    32 =  0x20 - enable remount read-only
    64 =  0x40 - enable signalling of processes (term, kill, oom-kill)
   128 =  0x80 - allow reboot/poweroff
   256 = 0x100 - allow nicing of all RT tasks

According to Fedora's QA for Sysrq:

Stock Fedora and RHEL kernels do have this functionality enabled at compile-time, but the distributions disable it at boot time, by default, using sysctl.conf.

Enabling this functionality by default on all of our systems seems like a good idea. On the off chance a system locks up, you can at-least semi-gracefully shut it down.

My questions...

  1. If it's such an obviously good idea, why is the feature disabled in 6.X, and restricted to just filsystem syncs in 7.X?
  2. Are there any risks in setting kernel.sysrq to 1 on all of our systems?
Caesar Kabalan
  • 213
  • 2
  • 5

1 Answers1

3

You might not want to have the ability for some random person to walk up to the keyboard and reset the machine, or even worse, start printing registers, syslog or all tasks to the console, all without logging in. Its a potential security issue.

I selectively enable it, for example, on hardware in our datacenter hooked up to a serial console concentrator. I disable it on our end user workstations.

jsbillings
  • 24,006
  • 6
  • 56
  • 58
  • Thanks for your response. I've accepted it as the answer. In the context of this question the console is a VM console, but you're right, it gives someone who doesn't have a system login to gain access in some way to control the system (log output, reboots, etc) and is a security risk. – Caesar Kabalan Sep 12 '16 at 04:33
  • Why is rebooting then allowed by default? – neverMind9 Apr 19 '18 at 09:47
  • Probably due to the principal of least astonishment. I turn it off on kiosk systems. Reboot safely restarts the computer (or at least tries) while the sysrq reset does not. – jsbillings Apr 19 '18 at 12:17