SysRq (Magic SysRq key)

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:

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
1 Like

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.

1 Like

SysRq : HELP : loglevel(0-9) reboot(b) crash(c) 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(p) show-all-timers(q) unraw(r) 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?

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.

1 Like
2 Likes

@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.

1 Like

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.
2 Likes

^^ Pretty badass.

1 Like

https://web.archive.org/web/20081011084822/http://kernel.org/doc/Documentation/sysrq.txt

1 Like

Quote Screen Locker (In)Security - Can we disable these at least 4 backdoors?

What does 176 value for /proc/sys/kernel/sysrq mean? Anyone can find documentation for that?

1 Like

Why use wayback?

The docs are still available. They’re just in the admin-guide directory.

https://www.kernel.org/doc/Documentation/admin-guide/sysrq.rst

It allows only rebooting, syncing and remounting all drives read-only with the sysrq key. Sysrq uses a bitmask to control which features to allow.

According to the kernel docs, 16 is sync, 32 is remount read-only and 128 is reboot/poweroff. 16 + 32 + 128 = 176

1 Like

Against link rot and couldn’t find the current version.

2 Likes

4 posts were split to a new topic: Send SysRq commands to VirtualBox usability helper - virtualbox-send-sysrq

Now that untrusted root is in our threat model, we might want to look at disabling SysRq again as abusing it can be done remotely by root (/proc/sysrq-trigger or /dev/uinput).

CLIPOS also recommends to disable this.

1 Like

Would it make sense to add this to apparmor-profile-everything? Since only apparmor-profile-everything implements untrusted root? security-misc alone doesn’t implement untrusted root?

Can’t find. Any reference?

1 Like

apparmor-profile-everything doesn’t really have anything to do with sysrq or other kernel hardening.

I don’t think we should make this related to apparmor.

It does a bit.

It disables kexec.

https://github.com/Whonix/security-misc/blob/master/etc/sysctl.d/kexec.conf

Hides kernel symbols from root.

https://github.com/Whonix/security-misc/blob/master/etc/sysctl.d/kptr_restrict.conf

Prevents root processes from creating coredumps.

https://github.com/Whonix/security-misc/blob/master/etc/sysctl.d/suid_dumpable.conf

Hardens the BPF JIT compiler for root (that’s what bpf_jit_harden=2 does).

https://github.com/Whonix/security-misc/blob/master/etc/sysctl.d/harden_bpf.conf

https://docs.clip-os.org/clipos/kernel.html#kernel-hacking

2 Likes

Without apparmor-profile-everything, a malicious root can just easyly enable sysrq as per instructions. There for users who only use security-misc don’t benefit from this. Only hinders debugging for these. Therefore I think this fits better into apparmor-profile-everything. Only with apparmor-profile-everything we can have a complete untrusted root implementation.

2 Likes

Not necessarily. An attacker running as root without read-write access to /proc/sys/kernel/sysrq (as is the case for many systemd services due to ProtectKernelTunables for example) can still be limited by this.

1 Like

madaidan via Whonix Forum:

Not necessarily. An attacker running as root without read-write access to /proc/sys/kernel/sysrq (as is the case for many systemd services due to ProtectKernelTunables for example) can still be limited by this.

In that situation could a compromised process simulate pressing sysrq key?

1 Like

Yes, should be possible via /dev/uinput.

2 Likes