SysRq (Magic SysRq key)

[madaidan]

What specifically does not look good?

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.

SysRq is also dubbed Secure Access Key .

That’s only the k option of SysRq, not the whole thing.

On the other hand, https://fedoraproject.org/wiki/QA/Sysrq 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?

How would the trojan be started at the login prompt anyway? That doesn’t really make sense.

On https://www.whonix.org/wiki/Full_Disk_Encryption 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]

We allow powering off with SysRq but disable everything else.

Also, it seems like Xen does support SysRq.

https://en.wikipedia.org/wiki/Magic_SysRq_key#Other_ways_to_invoke_Magic_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.

[Patrick]

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.

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.

How would the trojan be started at the login prompt anyway?

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.

[madaidan]

If any non-root user can use SysRq via emulated keyboard event, then this changes security considerations.

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.

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 X was interrupted.

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.

[Patrick]

I don’t think X can mess with other virtual consoles anyway.

The question would be who handles “alt + ctrl + F1”?

[madaidan]

The question would be who handles “alt + ctrl + F1”?

getty does.

[Patrick]

@madaidan

getty does.

Likely not the case.

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.

[Patrick]

Not on SysRq but on “alt + ctrl + F1”

@Patrick wrote:
Why “I” can do it but user “man” cannot? What makes “me” and user “man” different?
On non-Qubes Debian I am always wondering if I can switch a virtual console using ctrl + alt + F1, why can user “man” not? And how’s that different in Qubes?

@marmarek wrote:
This is about where the process is started and what has connected as controlling terminal. It isn’t anything Qubes specific. A non-privileged process cannot inject characters into a separate session (lets forget about X11 breaking all this assumptions, as we are talking about non-X11 session), especially if it’s of a different user, similarly as it cannot write to files it doesn’t have write permission. to. You can think of it as a write access to /dev/tty* (or /dev/hvc0 in this case). When you login on /dev/hvc0, login process (running as root) will setup permission to /dev/hvc0 and also pass an open FD to it to your shell. Then, you (user, and that shell) will be able to interact with /dev/hvc0 and specifically run commands connected to it. If you don’t login there, login process will not set the permissions, so you won’t have access.
This does assume kernel enforced permissions are effective, but as we are talking here about in-VM account isolation only, it’s a reasonable assumption.

[madaidan]

The Debian devs think the sysrq key should be disabled for security

https://www.debian.org/doc/manuals/securing-debian-howto/ch4.en.html#s-restrict-sysrq

You should disable this functionality ifaccess to the console is not restricted to authorised users: the console is connected to a modem line, there is easy physical access to the system or it is running in a virtualised environment and other users access the console.

They link to http://tldp.org/HOWTO/Remote-Serial-Console-HOWTO/security-sysrq.html which says

For computers that are not used for kernel software development the magic SysRq key makes an ideal denial of service device. A few unauthenticated keystrokes and the computer is dead in the water. The console, serial or otherwise, must be in an area with access limited to trusted people.

[Patrick]

Good finds. Now it’s important to construe what the authors wanted to say.

https://www.debian.org/doc/manuals/securing-debian-howto/ch4.en.html#s-restrict-sysrq

You should disable this functionality ifaccess to the console is not restricted to authorised users:

Console is restricted to authorised users. Physically nearby adversaries are out of scope.

the console is connected to a modem line,

Not the case. Sounds like legacy. Who’s doing that nowadays still.

there is easy physical access to the system

Physically nearby adversaries are out of scope.

or it is running in a virtualised environment and other users access the console.

Virtualized environment yes but no other user access to console.

---

For computers that are not used for kernel software development the magic SysRq key makes an ideal denial of service device. A few unauthenticated keystrokes and the computer is dead in the water.

Keystrokes -> sounds physical. -> Physically nearby adversaries are out of scope.

The console, serial or otherwise, must be in an area with access limited to trusted people.

This is the case. Physically nearby adversaries are out of scope.

---

In my interpretations, none of these authors speak about malware running on the system abusing SysRq as far as I understand.

[madaidan]

This is the case. Physically nearby adversaries are out of scope.

I don’t see why nearby adversaries should be out of scope. It could be the user themselves making a mistake or some random person pressing buttons. It doesn’t necessarily have to be an advanced adversary.

Something useful here?

Debian disables coredumps by default and we disable coredumps in security-misc for other distros.

https://github.com/Whonix/security-misc/blob/master/etc/security/limits.d/disable-coredumps.conf (there are a few other ways we disable them too)

[HulaHoop]

I don’t see why nearby adversaries should be out of scope.

They have so many options to infect and sabotage security that its hopeless to try and stop them. Meanwhile disabling sysrq completely will prevent system admins/owners from doing some useful stuff. I advocate for a whitelist of functions instead of killing off one of the great features Linux supports.

[madaidan]

They have so many options to infect and sabotage security that its hopeless to try and stop them.

Hence why I said, “It could be the user themselves making a mistake or some random person pressing buttons. It doesn’t necessarily have to be an advanced adversary.”.

I advocate for a whitelist of functions instead of killing off one of the great features Linux supports.

That’s basically what we’re doing. We need to make sure the functions we whitelist aren’t too dangerous and have a clear usecase.

[Patrick]

Created a separate forum thread for Should (lesser) Adversaries with Physical Access be part of the Threat Model of Whonix / Whonix-Host / Kicksecure?

They have so many options to infect and sabotage security that its hopeless to try and stop them. Meanwhile disabling sysrq completely will prevent system admins/owners from doing some useful stuff. I advocate for a whitelist of functions instead of killing off one of the great features Linux supports.

I advocate for a whitelist of functions instead of killing off one of the great features Linux supports.

Why bother with a whitelist if “They have so many options to infect and sabotage security that its hopeless to try and stop them.”? What enhancement would the whitelist give under that assumption?

It doesn’t necessarily have to be an advanced adversary.

What’s the threat model? What kind of lesser adversary knows about SysRq? Which SysRq commands would a lesser adversary use?

[Patrick]

Generally, I would also suggest to suggest such security enhancements such as related to SysRq or Blacklist more kernel modules to reduce attack surface or others also to other security/privacy focused projects, such as:

• Qubes
• Tails
• Hardened Gentoo
• https://clip-os.org
• Alpine
• GrapheneOS
• https://en.wikipedia.org/wiki/Security-focused_operating_system others?

The purpose of this is to increase the security of the whole ecosystem. Would good would we be off if security of Whonix / Kicksecure would be “perfect” but at the same time:

• Debian package build servers compromised
• Debian maintainers compromised
• Tor relays compromised
• etc.

More reasons:

• more brain power reviewing suggestions and perhaps being inspired to make further suggestions
• wider testing
• wider use (bugs more easily caught)
• more easily convinced doing the same by Whonix default if others are doing the same

[madaidan]

What’s the threat model? What kind of lesser adversary knows about SysRq? Which SysRq commands would a lesser adversary use?

I’d imagine many Linux users would know how to use the SysRq key but aren’t advanced enough to reflash the firmware with malware or other advanced attacks.

[Patrick]

Should (lesser) Adversaries with Physical Access be part of the Threat Model of Whonix / Whonix-Host / Kicksecure?

These examples aren’t great since apparmor and firewall aren’t processes. Also I didn’t see a feature to kill any specific process. To do what? -> Advanced adversary. To do what? These will end up only accessible by root and on a hopefully encrypted disk? Disk not encrypted + physical access -> running machine -> game over anyhow. Disk encrypted + physical access… Advanced adversary. I’ve tried all sysrq commands and didn’t see any command to dump RAM contents to console. Crash dump…

---

SysRq : HELP : loglevel(0-9) reboot(b) crash© terminate-all-tasks(e) memory-full-oom-kill(f) kill-all-tasks(i) thaw-filesystems(j) sak(k) show-backtrace-all-active-cpus(l) show-memory-usage(m) nice-all-RT-tasks(n) poweroff(o) show-registers§ show-all-timers(q) unraw® sync(s) show-task-states(t) unmount(u) force-fb(V) show-blocked-tasks(w) dump-ftrace-buffer(z)

To see output generated by using SysRq commands it is required:

• when using X: open a terminal emulator and run sudo journalctl -f
• or to switch to a virtual console

---

• when using X: we should probably assume the session protected by xscreensaver or login prompt? What else would restricted SysRq prevent from an adversary that can use an active login session anyhow?
• on a virtual console: can we prevent seeing SysRq (or all kernel output) in virtual consoles as long as no user is logged in?

Not the Whonix / Kicksecure use case but in a use case of kiosk mode (somewhat(?) public access to a keyboard and screen only while the computer is considered securely locked away) it seems wrong that users without any login session can see output by the kernel in virtual consoles.

Output by SysRq commands should be hidden until there is a active login session? Good compromise?

Maybe removing quite boot parameter is the cause of this?

[Patrick]

While experimenting with module loading disabling, I experienced that broken X can block switching to virtual console. Needless to say (for other readers), if X can do, also malware could do. “SysRq + r” can take away control from X. After that, switching to another virtual console was possible.

[Patrick]

undo SysRq restrictions

[Patrick]

@marmarek

(lets forget about X11 breaking all this assumptions

@Patrick

Indeed.

While experimenting with module loading disabling, I experienced that broken X can block switching to virtual console. Needless to say (for other readers), if X can do, also malware could do. “SysRq + r” can take away control from X. After that, switching to another virtual console was possible.

@marmarek

Yes, X (or other process with access to input device) can grab it for exclusive access, disabling Alt+Ctrl+F1 or similar combos. This still is independent of what is happening on other terminals. Especially, input devices grabbed in this mode are handled by X server (or other process that grabbed them). As long as X server doesn’t have access to other terminals, it still can’t influence them.

[Patrick]

Quote https://www.kernel.org/doc/Documentation/SAK.txt

=========================================
Linux Secure Attention Key (SAK) handling
=========================================

:Date: 18 March 2001
:Author: Andrew Morton

An operating system's Secure Attention Key is a security tool which is
provided as protection against trojan password capturing programs.  It
is an undefeatable way of killing all programs which could be
masquerading as login applications.  Users need to be taught to enter
this key sequence before they log in to the system.

From the PC keyboard, Linux has two similar but different ways of
providing SAK.  One is the ALT-SYSRQ-K sequence.  You shouldn't use
this sequence.  It is only available if the kernel was compiled with
sysrq support.

The proper way of generating a SAK is to define the key sequence using
``loadkeys``.  This will work whether or not sysrq support is compiled
into the kernel.

SAK works correctly when the keyboard is in raw mode.  This means that
once defined, SAK will kill a running X server.  If the system is in
run level 5, the X server will restart.  This is what you want to
happen.

What key sequence should you use? Well, CTRL-ALT-DEL is used to reboot
the machine.  CTRL-ALT-BACKSPACE is magical to the X server.  We'll
choose CTRL-ALT-PAUSE.

In your rc.sysinit (or rc.local) file, add the command::

	echo "control alt keycode 101 = SAK" | /bin/loadkeys

And that's it!  Only the superuser may reprogram the SAK key.


.. note::

  1. Linux SAK is said to be not a "true SAK" as is required by
     systems which implement C2 level security.  This author does not
     know why.


  2. On the PC keyboard, SAK kills all applications which have
     /dev/console opened.

     Unfortunately this includes a number of things which you don't
     actually want killed.  This is because these applications are
     incorrectly holding /dev/console open.  Be sure to complain to your
     Linux distributor about this!

     You can identify processes which will be killed by SAK with the
     command::

	# ls -l /proc/[0-9]*/fd/* | grep console
	l-wx------    1 root     root           64 Mar 18 00:46 /proc/579/fd/0 -> /dev/console

     Then::

	# ps aux|grep 579
	root       579  0.0  0.1  1088  436 ?        S    00:43   0:00 gpm -t ps/2

     So ``gpm`` will be killed by SAK.  This is a bug in gpm.  It should
     be closing standard input.  You can work around this by finding the
     initscript which launches gpm and changing it thusly:

     Old::

	daemon gpm

     New::

	daemon gpm < /dev/null

     Vixie cron also seems to have this problem, and needs the same treatment.

     Also, one prominent Linux distribution has the following three
     lines in its rc.sysinit and rc scripts::

	exec 3<&0
	exec 4>&1
	exec 5>&2

     These commands cause **all** daemons which are launched by the
     initscripts to have file descriptors 3, 4 and 5 attached to
     /dev/console.  So SAK kills them all.  A workaround is to simply
     delete these lines, but this may cause system management
     applications to malfunction - test everything well.