I first raised this issue on 2013-12-22 in this[01] thread. There I
wrote:[02]

> In order to make a decision about how long and complex the
> screen locker password should be (and this is an important decision,
> since many users will be typing that password dozens of times every
> day), we must know what kind of security the screen locker provides.
> Obviously, the screen locker is only relevant to attackers with physical
> access to the system. But physical access comes in degrees. For example,
> if it's a desktop computer, the keyboard and mouse might be freely
> accessible while the tower is locked in a metal box. In this case,
> attacks which require access to internal components of the computer
> (like cold boot attacks) are significantly more difficult (the degree of
> difficulty depends on things like how hard it is to cut through the
> metal box or break/pick/bump the lock). In this scenario, the screen
> locker might be very useful *if* there really is no way to gain access
> without the correct password. If it's easy to bypass the screen locker,
> then the owner of the computer will probably have a false sense of
> security (and have wasted money and effort on putting the tower in a
> locked metal box!).

(Note: Throughout this discussion, I am assuming that other attack
vectors, e.g., USB, have been secured by other means, e.g., with a
USBVM. This is about an unauthorized user who interacts *only* with the
keyboard/mouse while the screen is locked.)

The topic of screen lockers has come up numerous other times in the past
on these lists.[03][04][05][06][07] However, in every case, the
correspondents seem to assume that the screen locking mechanism is
itself secure.

This is an important issue, because the Qubes security model explicitly
relies upon the screen locker to protect against certain attack vectors.
For example, when the host system is powered on and the user is logged
in, but the computer is briefly or unexpectedly left unattended, the
default screen locker is explicitly trusted to prevent unauthorized
access to dom0.[08]

Even proposals about adding additional authentication requirements for
screen unlocking seem to assume that the underlying default screen
locking mechanism is secure.[09]

However, it is far from clear that the default screen locking mechanism
is, in fact, secure. There are several reasons for this.

First, there have been multiple well-publicized cases of past bugs which
have allowed screen lockers on a variety of Linux systems (including
Fedora) to be easily bypassed with only keyboard access.[10][11][12][13]

Second, there is controversy over the relative security of different
screen saving/locking programs. For example, Jamie Zawinski has
forcefully argued that the minimal library usage of the XScreenSaver
daemon makes it far more secure than both GNOME's and KDE's screen
savers/lockers (which he describes as "bug-ridden, unreliable, and an
ongoing security disaster").[14][15][16] However, the default screen
locker used in Qubes is KDE's default screen locker, kscreenlocker.
(This is because kscreenlocker is the default screen locker in KDE,
which is itself the default DE used in Qubes.)

Third, even purportedly secure screen lockers like XScreenSaver are
still at the mercy of X11 and the Linux kernel, which sometimes make it
impossible for any screen locker to be implemented securely.[17]

Fourth, there have been reported cases on these lists of screen
savers/lockers failing to properly obscure the screen.[18] Although some
of these bugs have been fixed, many persist. For example, on my system,
if more than one monitor is connected, the (sometimes partial, sometimes
total) contents of my desktop become visible (after some period of time,
for no apparent reason) *instead of* the screen locker prompt. This
occurs no matter what I do or which screen saver/locker I use. In fact,
I seem to be able to attach an additional monitor in order to trigger
this effect at will. Even though keystrokes and mouse input are all
captured by the screen locker, it's obvious that an attacker could use
this technique to leak information from a locked session. (Switching to
a different virtual desktop has no effect, as the contents seem to be
randomly gathered from different VDs or superimposed from multiple VDs.)

Fifth, even "properly functioning" screen lockers do not by themselves
(i.e., without being paired with something like physlock[19]) prevent
unauthorized users from tampering with the system, e.g., by allowing
anyone to (intentionally or unintentionally) crash the system by trying
to enter a new login.[20]

So, what should we do?

The purpose of this email is not to endorse any particular course of
action. (I defer to Joanna, Marek, and other security experts on this.)
Rather, the purpose is to bring awareness to this issue and to gain
insight from the community. Nonetheless, it is generally undesirable to
point out problems without at least attempting to offer ideas for
potential solutions. Thus, here are some things we might want to do for
Qubes:

 * Rather than just accepting the dom0 distro default screen locking
program, we could make a conscious security decision about the screen
locker. This would mean determining, if we can, which screen locker
program would be the most secure default screen locker in Qubes
(XScreenSaver?), and making that screen locker the default (and turned
on!) in every new Qubes installation.

 * Adjust the default settings of the screen locker program chosen in
the previous step in order to make it more suitable for Qubes. (E.g.,
remove all multi-user functionality, such as the "New Login" button.[20])

 * Consider hardening "locked" sessions in other ways (ideas inspired by
[19]?).

 * Finally and ultimately, if screen locking is inherently insecure,[17]
we should think about "migrating away" from the obsolete "screen locker
security model." In practical terms, this means finding ways to mitigate
or eliminate our dependence upon it (e.g., [05]).



[01]https://groups.google.com/d/topic/qubes-users/r9dTJGTzXzY/discussion
[02]https://groups.google.com/d/msg/qubes-users/r9dTJGTzXzY/C79GPTLaIoUJ
[03]https://groups.google.com/d/topic/qubes-users/0bwygZ4poJU/discussion
[04]https://groups.google.com/d/topic/qubes-users/hkrk0yiH_Yo/discussion
[05]https://groups.google.com/d/topic/qubes-devel/1B2KDyenYVg/discussion
[06]https://groups.google.com/d/topic/qubes-devel/0itE7qkZnJ4/discussion
[07]https://groups.google.com/d/topic/qubes-devel/wHsrkzj3_qI/discussion
[08]https://groups.google.com/d/msg/qubes-users/hkrk0yiH_Yo/dntKwiNVDsMJ
[09]https://groups.google.com/d/msg/qubes-users/r9dTJGTzXzY/AyHEbKI2qSoJ
[10]https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1308572
[11]https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1313885
[12]https://bugzilla.redhat.com/show_bug.cgi?id=1064695
[13]http://www.webupd8.org/2012/01/xorg-111-vulnerability-allows-attackers.html
[14]http://www.jwz.org/xscreensaver/toolkits.html
[15]http://www.jwz.org/xscreensaver/man1.html#8
[16]http://www.jwz.org/xscreensaver/man1.html#9
[17]http://www.jwz.org/xscreensaver/faq.html#no-ctl-alt-bs
[18]https://groups.google.com/d/msg/qubes-users/0bwygZ4poJU/62wfFLorDXEJ
[19]https://github.com/muennich/physlock
[20]https://groups.google.com/d/topic/qubes-users/uCA8_7t2JVY/discussion

On 18/08/14 09:48, Joanna Rutkowska wrote:
>>  * Rather than just accepting the dom0 distro default screen locking
>> program, we could make a conscious security decision about the screen
>> locker. This would mean determining, if we can, which screen locker
>> program would be the most secure default screen locker in Qubes
>> (XScreenSaver?), and making that screen locker the default (and turned
>> on!) in every new Qubes installation.
>>
>
> I like this approach. Anybody has experience with using XScreenSaver
> with KDE?

FWIW, I'm using xscreensaver on another computer (not with KDE), and I
find it sometimes fails to lock at all (as in, blanked screen, but no
password screen afterwards). IIRC, device grab failure. It's a rare
occasion, so hard to tell if "fixed" and probably needing a lot of
testing time...

Joanna Rutkowska:
Well, I do now. :P

It's actually very simple. I just followed the instructions at [16], and
it works fine (except when I try to use multiple monitors, as I
mentioned previously).

IMO, XScreenSaver has some very nice features compared to the KDE
default. The main one is that, once you successfully unlock the screen,
it tells you how many failed login attempts there have been. So, there's
at least a chance that you'll be tipped-off in the even that an evil
maid makes a mistake while trying to attack your machine. ;)

Vincent Penquerc'h:
Is it that the lock screen is invisible/transparent (yet all of your
keyboard/mouse input is captured), or is that there's really no lock
screen (and you can freely interact with the OS)? As I mentioned in my
previous email, I've regularly experienced the former when trying to use
multiple monitors.

On 18/08/14 10:10, Axon wrote:
> Is it that the lock screen is invisible/transparent (yet all of your
> keyboard/mouse input is captured), or is that there's really no lock
> screen (and you can freely interact with the OS)? As I mentioned in my
> previous email, I've regularly experienced the former when trying to use
> multiple monitors.

Really no lock screen, just the screen blank. Laptop without external
monitor. I might have a weird setup though (Ubuntu base with WM killed
and fluxbox instead). But it works fine most of the time, so I don't
*think* it's the reason.

Vincent Penquerc'h:
Ah, I see. Well, then your experience regarding the reliability of
screen lockers is, unfortunately, quite similar to my own.

> ..[snip]..

> I've added Qubes-specific instructions for making the switch here (in
> case XScreenSaver ends up being chosen):
>
> https://wiki.qubes-os.org/ticket/888#comment:1
>
> Hopefully that makes your and/or Marek's job on this ticket a little
> easier and faster. :)

> ..[snip]..

Although a silent listener and enthusiast about Qubes for a while, I have yet to be an actual "user", so am aware my input might be slightly wonky, but I'll throw it in in case it adds any value if you are investigating safest/simplest "baseline screenlock" options: I prefer to disable all X-based screenlockers/savers and set an autostart file with a oneliner along the lines of:

  xautolock -locker 'sudo vlock -a -n -s' -time 3 -detectsleep ...

on my Linux-based machines (-a = lock all VCs, -n = switch to a new VC, -s = disable sysrq magic keys while locked). If memory serves correctly I think the -n and -s are provided by its plugin framework (at least on recent releases of Debian and Gentoo both flags are included by default). I have found it to be the most reliable and safe (minimal) solution for me on various WMs/DEs, and has never had a problem with multiple monitor setups or hibernate/resume either. The new plugin framework for vlock also allows for hooking in eye-candy "screensaver" stuff, but I haven't investigated it (I am happy with a "this screen is locked" message).

There is always this: https://github.com/google/xsecurelock