Simple Screen Auto-Locking Mechanisms
Computer security is a major concern of most corporations.
information age of today, corporate computing services
and databases are
major assets that must be closely guarded against intruders
and outside the company. Many computer crimes, however,
can easily be
prevented by such common practices as instructing employees
before leaving terminals unattended. A live session
on an unattended
terminal is an open invitation to trouble; anyone can
simply walk up to
the terminal and enter commands that will execute with
authority and identity of the logged-in user.
The exposure of unattended terminals is well recognized.
security manuals include policies and practices like
the above. It is
commonplace at mainframe facilities for such policies
to go even
further: sessions are monitored for user keyboard input,
and when no
user input is received for a specified period (e.g.,
10 minutes), the
session is canceled, and the user is logged off.
For a highly interactive operating environment such
as UNIX, this type
of forced logoff policy is usually too harsh. Unexpected
the user's processes could result in corrupted files
and/or lost data.
For this type of environment a gentler approach, such
screen lock, is more appropriate. The automatic screen
many of the objectives of the forced logoff. It does
not free up
computing resources like a true logoff, but it does
terminals from being used by unintended parties.
How Screen Locks Work
The concept of an automatic screen lock is simple. The
terminal (screen) interactions, such as key presses
and mouse movements,
and when interactions cease for a preset period of time,
screen. Locking the screen usually implies some or all
of the following
1. Protecting the screen contents from public view
-- The screen is
blanked or overwritten with a warning screen or changing
pattern. Screen savers also prevent the display screen
from being "
burned." Screen phosphors can be burned and permanently
damaged when the
electron beams used to excite the screen repeatedly
strike the same
2. Locking the keyboard The keyboard is put into a
locked state where
key presses are no longer sent to the underlying programs
system. All key presses are captured by the locking
program and used to
determine if a preassigned "unlock" password
has been entered. Entry of
the "unlock" password signals the locking
program to unlock the keyboard
and restore the screen to the same state as before locking.
3. Locking the mouse or other input devices Mouse
presses, and similar input events are no longer sent
to the underlying
programs or operating system. All input events are either
like keyboard activity, sent to the locking program.
Given the above measures, the terminal or display is
rendered useless to anyone wanting to gain access during
If the screen lock is invoked through a voluntary action
(i.e., a menu
selection, icon, or command), it is called a manual
screen lock. If it
is invoked automatically after an expired period of
inactivity, it is
called an auto-screen lock. To improve security, both
auto-screen lock capabilities should be readily available
Screen lock programs are available from many third-party
most workstation vendors usually supply some sort of
manual screen lock.
Unfortunately, most do not provide auto-screen locks,
methods can be used to implement an auto-screen lock
for a UNIX
workstation or X terminal.
Below are described two simple methods for implementing
lock. In both examples a manual screen lock program
is assumed to be
available. For the workstation example refer to your
system man pages to
obtain the name of a suitable manual screen lock program;
graphics, simply use a public domain program such as
xlock. xlock can be
obtained directly from the X Consortium ftp site at
pathname of the latest version is:
Example 1 -- Auto-Lock for a Workstation
A necessary component of any auto-lock program is an
event monitor to
capture keyboard and mouse events. In this example,
a background script
is used to monitor events and invoke a manual screen
lock program after
an expired period of inactivity.
The monitor script calls two operating system dependent
_kbr and _msr. These scripts are used to obtain cumulative
keyboard and mouse activity (i.e., key press/releases
movements/presses). The monitor script determines whether
is attended by capturing keyboard and mouse counts at
the beginning of a
sleep interval and comparing them to those obtained
at the end. If no
activity occurred during the sleep interval, then the
assumed to be unattended, and it is locked. If activity
did occur during
the sleep interval, then the monitor process is repeated
until the process is terminated.
Listing 1 contains a listing of the monitor script,
and Listing 2 and Listing 3
contain helper scripts for Linux and SunOS, respectively.
programs or scripts can be written for other versions
of UNIX, but in
many cases, execution may require special privileges
(root or kmem) to
access kernel structures.
Linux provides easy access to device interrupt statistics
proc filesystem. The proc filesystem is a virtual filesystem
contains no real data. The files and directories in
the proc filesystem
are access paths to information on system and user processes
structures. For example, the file /proc/interrupts contains
information on device statistics one line for each
SunOS and other BSD derivatives allow access to kernel
through the /etc/pstat command. On SunOS systems, the
(/dev/kbd) and mouse (/dev/mouse) devices are stream
devices. This means
the file table offset entries reflect cumulative counts
events (for nondevice files, the file table offset entries
offsets that apply to one or more file descriptors).
The helper scripts
use this fact to extract offsets from the file table
pointers cross-referenced from the streams table. The
entries in the streams table are located by matching
the device number
fields in the streams table to those returned by ls.
Unfortunately, it is not possible to write portable
code for device
interrupt monitoring; it is highly operating system
usually requires access to implementation-specific kernel
structures. Fortunately, if X is the windowing system,
this level of
monitoring is not necessary. X can be tricked into doing
as shown in the next example.
Example 2 -- Auto-Lock for an X Terminal or Workstation
As in the first example, you will need a background
monitor script. The
script in this case, uses an X program (chkact) to do
keyboard and mouse monitoring. The monitor script simply
return code from chkact and locks the screen if it returns
0. If chkact
returns any other value, the monitor script ends. A
listing of the
monitor script (xmon) appears in Listing 4.
The C program, chkact, shown in Listing 5, tricks the
X server into
doing the keyboard and mouse monitoring by invoking
the built-in X
screen saver. The built-in screen saver is configurable
XSetScreenSaver call. The second parameter (wait) in
establishes the time-out period. The X server monitors
all input devices
and invokes the screen saver if the time-out period
expires without any
device input being received by the X server.
The chkact program, instead of attempting to monitor
the input devices,
monitors X window creation events. It monitors each
event and looks for the creation of a window id lower
than that of the
root window. All application windows will have window
ids higher than
that of the root window. The only windows having ids
lower than the root
window are special window ids preallocated within the
X server. To my
knowledge, this fact is not documented anywhere but
in the server code.
Fortunately, the screen saver uses one of these special
window ids to
display the familiar X logo, so receiving a creation
event for a window
id less than that of the root is a sure sign that the
screen saver has
been invoked and the preceding time-out period has expired
When the chkact program determines that the screen saver
triggered, it resets the screen saver and exits with
a return code of 0.
The monitor script (xmon) detects the return code of
0 and invokes the
screen lock program. After the lock is opened by entering
password, the monitor script reinvokes chkact, and the
until a signal is received by chkact.
When chkact receives a signal, it resets the screen
saver and exits with
a return code of 1. The monitor script detects the nonzero
To invoke Example 1, add the following command to .profile
session startup script:
lock=/usr/bin/lock monitor 300 &
The above will invoke /usr/bin/lock to lock the screen
after 300 seconds
of inactivity. Monitoring will be continuous until a
kill signal is sent
to the monitor process.
To invoke Example 2, add the following command to .xsession
session startup script:
lock=/usr/bin/X11/xlockxmon 300 &
The above will invoke /usr/bin/X11/xlock to lock the
screen after 300
seconds of inactivity. Monitoring will be continuous
until a kill signal
is sent to the chkact process. It is best to kill chkact
first so the
screen saver can be reset.
About the Author
Doug Morris has a B.S. in Mathematics and an M.B.A.
Information Systems. He is a UNIX enthusiast and long-time
advocate. He has been an active participant in XOpen,
an elected office on the XOpen User Council Executive.
He has held
various positions in technology evaluation and management
Fortune 500 companies, including his current position
as a Systems
Specialist/Software Engineer at a major international
oil company. He
can be reached at his personal email address of damorri.msn.com.