| Linux 2.4.2 Secure Attention Key (SAK) handling | 
 | 18 March 2001, 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. | 
 |  | 
 |  | 
 | NOTES | 
 | ===== | 
 |  | 
 | 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. | 
 |  |