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?
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.
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.
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.
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).
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.
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.
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.
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.
Right. Needs to be confirmed since no one outside of our forums claimed and/or demonstrated that this is possible yet as far as I know.
Speculation: I guess the theory goes if you press “alt + ctrl + F1” to switch to a virtual console that a compromised X server could draw a login console prompt which in fact is not one. While SysRq would be privileged and allow another non-root user (different from X user) to use login while making sure that Xwas interrupted.
I’ve looked into this and it doesn’t seem possible.
Things such as xdotool won’t work as the SysRq key isn’t handled by Xorg and things like /dev/uinput or /proc/sysrq-trigger requires root access already.
It seems like SysRq requires a local keyboard to be connected.
The k command only kills programs on the current virtual console so it wouldn’t be able to kill X as it’s not running on the one you switched to.
I don’t think X can mess with other virtual consoles anyway.
Well, ultimately all handling of all devices including keyboard and all keys is handled by the kernel but that answers very little without knowing how the kernel handles and/or forwards these tasks.
/lib/systemd/system/console-getty.service uses agetty, not getty. May or may not be an irrelevant detail, didn’t research the difference.
If you are in X, run sudo journalctl -f and press ctrl + alt + F2 and switch back to X, you will see the following in the log:
Aug 22 18:30:48 dom0 systemd[1]: Started Getty on tty2.
Aug 22 18:30:48 dom0 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=getty@tty2 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Aug 22 18:30:48 dom0 kernel: audit: type=1130 audit(1566513048.972:200): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=getty@tty2 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
This means as long as no virtual console is being switched to, no getty is ruining. This can be confirmed using sudo ps aux too. Nowadays there are no needless processes running all the time. Therefore it cannot be getty or agetty listening for ctrl + alt + F1. systemd starts agetty (probably, even though log says getty), looks like.
It might be systemd that intercepts ctrl + alt + F1. Or it could be the kernel which then notifies systemd. But we still don’t know if X could hook/intercept ctrl + alt + F1 since obviously X also knows what’s happening on the keyboard.