Secure your unattended terminal from prying eyes.
If you work in a networked environment, the importance of locking your screen before leaving your workstation has probably been stressed to you. After all, your brilliant password becomes moot if anyone can walk up to your logged in station and start poking about the contents of your home directory.
If you use a GUI on your workstation, your Window Manager probably includes a locking feature. However, if you use a terminal, you may not be aware of the mechanisms available for locking your terminal.
As an administrator, you may want to automate these mechanisms as part of your security policy. Fortunately, FreeBSD’s screen locking mechanism is customizable.
FreeBSD comes withlock(and it’s available for NetBSD and OpenBSD). Its default invocation is simple:
Without any switches,lockwill request that the user input a key which will be used to unlock the terminal. This is a good thing, as it gives the user an opportunity to use something other than her login password. If the user tries to be smart and presses Enter (for an empty password), thelockprogram will abort.
Once a key is set, it is required to unlock the screen. If a user instead types Ctrl-c, she won’t terminate the program. Instead, she’ll receive this message:
Key: lock: type in the unlock key. timeout in 10:59 minutes
Did you notice that timeout value of 15 minutes? At that time, the screen will unlock itself, which sorta diminishes the usefulness of locking your screen. After all, if you run into your boss in the hall, your 5-minute coffee break might turn into a 25-minute impromptu brainstorming session.
To lock the terminal forever, or at least until someone types the correct key, use the-nswitch. If the system is a personal workstation,-vis also handy; this locks all of the virtual terminals on the system, meaning a passerby can’t use Alt-Fn to switch to another terminal.
As an administrator, you can assist users in using the desired switches by adding an alias to /usr/share/skel/dot.cshrc [Hack #9]. This alias removes the timeout and locks all terminals:
alias lock /usr/bin/lock -nv
If you use thetcshshell, you also have the ability either to lock your session or to be logged out of your session automatically after a set period of inactivity. As an administrator, you can set your policy by adding a line to /usr/ share/skel/dot.cshrc.
Theautologoutvariable can accept two numbers. The first number represents the number of minutes of inactivity before logging out the user. The second number represents the number of minutes of inactivity before locking the user’s screen. Once the screen is locked, the user must input the password to unlock it. If the screen is not unlocked in time, the user will be logged out once the shell has been idle for the logout period of minutes.
The manpage is pretty vague on how to set those two numbers. For example, if you try:
set autologout = 30 15
users will receive this error message when they try to log in:
set: Variable name must begin with a letter.
That’s a deceptive error message, as this variable does accept numerals. The correct invocation is to enclose the two numbers between parentheses:
set autologout = (30 15)
This particular setting will log out a user after 15 minutes of inactivity. The user will know this happened as the terminal will resemble:
After 30 minutes of inactivity (or 15 minutes after the screen was locked), the user will be logged out and see this:
What if you do want to enforce a logout policy that users can’t change in their shell configuration files? Consider usingidled, which can be installed from /usr/ports/sysutils/idled or built from source. This utility was designed to log out users either after a configured period of inactivity or after they’ve been logged in for a certain amount of time.
Once you’ve installedidled, copy the template configuration file:
# cd /usr/local/etc/
Open /usr/local/etc/idled.cf using your favorite editor. You’ll find this file to be well commented and quite straightforward. You’ll be able to configure the time before logout as well as when the user will receive a warning message. In addition, you can refuse logins, set session timeouts, and provide for exemptions.
blog comments powered by Disqus