View previous topic :: View next topic |
Author |
Message |
curmudgeon Veteran

Joined: 08 Aug 2003 Posts: 1745
|
Posted: Sun Mar 30, 2025 1:05 pm Post subject: Limiting access to SysRq |
|
|
On a machine that I manage, one user has just discovered the Alt+SysRq+F sequence, and has used it to kill programs of other users (something I most definitely do NOT want). It surprises me somewhat that SysRq apparently has no access controls or restrictions on which programs SysRq can kill. Does some way exist to restrict certain users from running SysRq sequences, or do I just have to disable SysRq completely (and hope that I can reenable it by writing to /proc/sys/kernel/sysrq if / when needed)? |
|
Back to top |
|
 |
Hu Administrator

Joined: 06 Mar 2007 Posts: 23395
|
Posted: Sun Mar 30, 2025 1:28 pm Post subject: |
|
|
There are two ways to restrict which users can use sysrq. The first option is to ban the offending user(s) from keyboard access to the affected systems. The second, slightly less strict approach, is to establish that inappropriate use of sysrq is a termination offense (in the corporate/government world, fire the user; in the academic world, expel them). In both cases, the kernel cannot know who is pressing the key, so it cannot tell whether this is an authorized user. All users with physical access are presumed authorized.
On the technical side, as I read Documentation/admin-guide/sysrq.rst, you can configure which sysrq features are enabled: Code: | - 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
| Alt+SysRq+F is documented as forcing a partial run of the oom-killer, so I think you want to disallow "enable signalling of processes". That said, SAK is highly disruptive to normal operations too, so you may want to block that, although that has the minor virtue that since it kills almost everything, a rogue user will hurt himself by using it (and thus he would deliberately avoid using it), whereas a forced OOM kill might leave the rogue's processes intact. If the rogue user is just generally destructive, then you need to block SAK, remount read-only, signalling, and reboot/poweroff. You also need to prevent the user from accessing the power cord, hardware power button, and hardware reset button. |
|
Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|