...making Linux just a little more fun!

<-- prev | next -->

# 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

Copyright © 2010, Anonymous. Released under the Open Publication License unless otherwise noted in the body of the article. Linux Gazette is not produced, sponsored, or endorsed by its prior host, SSC, Inc.

Published in Issue 173 of Linux Gazette, April 2010

<-- prev | next -->