89 lines
2.8 KiB
Plaintext
Executable File
89 lines
2.8 KiB
Plaintext
Executable File
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.
|
|
|