Notice
You can actually avoid this problem by usingexec startx instead of just startxFor many years now, I have used a very simple screen locker called xtrlock in order to stop others from accessing my systems whilst I’m away from my desk. Some time ago, I switched from using Gentoo on my Samsung NC10 netbook to using Arch. Though I prefer Gentoo, it just didn’t make much sense to compile everything on that poor Atom N270 processor (think Chromium or LibreOffice). Anyway, Arch does not have xtrlock in their repositories, likely because it has been abandoned upstream since 2010 (although the Debian homepage for the package shows an update to version 2.2 as of June 2012). So, I needed to find an alternative package for locking my screen.
Seeing as I am a minimalist, I wanted something incredibly lightweight without a bunch of features that I will never use or dependencies linked to the libraries of some particular desktop environment. Through some quick searching, I found slock, which is arguably even lighter and featureless than xtrlock. Xtrlock displays a little blue lock icon in front of the active desktop, only allowing for cursor movement until one enters the password of the user who invoked it. Slock, on the other hand, doesn’t even show the desktop or an icon. Instead, it shows a black screen. Similar to xtrlock, slock requires one to enter the password of the user that started the application in order to see the desktop again. So, both applications are very similar in nature and execution.
Both applications also have a similar “flaw,” which likely won’t have much of an impact, but is worth mentioning. When the screen is locked using either application, one can switch to a different virtual terminal (by using the CTRL-ALT-F# combination for the desired virtual terminal) without entering the password of the user that started the locking application. Now, that user can log in to the system, but cannot kill xtrlock or slock unless they can become root. However, it does pose a bit of a security concern in some use cases that don’t really apply to my situation. If you can think of some other possibilities, feel free to leave a comment here, and I’ll further investigate.
So, which application is better? Seeing as they both accomplish the same task, they are both lightweight and unobtrusive, and they are both available via Portage, it would seem to be a stalemate. However, the two each have one exclusive plus, respectively. Xtrlock still shows the display. That means that if you are in an environment where you need to have an application (like ping or watch -n 1 'netstat -tupan' running even whilst you are not directly in front of your computer, it will still run and you can still see it. That may also be an unlikely use case though. Slock, by only showing a black screen and not indicating any type of other activity, may be an added layer of security through obscurity. In either case, both applications are relatively similar.
Cheers,
Zach
EDIT: Be sure to view the update to this post for more information about a security problem with startx and screen lockers.
29 comments
2 pings
Skip to comment form
I use slock it is a bit simple but works. I have sudo on my system and user pass word set up so even if you switch tty you will need user pass word and root password, so for me it is secure.
I was looking for a light screen locker, like you. I tried slock but it doesn’t feet my needs because of the colors used when typing passwords (they’re not customizable, without modifying source code). I found i3lock, which is customizable and uses an original way to show password typing and validity.
I also use startx in order to start graphical environment. But X server is started in the same VT from which it was launched. I think it’s the more secure way (like it was said in a previous comment) and, moreover, it’s a good way to not waste a VT.
I used cdm (Console Display Manager) in the past. It’s light (a simple bash script using dialog) and take care of X server launching (maybe covering some security holes). Perhaps it will feet your needs !
I use xtrlock and like it a lot. I use awesome wm and use startx to start my graphical environment. I found that it is possible to switch to the terminal I started X from and kill it by pressing ctrl C and so gain access to my terminal. I’ve solved that problem by emerging vlock and starting X with the command startx; vlock. Is there a better way of achieving this?
Author
Hello Ro,
Using startx instead of a login manager, and coupling it with a screen locker definitely poses a big security risk. Using vlock in the way that you do is definitely one way around it. Whilst it might not be the most “graceful” way of achieving the goal, it certainly does the job, and is likely the least intrusive (and we all know what Ockham would say about that). 🙂
Cheers,
Zach
That’s not just logic. That’s really sesnbile.
It’s always a relief when someone with obvious expertise answers. Thanks!
use “exec startx” instead of “startx”, luke!
Author
Hello Vasya,
Indeed, that is the workaround that I use for starting Xorg these days. That’s quite an old post and honestly I had forgotten about it. I have updated it accordingly.
Cheers,
Zach
An ugly fix for virtual terminal switching (and killing X server with A+C+Bs) issue is to modify the keymap temporarily using xmodmap, or more completely with setxkbmap. Switching VT are nothing more than commands bound to keys:
$ xmodmap -pk |grep “(F1)”
67 0xffbe (F1) 0xffbe (F1) 0xffbe (F1) 0xffbe (F1) 0xffbe (F1) 0xffbe (F1) 0x1008fe01 (XF86Switch_VT_1) 0xffbe (F1) 0xffbe (F1) 0x1008fe01 (XF86Switch_VT_1)
$ xmodmap -pk |grep Terminate
22 0xff08 (BackSpace) 0xfed5 (Terminate_Server) 0xff08 (BackSpace) 0xfed5 (Terminate_Server) 0x0000 (NoSymbol) 0x0000 (NoSymbol) 0xfed5 (Terminate_Server) 0x0000 (NoSymbol) 0x0000 (NoSymbol) 0xfed5 (Terminate_Server)
I don’t remember if these commands can be grabbed (i.e. handled by clients). Personally I don’t feel like asking to X experts, but just FYI.
Regards.
Author
That is indeed an ugly hack, but it makes perfect sense! Thank you for sharing it with us, Teika. I will give it a go, and see what else I can make of it.
Cheers,
Zach
Hi. The man page of good old xscreensaver says:
“Unfortunately, there is no way for xscreensaver itself to override the interpretation of these keys…To globally disable VT switching, you can set the DontVTSwitch flag”
You can trust this statement, I think, since old days developers knew X well. So the workaround above may be the only way out. You can use grep / sed (I’m not good at them.) to save and modify the involved keys, and restore them after unlocking.
In the previous comment I mentioned setxkbmap, but forget it.
# I was not sure if xmodmap can faithfully restore the original configuration for complex cases, but it seems OK. I mean by “complex” combinations “Alt+Ctrl” etc. (In the XKB language, special “type”.) For the simplest case on the other hand, the columns in xmodmap output corresponds to plain and shifted. xmodmap man says it only supports up to 8 columns, but even 10 are accepted as far as I tested.
Author
This could, indeed, be the only feasible workaround. I’ll see what I can do to make it happen, and post my findings.
Thanks again Teika!
Cheers,
Zach
Hi again, Zach. I come to think this issue is important, and it’s a shame that the X community has negelected it for years. Thanks for raising it.
Unless X implements dynamics switching of DontZap and DontVTSwitch, my solution is the only way. Replacing Terminate_Server and XF86Switch_VT_* with “NoSymbol” does the job.
I found another, less optimal solution. xlockmore provides a vt locking option. (But as far as I tested a Gentoo package, it didn’t work. Passing “-vtlock noswitch” + setting mode 4755 should work, but didn’t.) It relies on VT_LOCKSWITCH ioctl, which requires the root priv. This is not the best, because 1. it’s only for linux, but X is used outside of linux, too. 2. it doesn’t prevent Ctrl+Alt+BS server killing, anyway.
Regards.
Author
Hi Teika,
Thanks for spending so much time, and for your diligence in researching the problem. I’ll see what I can find regarding the problem. As for me, it isn’t a huge issue considering my only system that uses X is a single-user system. That being said, it does seem like a bit of a security problem.
Cheers,
Zach
Guys, “xlock -mode clock” is the funkiest minimal design looking screenlock ever.
Stuff this into .Xresources and give it at try.
!! — XLock —
XLock.clock.count: 1
XLock.clock.size: 0
XLock.description: False
Xlock.echokeys: True
XLock.echokey: *
XLock.erasemode: no_fade
Author
I would assume that xlockmore will do the trick?
$ eix xlock
* x11-misc/xlockmore
Available versions: 5.31 5.37 5.38 (~)5.39 (~)5.40 {{crypt debug gtk imagemagick motif nas opengl pam truetype xinerama xlockrc}}
Homepage: http://www.tux.org/~bagleyd/xlockmore.html
Description: Just another screensaver application for X
yes, xlockmore is the up to date maintained version.
A few weeks ago I switched from slock to slimlock. You get a Gentoo (or Arch) logo and a textbox. But it looks like it still allows you to switch to a different VT.
Author
Hi Nico,
Yes, I’ve heard of slimlock, and actually think that I saw a write-up about it recently. I’m thinking that Rafael was correct in his comment about the issue being more closely tied to Xorg rather than the locking programme. However, it would be nice if I could find a workaround that only disabled VT switching whilst the lock screen was enabled.
Cheers,
Zach
I have been using both of time for a while to (also use gentoo and arch next to eachother). A while a go i switched to i3lock which is available in the repositories of both of them.
It has the ability to choose your background color or even a png image.
Unfortunatly makin a transparent png doesnt work 🙂
Author
Hi Jo,
Thanks for the information about i3lock. I’ll have to play around with it at some point. I believe that I ran across a forum post at some point where a user had modified slock to display a custom background as well, but it wasn’t something that I cared to do at the time. i3lock is definitely worth a look.
Cheers,
Zach
I use alock which is similar to XtrLock in the sense of allowing the view of the desktop. I’ve two monitors with full screen tail -f of remote logs with ccze on last virtual desktop, and a khotkey that switches there and calls alock, assigned to one of those useful extra keys of new keyboards).
Author
Hello Rafael,
I haven’t used alock before, but will have to look into it as well. Does it also have the problem of being able to switch to a different virtual terminal when engaged?
Cheers,
Zach
Yes, it does allow that, but I think you aren’t doing it right:
There’s an Xorg setting “DontVTSwitch” that controls this behavior.
Author
Rafael,
Thank you for the information regarding the DontVTSwitch directive within Xorg. However, I am not looking to disable the possibility of switching to a different virtual terminal. Rather, I’m wanting a screen locker that disables the function keys, making switching impossible whilst the screen is locked. Again, I appreciate your insight.
Cheers,
Zach
You could put xtrlock into a script along with an xmodmap that disables the Alt key and then run that script using xautolock. The only problem would be re-enabling the Alt key. Just a thought.
Author
That’s definitely a thought; thanks for the suggestion. 🙂
Cheers,
Zach
Like you, I have used xtrlock for many years now on Gentoo, and still do. I’ve always wondered about how secure it really was, if it had any loopholes. Since I start X manually through startx I use tmux (and before that I used gnu screen) to log out from the tty terminal after X starts otherwise it’s pointless due to the flaw you mentioned.
I haven’t tried slock but I would definitely dislike the black screen because it would force me to unlock it more frequently, for example to check if something requires my attention.
I hope xtrlock stays in portage for a long time because I really can’t live without it 🙂
Author
I completely agree about xtrlock. It is a great little application. I switched to slock because it works for my needs, but I certainly see the purpose of being able to see what’s going on in the background. At this point, I don’t see why it would get removed from the tree unless there’s a gigantic security flaw that won’t be patched upstream. Even then, there may be a Gentoo developer willing to take a shot at patching it. 🙂
Cheers,
Zach
[…] use xtrlock on Debian, but it seems to be unavailable on Arch. Here’s a blog post describing some of the alternatives on […]
[…] I posted about two screen lockers that I’ve used in the past (xtrlock and slock). There has been some great discussion about […]