Good letâs shut it down.
The only thing weâll miss is the ability to crash the system in case of an emergency such as when thereâs an attempt to seize a device.
Fortunately you can select which commands are allowed by settings a bitmask in the system settings. Please keep the ability to halt the system.
That sounds like something much better done on the host.
So it should be kernel.sysrq=128
, right?
Yes
Just created a pull request for these.
@madaidan can you also exempt sysrq + f from being blocked?
This key is particularly useful when killing a hanging process considering swap is disabled on the host for Whonix live mode to be traceless.
Call oom_kill, which kills a process to alleviate an OOM condition f
I donât see how this is any better than just using Ctrl + C or kill -9
.
They likely wonât want to do that as the map files are good for debugging.
It would protect against malware attempting to check for local files instead of having to use another source.
sysrq is immediately applied when the whole machine is stalled and you canât really open a terminal and type anything. Also isnât Ctrl + C just the copy command?
Ctrl + C seems fine for that then.
No, Ctrl + C sends the SIGINT command to kill a process. For example, run yes
in a terminal and press Ctrl + C to kill it. Ctrl + D can also be used to kill an open terminal.
madaidan via Whonix Forum:
Ctrl + C seems fine for that then.
When the whole machine appears frozen Ctrl + C wonât have any effect.
sysrq might work.
Of course, but we shouldnât be too trusting of Copperhead.
If Ctrl + C doesnât work, I doubt sysrq would.
sysrq is immediately enforced by a running kernel. Thatâs what makes these commands so special. If there isnât a security argument against it, please add it to the mask.
Can a user only kill itâs own processes with it or any process?
What if an unprivileged user kills a very important process that is usually only accessible by root?
It seems that restricting sysrq was unnecessary as no non admin/root user is allowed to trigger it. A process with root privileges has many more options for killing a process or doing worse.
https://www.kernel.org/doc/html/v4.14/admin-guide/sysrq.html
Note that the value of /proc/sys/kernel/sysrq influences only the invocation via a keyboard. Invocation of any operation via /proc/sysrq-trigger is always allowed (by a user with admin privileges).
No, it says only root can trigger it via /proc/sysrq-trigger. Any user can trigger it with the actual SysRq key on the keyboard.
Could any compromised non-root user generate the keyboard event for SysRq and thereby use SysRq?
Yes, it shouldnât be too hard to emulate the SysRq key the same way something like an on-screen keyboard works.
Could you test please? We need to know this for sure.
If any non-root user can use SysRq via emulated keyboard event, then this changes security considerations.
Maybe a real keyboard (perhaps PS/2 only) can generate an event (hardware interrupt) that cannot be generated by a non-root user?
What specifically does not look good?
SysRq
is also dubbed Secure Access Key
.
I havenât seen any linux security guides recommending disabling SysRq. Perhaps in context of physical access and/or servers. But physical access is game over anyhow independent from SysRq key.
On the other hand, QA/Sysrq - Fedora Project Wiki says:
Sa
k
(Secure Access Key) is useful when you want to be sure there is no trojan program running at console which could grab your password when you would try to login.
SysRq might be a good addition for Prevent Malware from Sniffing the Root Password?
On Full Disk Encryption (FDE) we write
In an emergency, Non-Qubes-Whonix ⢠is capable of powering-off the computer immediately via the Magic SysRq key feature. This is invoked by pressing the key combination:
Alt
+PrintScreen
+o
(lower-case letter). On bare-metal linux systems, the FDE passphrase is prompted after rebooting.[21] [22] [23] The magic key feature does not work on Qubes hosts because the Xen hypervisor does not recognize these commands. [24]
Previously considered a security feature:
Looks more like we shouldnât disable SysRq at all, rather make sure it is functional?
Being able to run a bunch of commands that would normally require root (such as killing every process, remounting all filesystems read-only etc.) as an unprivileged user doesnât look very good. Sounds like a possible privilege escalation hole and/or a feature that can easily be abused.
Thatâs only the k
option of SysRq, not the whole thing.
How would the trojan be started at the login prompt anyway? That doesnât really make sense.
We allow powering off with SysRq but disable everything else.
Also, it seems like Xen does support SysRq.
The Xen hypervisor has functionality to send magic commands to hosted domains via its xm sysrq command.[11] Additionally, a SysRq command can be invoked from a Xen paravirtual console by sending a break sequence Ctrl+O followed by the desired key.