Simple Screen Auto-Locking Mechanisms
Doug Morris Computer security is a major concern of most corporations. In the information age of today, corporate computing services and databases are major assets that must be closely guarded against intruders both inside and outside the company. Many computer crimes, however, can easily be prevented by such common practices as instructing employees to logout 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 the full authority and identity of the logged-in user. The exposure of unattended terminals is well recognized. Most corporate 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 termination of the user's processes could result in corrupted files and/or lost data. For this type of environment a gentler approach, such as automatic screen lock, is more appropriate. The automatic screen lock accomplishes many of the objectives of the forced logoff. It does not free up computing resources like a true logoff, but it does protect unattended terminals from being used by unintended parties. How Screen Locks Work The concept of an automatic screen lock is simple. The computer monitors terminal (screen) interactions, such as key presses and mouse movements, and when interactions cease for a preset period of time, locks the screen. Locking the screen usually implies some or all of the following measures: 1. Protecting the screen contents from public view -- The screen is blanked or overwritten with a warning screen or changing screen saver 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 points. 2. Locking the keyboard The keyboard is put into a locked state where key presses are no longer sent to the underlying programs or operating 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 movements, button presses, and similar input events are no longer sent to the underlying programs or operating system. All input events are either ignored, or like keyboard activity, sent to the locking program. Given the above measures, the terminal or display is effectively rendered useless to anyone wanting to gain access during the locked period. 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 manual and auto-screen lock capabilities should be readily available to users. Screen lock programs are available from many third-party vendors, and most workstation vendors usually supply some sort of manual screen lock. Unfortunately, most do not provide auto-screen locks, (however, simple 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 an auto-screen 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; for X graphics, simply use a public domain program such as xlock. xlock can be obtained directly from the X Consortium ftp site at ftp.x.org. The pathname of the latest version is:
/contrib/applications/xlockmore-3.6.tar.gz.
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 helper scripts, _kbr and _msr. These scripts are used to obtain cumulative counts on keyboard and mouse activity (i.e., key press/releases and mouse movements/presses). The monitor script determines whether the terminal 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 terminal is assumed to be unattended, and it is locked. If activity did occur during the sleep interval, then the monitor process is repeated continuously 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. Similar 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 through the proc filesystem. The proc filesystem is a virtual filesystem that contains no real data. The files and directories in the proc filesystem are access paths to information on system and user processes and kernel structures. For example, the file /proc/interrupts contains cumulative information on device statistics one line for each device. SunOS and other BSD derivatives allow access to kernel structures through the /etc/pstat command. On SunOS systems, the keyboard (/dev/kbd) and mouse (/dev/mouse) devices are stream devices. This means the file table offset entries reflect cumulative counts for device events (for nondevice files, the file table offset entries record local offsets that apply to one or more file descriptors). The helper scripts use this fact to extract offsets from the file table using vnode pointers cross-referenced from the streams table. The appropriate 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 dependent and usually requires access to implementation-specific kernel memory structures. Fortunately, if X is the windowing system, this level of monitoring is not necessary. X can be tricked into doing the monitoring as shown in the next example. Example 2 -- Auto-Lock for an X Terminal or Workstation Running X As in the first example, you will need a background monitor script. The script in this case, uses an X program (chkact) to do the actual keyboard and mouse monitoring. The monitor script simply examines the 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 through the XSetScreenSaver call. The second parameter (wait) in the call 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 window creation 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 without any input. When the chkact program determines that the screen saver has been 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 the correct password, the monitor script reinvokes chkact, and the process repeats 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 return code and ends. Example Invocations To invoke Example 1, add the following command to .profile or other 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 or other 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. in Management Information Systems. He is a UNIX enthusiast and long-time Open Systems advocate. He has been an active participant in XOpen, including holding an elected office on the XOpen User Council Executive. He has held various positions in technology evaluation and management at several 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.
|