Actions

System Recovery using SysRq Key

From Whonix



Use Cases[edit]

The SysRq or "Security Keys" (SAK [archive] key) function in Linux is equivalent to the well known Control-Alt-Delete (Ctrl+Alt+Del) function in Windows, otherwise referred to as the "three-finger salute". Debian documentation notes that SysRq combinations are useful for bypassing bad situations and gaining usable keyboard access, without stopping the system. [1] In effect this provides insurance against system malfunctions due to support compiled in the Linux kernel -- pressing SysRq followed by the required key for a specific command "rescues" the system.

SysRq is handled directly by the kernel. Not by (a)getty, systemd or the X Window System.

Call oom_kill, which kills a process to alleviate an OOM condition

This is more effective than Ctrl + C or kill -s sigkill. When the whole machine appears frozen Ctrl + C often will not have any effect. SysRq has a higher chance of being processed by the kernel except if the kernel itself is locked up.

System Recovery[edit]

Wikipedia [archive] notes:

The magic SysRq key is a key combination understood by the Linux kernel [archive], which allows the user to perform various low-level commands regardless of the system's state. It is often used to recover from freezes [archive], or to reboot [archive] a computer without corrupting the filesystem [archive]. Its effect is similar to the computer's hardware reset button [archive] (or power switch) but with many more options and much more control.

This key combination provides access to powerful features for software development and disaster recovery. In this sense, it can be considered a form of escape sequence [archive]. Principal among the offered commands are means to forcibly unmount file systems, kill processes, recover keyboard state, and write unwritten data to disk. With respect to these tasks, this feature serves as a tool of last resort.

The magic SysRq key cannot work under certain conditions, such as a kernel panic [archive] or a hardware failure preventing the kernel from running properly.

In the Whonix ™ case, magic SysRq keys are useful when the guest is unresponsive, especially in cases where VMs are running headless and a GUI console is not available for forcing them to shut off on the host.

Malware[edit]

SysRq can be used to defeat login spooking (malware masquerading as login prompt and stealing login passwords).

Quote Linux Kernel Documentation [archive]:

Sak (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. It will kill all programs on given console, thus letting you make sure that the login prompt you see is actually the one from init, not some trojan program.

Enable SysRq[edit]

SysRq can be enabled temporarily or permanently.

For temporary functionality, run.

echo "1" | sudo tee /proc/sys/kernel/sysrq

To permanently enable SysRq, run.

echo "kernel.sysrq = 1" | sudo tee -a /etc/sysctl.d/50_sysrq.conf

After completing the temporary or permanent change, check that SysRq has been properly set.

cat /proc/sys/kernel/sysrq

The output should show.

1

Overview of Commands[edit]

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)

  • loglevel(0-9)s
  • 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)

Usage[edit]

SysRq can also be used by writing to /proc/sysrq-trigger.

sudo -u root bash

echo h > /proc/sysrq-trigger

Qubes[edit]

See also add Qubes host key to allow switching virtual console (ctrl + alt + F1) or SysRq for HVM [archive].

Development[edit]

Security Discussion[edit]

SysRq Security concern raised by madaidan [archive]:

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.

On the other hand, SysRq + k also dubbed Secure Access Key. Therefore SysRq is not completely disabled without further consideration.

Can a user only kill its own processes with it or any process?

What if an unprivileged user kills a very important process that is usually only accessible by root?

Quote screensaver FAQ [archive]:

Backdoor #3: Alt-SysRq-F.

This is the Linux kernel "OOM-killer" keystroke. It shoots down random long-running programs of its choosing, and so might might target and kill xscreensaver, and there's no way for xscreensaver to protect itself from that. You can disable it globally with: sudo 'echo 176 > /proc/sys/kernel/sysrq'

(As of version 5.41, if xscreensaver is setuid, and you are running Linux 2.6.37 or newer, xscreensaver attempts to request that the kernel's out-of-memory assassin not randomly unlock the screen on you, but it's only a request.)

Related: Screen Locker (In)Security - Can we disable these at least 4 backdoors? [archive]

Quote https://www.kernel.org/doc/html/v4.14/admin-guide/sysrq.html [archive]

Note that the value of /proc/sys/kernel/sysrq influences only the invocation via a keyboard.

Quote https://www.kernel.org/doc/html/v4.14/admin-guide/sysrq.html [archive]

Invocation of any operation via /proc/sysrq-trigger is always allowed (by a user with admin privileges).

Could any compromised non-root user generate the keyboard event for SysRq and thereby use SysRq? Quote [archive]:

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.

SysRq can be triggered remotely [2].

Virtual Console Handling[edit]

Would be who handles “alt + ctrl + F1”?

Attacks from Lesser Adversaries with Physical Access[edit]

https://forums.whonix.org/t/should-lesser-adversaries-with-physical-access-be-part-of-the-threat-model-of-whonix-whonix-host-kicksecure/7997 [archive]

Development Discussion[edit]

Development Discussion [archive]

See Also[edit]

Footnotes[edit]



text=Jobs in USA
Jobs in USA


Search engines: YaCy | Qwant | ecosia | MetaGer | peekier | Whonix ™ Wiki


Follow: 1024px-Telegram 2019 Logo.svg.png Iconfinder Apple Mail 2697658.png Twitter.png Facebook.png Rss.png Reddit.jpg 200px-Mastodon Logotype (Simple).svg.png

Support: 1024px-Telegram 2019 Logo.svg.png Discourse logo.png Matrix logo.svg.png

Donate: Donate Bank Wire Paypal Bitcoin accepted here Monero accepted here Contriute

Whonix donate bitcoin.png Monero donate Whonix.png United Federation of Planets 1000px.png

Twitter-share-button.png Facebook-share-button.png Telegram-share.png Iconfinder Apple Mail 2697658.png Reddit.jpg Hacker.news.jpg 200px-Mastodon Logotype (Simple).svg.png

Please help us to improve the Whonix ™ Wikipedia Page. Also see the feedback thread.

https link onion link

This is a wiki. Want to improve this page? Help is welcome and volunteer contributions are happily considered! Read, understand and agree to Conditions for Contributions to Whonix ™, then Edit! Edits are held for moderation. Policy of Whonix Website and Whonix Chat and Policy On Nonfreedom Software applies.

Copyright (C) 2012 - 2021 ENCRYPTED SUPPORT LP. Whonix ™ is a trademark. Whonix ™ is a licensee [archive] of the Open Invention Network [archive]. Unless otherwise noted, the content of this page is copyrighted and licensed under the same Freedom Software license as Whonix ™ itself. (Why?)

The personal opinions of moderators or contributors to the Whonix ™ project do not represent the project as a whole.

Whonix ™ is a derivative of and not affiliated with Debian [archive]. Debian is a registered trademark [archive] owned by Software in the Public Interest, Inc [archive].

Whonix ™ is produced independently from the Tor® [archive] anonymity software and carries no guarantee from The Tor Project [archive] about quality, suitability or anything else.

By using our website, you acknowledge that you have read, understood and agreed to our Privacy Policy, Cookie Policy, Terms of Service, and E-Sign Consent. Whonix ™ is provided by ENCRYPTED SUPPORT LP. See Imprint, Contact.

By using our website, you acknowledge that you have read, understood and agreed to our Privacy Policy, Cookie Policy, Terms of Service, and E-Sign Consent.