How secure are screen lockers?
491 views
Skip to first unread message
Axon
Aug 17, 2014, 11:17:02 AM8/17/14
to qubes...@googlegroups.com
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
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
Joanna Rutkowska
Aug 18, 2014, 4:48:44 AM8/18/14
to Axon, qubes...@googlegroups.com
> 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]
>
solutions that are discussed there.
> 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.
>
with KDE?
> * 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]).
>
>
broken just because some bloated software crashes or users tend to log
in to text consoles and don't log out before screenlocking. I think we
should test the solutions discussed in [17] as well as find some more
reliable screenlocking software.
https://wiki.qubes-os.org/ticket/888
Thanks,
joanna.
Vincent Penquerc'h
Aug 18, 2014, 4:55:54 AM8/18/14
to qubes...@googlegroups.com
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
>> * 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?
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...
Axon
Aug 18, 2014, 5:08:07 AM8/18/14
to Joanna Rutkowska, qubes...@googlegroups.com
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. ;)
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. ;)
Axon
Aug 18, 2014, 5:10:27 AM8/18/14
to Vincent Penquerc'h, qubes...@googlegroups.com
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.
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.
Vincent Penquerc'h
Aug 18, 2014, 5:16:25 AM8/18/14
to Axon, qubes...@googlegroups.com
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
> 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.
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.
Axon
Aug 18, 2014, 6:10:37 AM8/18/14
to Joanna Rutkowska, qubes...@googlegroups.com
Axon:
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. :)
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. :)
ro...@rowanthorpe.com
Aug 20, 2014, 7:47:02 PM8/20/14
to qubes...@googlegroups.com, joa...@invisiblethingslab.com, ax...@openmailbox.org
> ..[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).
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).
Axon
Aug 24, 2014, 2:44:39 PM8/24/14
to ro...@rowanthorpe.com, qubes...@googlegroups.com, joa...@invisiblethingslab.com
ro...@rowanthorpe.com:
Interesting suggestion; thank you! I wonder if any of these criticisms
of xlock also apply to vlock:
http://www.jwz.org/xscreensaver/versus-xlock.html
Also, I noticed this line in the man page:
> vlock works for console sessions primarily. However, there is
> support for trying to lock non-console sessions as well, but that
> support has not been well tested.
I wonder if this should be a concern.
of xlock also apply to vlock:
http://www.jwz.org/xscreensaver/versus-xlock.html
Also, I noticed this line in the man page:
> vlock works for console sessions primarily. However, there is
> support for trying to lock non-console sessions as well, but that
> support has not been well tested.
I wonder if this should be a concern.
Axon
Aug 24, 2014, 3:08:31 PM8/24/14
to ro...@rowanthorpe.com, qubes...@googlegroups.com, joa...@invisiblethingslab.com
ro...@rowanthorpe.com:
This is also similar to using physlock, right?
https://github.com/muennich/physlock
https://github.com/muennich/physlock
Axon
Aug 24, 2014, 4:15:11 PM8/24/14
to qubes...@googlegroups.com
Axon:
I just noticed something interesting. When the XScreenSaver lock screen
goes "transparent," the state of the screen it shows is often a few
seconds old (or older). In other words, this sort of thing often happens:
1. Start with one window open on desktop.
2. Open a second window.
3. Press CTRL+ALT+L to lock the screen and put the monitors to sleep.
4. Move the mouse to wake the monitors.
5. Monitors show an unobstructed view of the desktop, but only *one*
window (the first) appears to be open. All cursor movements are
constrained to the small rectangular space where the password prompt
should be. All keystrokes are captured by the (invisible) lock screen.
6. Press ESC repeatedly (or just hold it down) to toggle the password
prompt until the lock screen returns to normal.
7. Enter password to unlock the screen.
8. Return to desktop with *two* open windows.
Perhaps this clue will allow a knowledgeable reader to formulate a
hypothesis regarding the cause of this bug.
goes "transparent," the state of the screen it shows is often a few
seconds old (or older). In other words, this sort of thing often happens:
1. Start with one window open on desktop.
2. Open a second window.
3. Press CTRL+ALT+L to lock the screen and put the monitors to sleep.
4. Move the mouse to wake the monitors.
5. Monitors show an unobstructed view of the desktop, but only *one*
window (the first) appears to be open. All cursor movements are
constrained to the small rectangular space where the password prompt
should be. All keystrokes are captured by the (invisible) lock screen.
6. Press ESC repeatedly (or just hold it down) to toggle the password
prompt until the lock screen returns to normal.
7. Enter password to unlock the screen.
8. Return to desktop with *two* open windows.
Perhaps this clue will allow a knowledgeable reader to formulate a
hypothesis regarding the cause of this bug.
shadowd...@gmail.com
Sep 29, 2014, 11:50:14 AM9/29/14
to qubes...@googlegroups.com, ax...@openmailbox.org
There is always this: https://github.com/google/xsecurelock
Google created it for their linux systems. Full security overview here: https://github.com/google/xsecurelock#security-design
Reply all
Reply to author
Forward
0 new messages