Magic and Mayhem
By Anonymous
It all started with SAK, the Secure Attention Key, that was supposed to get me out of trouble in Ubuntu. The help I got was a kernel panic.
Investigations followed; doubts followed the investigations. I report starting with a recap on SysRq, mainly from
http://www.kernel.org/doc/documentation/sysrq.txt
This doc lacks important information, but it is included here.
(1) What is the 'magic' SysRq key?
It is a key combo the kernel will immediately respond to, whatever it is doing - assuming it was compiled with the CONFIG_MAGIC_SYSRQ option. This is the case with the major GNU/Linux distros.
(2) Need the SysRq key be enabled?
No, when running a kernel with SysRq compiled in, the key is (usually) enabled.
However, distributions like openSUSE have a restricted value in /proc/sys/kernel/sysrq -
meaning that, according to their documentation, sysrq is disabled by default.
But you can disable or restrict it courtesy of /proc/sys/kernel/sysrq.
By default, this file contains 1 and SysRq is fully enabled (with some
exceptions - see above). To disable SysRq, write 0 to the file.
To restrict functionality selectively, pick values from this table:
| Value | Option |
|---|---|
| 2 | Enable control of console logging level |
| 4 | Enable control of keyboard (e.g. SAK) |
| 8 | Enable debugging dumps of processes etc. |
| 16 | Enable sync command |
| 32 | Enable remount read-only |
| 64 | Enable signalling of processes (term, kill, oom-kill) |
| 128 | Allow reboot/poweroff |
| 256 | Allow rescheduling |
Pick your options, sum their values, write the sum to /proc/sys/kernel/sysrq; after that, only your options will be allowed.
The value in /proc/sys/kernel/sysrq determines the shortcuts available to all users and is not subject to permissions. However, writing to this file requires root privileges. And since the file is not really a file and dies when shutting down or rebooting, the writing has to be repeated after each boot.
The option 'sysrq_always_enabled' in the kernel line of the boot loader will let the kernel ignore /proc/sys/kernel/sysrq.
(3) How do I use the SysRq key on x86 PCs?
Press the key combo Alt-SysRq-command_key, where 'SysRq' is
same as 'PrintScreen' and command_key is a case-insensitive
letter or a digit from
b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,z,0-9
Needless to say, it is awkward or even infeasible to hold down three keys at once when two of them are a stretched hand apart. Just do:
hold down Alt (either on the right or on the left)
press and release SysRq quickly
press command_key quickly
release everything
Quickly means: don't dither, or Ubuntu will pop up a Screen Shot dialog.
NOTE: the position of keys is as on the US keyboard! Keep this in mind when using a non-US keyboard. For instance, 'q' is the key just right of Tab even if that same key carries the label 'a' on a French keyboard.
Indeed, you are not sending an 'a' or a 'q': you are sending a well-defined scancode to the kernel. Keyboards needn't apply if they produce scancodes different from those of the common PC keyboards.
Only details for a couple of the commands are of interest in the current context:
| i | Kill all processes, except init. |
| k | Secure Attention Key (SAK) kills all applications on the current virtual console. |
| 0-9 | Sets the console log level, controlling which kernel messages will show on your console: 0 would let only emergency messages reach the console while 9 is verbose. |
(4) Kernel Panic
So why do I very reliably trigger a kernel panic when I press SAK on Ubuntu 9.10, both in the text console and on the desktop? The difference between the two is that the kernel panic is immediate in the text console. On the desktop it may look like everything is ok, then you press e.g. Alt-Ctrl-F1 to switch to a text console and it happens.
Well, this is a bug already reported in February 2009 for a previous version:
https://bugs.launchpad.net/Ubuntu/+source/linux/+bug/329576/
An addendum to the bug report says the bug manifests on AMD boards, but not necessarily on Intel boards. I can confirm that I do get my kernel panic on AMD hardware, but I have also seen it on an Intel motherboard with a VIA graphic adapter.
A related bug was reported for Debian in August 2009:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543324/
but here the console-kit-daemon was pointed out as the culprit. I disabled it, the bug is still active on my Ubuntu.
Changing the log level with Alt-SysRq-9 allows for a flood of
low level details for the initiated. What is clear, reading and watching,
is that an attempt to kill the 'init' process occurs - certainly not the
kernel's intention. Who is trying to kill init? Something specific to
Ubuntu, shall we say, since openSUSE doesn't do it.
Now, when I try Alt-SysRq-i to kill all processes except init,
I get a kernel panic exactly as with SAK, exactly with the same message
about init's attempted murder.
That Ubuntu bug of February 2009 got no follow-up, not even an assignment to a developer, not even a priority rank. What does it take for serious bugs to get fixed in Ubuntu?
(5) Security by Good Luck
At the end of the day, what we know is disturbing:
- Everybody wants the magic of SysRq, otherwise the major distros would not compile it in.
- The administrator can reduce SysRq's functionality, but not just for the unwashed masses. Any reduction in SysRq's functionality will equally affect the administrator. Functionality cannot be changed on the fly, because when a critical situation arises you already need it.
- Even disregarding bugs like Ubuntu SAK's bug, SysRq has options to bring down and damage the entire system. If you start disabling them, SysRq loses its magic in the difficult situations it is called for. So if you as an administrator want SysRq, you are offering vandals and experimenters a comfortable way to wreak havoc.
Is a GNU/Linux system the most insecure system in the history of computers? Why is the SysRq magic not reserved for root?[1]
[1] That's an easy question to answer - although, unfortunately, the answer does nothing to address this concern. Since most Linux users are (hopefully) not logged in as root most of the time, restricting SysRq to root-only would make it essentially useless at precisely the times when it's needed. Perhaps a reasonable approach to a SysRq policy is to disable the "dangerous" features by default, and enable them on specific machines that need more specific troubleshooting? -- Ben
Talkback: Discuss this article with The Answer Gang
A. N. Onymous has been writing for LG since the early days - generally by
sneaking in at night and leaving a variety of articles on the Editor's
desk. A man (woman?) of mystery, claiming no credit and hiding in
darkness... probably something to do with large amounts of treasure in an
ancient Mayan temple, and a beautiful dark-eyed woman with a snake tattoo
winding down from her left hip. Or maybe A.N. is just into privacy. In
any case, we're grateful for the contributions.
-- Editor, Linux Gazette
