☰

为什么 Magic SysRq 在某些系统上默认未启用？有风险吗？

tag-icon • tag-icon fedora rhel kernel oracle-linux magic-sysrq
为什么 Magic SysRq 在某些系统上默认未启用？有风险吗？

在对 Oracle Linux 6.3 服务器（RHEL 衍生版）进行故障排除时，我第一次尝试使用一些 Magic SysRq Key 命令。没有这样的运气，所以我不得不硬重启。当它恢复时，我检查了 SysRq 是否已启用......

> sysctl kernel.sysrq
kernel.sysrq = 0

但在我们的 Oracle Linux 7.2（RHEL 衍生版）系统上...

> sysctl kernel.sysrq
kernel.sysrq = 16

看着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

根据Fedora 的 Sysrq 质量保证：

普通 Fedora 和 RHEL 内核确实在编译时启用了此功能，但发行版默认情况下使用 sysctl.conf 在启动时禁用它。

在我们的所有系统上默认启用此功能似乎是个好主意。万一系统锁定，您至少可以半正常地将其关闭。

我的问题...

  1. 如果这是一个明显的好主意，为什么该功能在 6.X 中被禁用，并且在 7.X 中仅限于 filsystem 同步？
  2. 在我们所有的系统上kernel.sysrq设置是否存在任何风险？1

答案1

您可能不希望随机某个人走到键盘前重置机器，或者更糟糕的是，在不登录的情况下开始将寄存器、系统日志或所有任务打印到控制台。这是一个潜在的安全问题。

例如，我有选择地在连接到串行控制台集中器的数据中心硬件上启用它。我在我们的最终用户工作站上禁用它。

相关内容