Recently, I posted about two screen lockers that I’ve used in the past (
slock). There has been some great discussion about these lockers, and some potential security problems that come along with using them. One very prominent issue regarding using screen lockers without login managers was raised by a reader, and I want to address it in this separate post.
Just as some background information, many people prefer to use login managers (also known as display managers) in order to be greeted by a graphical login prompt. To use these managers, the X Window System must be started as one of the final steps of the boot process (either by setting the default runlevel to 5 in
inittab, setting the display manager to start via the rc system / a daemon, or another method). Some people don’t like the idea of a login manager starting automatically at the end of the boot process, and would prefer to simply be greeted with a terminal login prompt. For those users, it is obviously still necessary to log in as a valid user, but then to start an X session (for their respective graphic environment), one must issue the
The problem with screen lockers and the
startx method of starting Xorg is that it presents a large security flaw. I mentioned in the previous post that one can switch to a different virtual terminal (by using the
CTRL+ALT+F# key combination) and log in as a different user. Unless that user can become root and kill the screen locker, though, there’s no problem. However, when Xorg is started using
startx, a person can switch to the virtual terminal that issued the
startx command, and just hit
CTRL+C to kill it. They will then be at the prompt for the user that issued the command, and won’t have to log in. Oops…
A good workaround for this problem is to start Xorg and make sure that the terminal is locked if X is killed. This workaround relies on the package
vlock, which is a terminal locking application. For it to work properly, instead of issuing the standard
startx command, one needs to issue
startx ; vlock. That way, if a person switches to the virtual terminal that started the X session, and hits
CTRL+C, it will kill X, but that will automatically start
vlock, and subsequently, present the person with nothing more than a login prompt. What’s more, that person will have to enter the password for the user that started the X session.
There might be more elegant methods for fixing this problem, including a script to disable virtual terminal switching when the screen locker is called, and I’ve been looking into such methods. If anyone has further suggestions regarding workarounds, or more permanent solutions, please feel free to comment.