xref: /OK3568_Linux_fs/kernel/Documentation/security/sak.rst (revision 4882a59341e53eb6f0b4789bf948001014eff981)
1*4882a593Smuzhiyun=========================================
2*4882a593SmuzhiyunLinux Secure Attention Key (SAK) handling
3*4882a593Smuzhiyun=========================================
4*4882a593Smuzhiyun
5*4882a593Smuzhiyun:Date: 18 March 2001
6*4882a593Smuzhiyun:Author: Andrew Morton
7*4882a593Smuzhiyun
8*4882a593SmuzhiyunAn operating system's Secure Attention Key is a security tool which is
9*4882a593Smuzhiyunprovided as protection against trojan password capturing programs.  It
10*4882a593Smuzhiyunis an undefeatable way of killing all programs which could be
11*4882a593Smuzhiyunmasquerading as login applications.  Users need to be taught to enter
12*4882a593Smuzhiyunthis key sequence before they log in to the system.
13*4882a593Smuzhiyun
14*4882a593SmuzhiyunFrom the PC keyboard, Linux has two similar but different ways of
15*4882a593Smuzhiyunproviding SAK.  One is the ALT-SYSRQ-K sequence.  You shouldn't use
16*4882a593Smuzhiyunthis sequence.  It is only available if the kernel was compiled with
17*4882a593Smuzhiyunsysrq support.
18*4882a593Smuzhiyun
19*4882a593SmuzhiyunThe proper way of generating a SAK is to define the key sequence using
20*4882a593Smuzhiyun``loadkeys``.  This will work whether or not sysrq support is compiled
21*4882a593Smuzhiyuninto the kernel.
22*4882a593Smuzhiyun
23*4882a593SmuzhiyunSAK works correctly when the keyboard is in raw mode.  This means that
24*4882a593Smuzhiyunonce defined, SAK will kill a running X server.  If the system is in
25*4882a593Smuzhiyunrun level 5, the X server will restart.  This is what you want to
26*4882a593Smuzhiyunhappen.
27*4882a593Smuzhiyun
28*4882a593SmuzhiyunWhat key sequence should you use? Well, CTRL-ALT-DEL is used to reboot
29*4882a593Smuzhiyunthe machine.  CTRL-ALT-BACKSPACE is magical to the X server.  We'll
30*4882a593Smuzhiyunchoose CTRL-ALT-PAUSE.
31*4882a593Smuzhiyun
32*4882a593SmuzhiyunIn your rc.sysinit (or rc.local) file, add the command::
33*4882a593Smuzhiyun
34*4882a593Smuzhiyun	echo "control alt keycode 101 = SAK" | /bin/loadkeys
35*4882a593Smuzhiyun
36*4882a593SmuzhiyunAnd that's it!  Only the superuser may reprogram the SAK key.
37*4882a593Smuzhiyun
38*4882a593Smuzhiyun
39*4882a593Smuzhiyun.. note::
40*4882a593Smuzhiyun
41*4882a593Smuzhiyun  1. Linux SAK is said to be not a "true SAK" as is required by
42*4882a593Smuzhiyun     systems which implement C2 level security.  This author does not
43*4882a593Smuzhiyun     know why.
44*4882a593Smuzhiyun
45*4882a593Smuzhiyun
46*4882a593Smuzhiyun  2. On the PC keyboard, SAK kills all applications which have
47*4882a593Smuzhiyun     /dev/console opened.
48*4882a593Smuzhiyun
49*4882a593Smuzhiyun     Unfortunately this includes a number of things which you don't
50*4882a593Smuzhiyun     actually want killed.  This is because these applications are
51*4882a593Smuzhiyun     incorrectly holding /dev/console open.  Be sure to complain to your
52*4882a593Smuzhiyun     Linux distributor about this!
53*4882a593Smuzhiyun
54*4882a593Smuzhiyun     You can identify processes which will be killed by SAK with the
55*4882a593Smuzhiyun     command::
56*4882a593Smuzhiyun
57*4882a593Smuzhiyun	# ls -l /proc/[0-9]*/fd/* | grep console
58*4882a593Smuzhiyun	l-wx------    1 root     root           64 Mar 18 00:46 /proc/579/fd/0 -> /dev/console
59*4882a593Smuzhiyun
60*4882a593Smuzhiyun     Then::
61*4882a593Smuzhiyun
62*4882a593Smuzhiyun	# ps aux|grep 579
63*4882a593Smuzhiyun	root       579  0.0  0.1  1088  436 ?        S    00:43   0:00 gpm -t ps/2
64*4882a593Smuzhiyun
65*4882a593Smuzhiyun     So ``gpm`` will be killed by SAK.  This is a bug in gpm.  It should
66*4882a593Smuzhiyun     be closing standard input.  You can work around this by finding the
67*4882a593Smuzhiyun     initscript which launches gpm and changing it thusly:
68*4882a593Smuzhiyun
69*4882a593Smuzhiyun     Old::
70*4882a593Smuzhiyun
71*4882a593Smuzhiyun	daemon gpm
72*4882a593Smuzhiyun
73*4882a593Smuzhiyun     New::
74*4882a593Smuzhiyun
75*4882a593Smuzhiyun	daemon gpm < /dev/null
76*4882a593Smuzhiyun
77*4882a593Smuzhiyun     Vixie cron also seems to have this problem, and needs the same treatment.
78*4882a593Smuzhiyun
79*4882a593Smuzhiyun     Also, one prominent Linux distribution has the following three
80*4882a593Smuzhiyun     lines in its rc.sysinit and rc scripts::
81*4882a593Smuzhiyun
82*4882a593Smuzhiyun	exec 3<&0
83*4882a593Smuzhiyun	exec 4>&1
84*4882a593Smuzhiyun	exec 5>&2
85*4882a593Smuzhiyun
86*4882a593Smuzhiyun     These commands cause **all** daemons which are launched by the
87*4882a593Smuzhiyun     initscripts to have file descriptors 3, 4 and 5 attached to
88*4882a593Smuzhiyun     /dev/console.  So SAK kills them all.  A workaround is to simply
89*4882a593Smuzhiyun     delete these lines, but this may cause system management
90*4882a593Smuzhiyun     applications to malfunction - test everything well.
91*4882a593Smuzhiyun
92