Change default screen locker from XScreenSaver

[mfc]

Editor's note: This issue has evolved beyond the original issue description. Please see the comments below for more recent information about this issue.

---

Qubes OS version (e.g., R3.1): R3.1

---

Expected behavior:

lock screen looks like log-in screen

Actual behavior:

lock screen looks wacky-different. also ugly.

Steps to reproduce the behavior:

lock screen in XFCE

General notes:

see this Ask Ubuntu for reasons why this is a bad lockscreen: https://askubuntu.com/questions/216323/ugly-lock-screen-in-xubuntu

perhaps switch to gnome-screensaver as suggested in the Ask Ubuntu thread.

[marmarek]

I agree that xscreensaver is ugly. But it is effective. And given a number of problems with other screenlockers (#888, #963), not sure if it wise to change it here. Requires a lot of testing.
Actually it may be better to switch to something even uglier - physlock, in all desktop environments.

[ghost]

Indeed there have been quite a few problems with the alternatives in the past
https://www.jwz.org/blog/2015/04/i-told-you-so-again/

[mfc]

is there any setting in xscreensaver to have it look like the XFCE log-in screen, rather than the default screensaver screen? having them look the same would be a step forward in UX, and the XFCE log-in screen certainly looks better.

[marmarek]

I'm not aware of any, unfortunately. There are settings for screen saver
itself, but not for password prompt.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[cfcs]

XScreensaver is a security disaster.
There is a long discussion / evaluation here:
#963

It's my personal opinion that spending time on prettifying a lock screen is great, but the work should be done on a screenlocking solution that we actually want to use. Please have a look at the two suggestions below:

• https://github.com/the-cavalry/light-locker/
• physlock (terminal-only, so no fancy bells and whistles).

[mfc]

XScreensaver is a security disaster.

confirmed: #2026

[cfcs]

I'm going to be bold and suggest that the KDE lock screen, apart from issues with random crashes, has similar issues related to stuff popping up on top, especially at times when you (or an attacker) attaches/detaches VGA/HDMI/whatever cables, or rotates monitors and so on.

Physlock is the way to go.

[andrewdavidwong]

XScreensaver is a security disaster.
There is a long discussion / evaluation here:
#963

No, that's a discussion of the KDE screen locker, which (as you know) is different. The only thing about XScreenSaver in that thread is a link to a problem with suspend. XScreenSaver is actually one of the more secure screen lockers available (which perhaps isn't saying much). At any rate, it does sound like physlock would be better.

XScreensaver is a security disaster.

confirmed: #2026

This, however, appears to be a legitimate security issue with XScreenSaver.

[cfcs]

@andrewdavidwong I kind of disagree, did you read the discussion? Anyway, the most important link in there, which I'd like to repost, is this one (by a KDE developer) who explains why the KDE screen locker is not sufficient, and why Xorg-based screen lockers are inherently insecure: http://blog.martin-graesslin.com/blog/2015/01/why-screen-lockers-on-x11-cannot-be-secure/

So, I restate my opinion about physlock and would like to hear some arguments against it. :)

[andrewdavidwong]

I kind of disagree,

You kind of disagree with what?

did you read the discussion?

Yes. I would not have said what I did if I had not.

Anyway, the most important link in there, which I'd like to repost, is this one (by a KDE developer) who explains why the KDE screen locker is not sufficient, and why Xorg-based screen lockers are inherently insecure: http://blog.martin-graesslin.com/blog/2015/01/why-screen-lockers-on-x11-cannot-be-secure/

What does this have to do with anything I said?

So, I restate my opinion about physlock and would like to hear some arguments against it. :)

What did I say that requires an argument against physlock or your opinion about physlock?

[cfcs]

No, that's a discussion of the KDE screen locker, which (as you know) is different.

@andrewdavidwong I kind of disagree, did you read the discussion?

You kind of disagree with what?

That the discussion is about the KDE screen locker [and all other Xorg-based screen lockers] is irrelevant to discussion of XScreenSaver security. The link provided in my comment above highlights why XScreenSaver (and the KDE screen locker, and all the other ones) is an attempt to solve the problem using an inherently insecure approach.

So, I restate my opinion about physlock and would like to hear some arguments against it. :)

What did I say that requires an argument against physlock or your opinion about physlock?

Nothing, except that XScreenSaver was one of the more secure projects around. That remark was meant for everyone, including @marmarek and people who can decide what goes into Qubes. I realize physlock is not very pretty, but perhaps it could be an optional thing? :)

PS: XScreenSaver nostalgia: http://insecure.org/sploits/xscreensaver.html ;)

[andrewdavidwong]

That the discussion is about the KDE screen locker [and all other Xorg-based screen lockers] is irrelevant to discussion of XScreenSaver security. The link provided in my comment above highlights why XScreenSaver (and the KDE screen locker, and all the other ones) is an attempt to solve the problem using an inherently insecure approach.

You specifically said "XScreensaver is a security disaster," so, naturally, I thought you were referring specifically to... XScreenSaver. If your comment was supposed to be about all Xorg-based screen lockers, then of course I agree. This is a point I raised about Qubes years ago:

https://groups.google.com/d/topic/qubes-devel/G_wVSL9WtEk/discussion

Nothing, except that XScreenSaver was one of the more secure projects around.

I said it's "one of the more screen lockers available (which perhaps isn't saying much). At any rate, it does sound like physlock would be better." As far as Xorg-based screen lockers go, I think it does better than most, but I also agree that Xorg-based screen lockers as a whole are problematic (again, this is all in the old thread linked above).

That remark was meant for everyone, including @marmarek and people who can decide what goes into Qubes. I realize physlock is not very pretty, but perhaps it could be an optional thing? :)

When it comes to security-critical components, I don't think prettiness should matter much, and I don't think a significantly more secure solution should be merely optional. It should be the default.

[marmarek]

What about light-locker? It spawns a second X server and switch to it for the locking. There are some technical difficulties with running a second X server in dom0, but I think it should be manageable.

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

[jpouellet]

We are in a unique position to be able to solve this once and for all in a more robust way than any other X-based system I am aware of.

We should be able to just kill and restart the entire dom0 X session (or s/dom0/GuiVM/ when we get there). This would not rely on your system not accidentally killing the screen locker, or accidentally making VTs available.

I've had this idea for a while, but implementation is blocked on not some issue reconnecting to already-running gui-daemons that I haven't gotten around to debugging. The same thing needs to be fixed to be able to log out and log back in (which happens sometimes, like when restoring a large VM backup and the OOM killer gets triggered in dom0 and decides X looks like the best candidate... sigh) instead of needing to reboot your whole machine.

[jpouellet]

The important thing to note is that we could do this without losing state about the currently logged-in session, because the AppVM X sessions stay alive but can be rendered inaccessible in a fail-closed manner unlike on other systems with a single X session connected to both the display and the apps you wish to protect needs to stay alive.

[marmarek]

Killing dom0 X session is not harmless. GUI daemon tries its best to recover what's possible but not everything is possible. For example:

• desktop assigned to windows will be lost (everything will appear on the same desktop)
• tray icons will get undocked, which is most cases require restarting an application to get them back
• restarting gui-daemon mean creating windows (at dom0 side) again, and window manager may decide to rearrange them

Some of those probably could be solved somehow, but in general touching anything around X11 handling is very risky. There are so many different toolkits, or even custom implementations that almost every change here breaks some application...

[cfcs]

@andrewdavidwong Cool, I think we're on the same page then!

@marmarek I think light-locker seems really promising. Someone (well, multiple independent people!) would have to investigate how well it manages in crash situations.

I think that killing the dom0 session to lock the screen is a bit over the top - you don't want that to happen in the middle of a dom0 update, or when doing any sort of maintenance. I usually keep a dom0 terminal window around at all times, I would hate if that was killed every time the screen went idle.
Also window placement, and everything else, would be totally fucked for users who use custom configurations for the window manager, or use their own window managers.

[jpouellet]

@cfcs If your only reason for wanting to retain a dom0 terminal is to ease disaster recovery in case of updates gone wrong (or other system-messed-up-ness), you can always just switch to a non-X VT (Ctrl+Alt+F2) and login there.

[ideologysec]

I'm sure this is buried in the issues or docs somewhere, but - at what point does Qubes envision transitioning to Wayland? (which would solve a heck of a lot of these "X11 lockscreens suck by design" problems.

Also, does physlock support YuibKey 2FA unlock? Wasn't able to dig up anything that said so (because while X11+YubiKey might be actually less secure than physlock, YubiKey+an actually secure screensaver would be dynamite).

[3hhh]

Since apparently everyone gave up on attempting to fix the underlying X issues, you could pretty much consider any X-based screensaver that fulfils the following requirements:

• succeeds at basic locking/unlocking tests (cat test)
• provides at least similar security standards as xscreensaver
• "doesn't look like malware" (UX)
• has some i18n features (UTF-8 support and language switch should suffice)
• ideally is in Fedora dom0 repos so that it doesn't require extra maintenance
• should have active maintenance to get upstream bug fixes

I'd recommend doing a comparison based on such pre-defined criteria to finally come to some conclusion.

E.g. IIRC both xsecurelock and light-locker should be available in 4.1 dom0 repos; so it should be rather straightforward to test them.

[unman]

On Sun, Mar 28, 2021 at 03:44:08AM -0700, 3hhh wrote: Since apparently everyone gave up on attempting to fix the underlying X issues, you could pretty much consider _any_ X-based screensaver that fulfils the following requirements: - succeeds at basic locking/unlocking tests (cat test) - provides at least similar security standards as `xscreensaver` - "doesn't look like malware" (UX) - has some i18n features (UTF-8 support and language switch should suffice) - ideally is in Fedora dom0 repos so that it doesn't require extra maintenance - should have active maintenance to get upstream bug fixes I'd recommend doing a comparison based on such pre-defined criteria to finally come to some conclusion. E.g. IIRC both [xsecurelock](https://github.com/google/xsecurelock) and [light-locker](https://github.com/the-cavalry/light-locker) should be available in 4.1 dom0 repos; so it should be rather straightforward to test them.

There is already a proposal on the table to use Xscreensaver, patched so it "doesn't look like malware". There is no need for any solution to be in the Fedora repos - we already ship a patched Xscreensaver to remove the "offending" update reminder. I'm not clear why any solution would need a "language switch" if by that you mean the capability to change languages *in the screenlocker* on the fly before inputting a passphrase. Is this common? Can you point me to an example?

[Edan-Redmind]

@3hhh I use english-only passwords but have secondary language installed. having some indicator for current language will help avoid "wrong pw msgs" when i don't recall what was the last input language i used when i left the workstation.

________________________________ From: unman ***@***.***> Sent: Sunday, March 28, 2021 5:41:42 PM To: QubesOS/qubes-issues ***@***.***> Cc: Edan Igali - Redmind ***@***.***>; Mention ***@***.***>

Subject: Re: [QubesOS/qubes-issues] Change default screen locker from XScreenSaver (#1917) On Sun, Mar 28, 2021 at 03:44:08AM -0700, 3hhh wrote: Since apparently everyone gave up on attempting to fix the underlying X issues, you could pretty much consider _any_ X-based screensaver that fulfils the following requirements: - succeeds at basic locking/unlocking tests (cat test) - provides at least similar security standards as `xscreensaver` - "doesn't look like malware" (UX) - has some i18n features (UTF-8 support and language switch should suffice) - ideally is in Fedora dom0 repos so that it doesn't require extra maintenance - should have active maintenance to get upstream bug fixes I'd recommend doing a comparison based on such pre-defined criteria to finally come to some conclusion. E.g. IIRC both [xsecurelock](https://github.com/google/xsecurelock) and [light-locker](https://github.com/the-cavalry/light-locker) should be available in 4.1 dom0 repos; so it should be rather straightforward to test them.

There is already a proposal on the table to use Xscreensaver, patched so it "doesn't look like malware". There is no need for any solution to be in the Fedora repos - we already ship a patched Xscreensaver to remove the "offending" update reminder. I'm not clear why any solution would need a "language switch" if by that you mean the capability to change languages *in the screenlocker* on the fly before inputting a passphrase. Is this common? Can you point me to an example? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#1917 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AM2W3KREKFBKXCCFQGCG46TTF452NANCNFSM4CBGN27Q>.

[unman]

@3hhh I use english-only passwords but have secondary language installed. having some indicator for current language will help avoid "wrong pw msgs" when i don't recall what was the last input language i used when i left the workstation.

I understand the problem.
My question was about the proposed:

has some i18n features (UTF-8 support and language switch should suffice)

I struggle to understand what "language switch" means here - an example from another locker would help.

[ninavizz]

^^ +1 to the question around language w/ lockers

[na--]

When you want to be able to type text in multiple languages, you do that by having multiple keyboard layouts on your system: https://docs.xfce.org/xfce/xfce4-settings/keyboard#layout

Keyboard layouts allow you to switch and be able to use the same keys on the same keyboard to type in different languages. You usually shift the layout by some shortcut (e.g. Ctrl+Shift), and typing "test" becomes "тест" or whatever. You also usually have a widget in the system tray that shows the currently active keyboard layout (as a flag or a language code or whatever you configure). QubesOS also has support for propagating the currently active keyboard layout from dom0 to VMs and that works reasonably ok.

Unfortunately, XScreenSaver is the worst possible screen locker in terms of password input UX, because it doesn't have any indication what keyboard layout you're currently using when typing your password. So if your password is TestPassword, you might be typing TestPassword or ТестПассворд, or even something else, if you have more than 2 keyboard layouts enabled. And you have to guess blindly - when it complains that your password is wrong, you don't know if you mistyped it or if you were in the wrong keyboard layout state.

As I explained above (#1917 (comment)), my situation is even worse, because my laptop doesn't have visual indicators for the capslock or numlock state, and re-uses part of the keyboard as the numlock 🤦‍♂️ . So, when typing my TestPassword password, I can be in one of 8 possible states and actually enter any one of these in the text field: TestPassword, tESTpASSWORD (caps), Test/assw6rd (num), tEST/ASSW6RD (caps+num), ТестПассворд (bg), тЕСТпАССВОРД (bg+caps), Тест/ассв6рд (bg+num), tEST/АССВ6РД (bg+caps+num). And, because XScreenSaver doesn't have any indication of the current keyboard state or layout, you have to blindly guess and toggle things on and off until you hit the correct one... Also, imagine what happens if you were in the correct state, by some miracle, but you actually mistype your password, because you are security-conscious person and have a reasonably complex one...

Pretty much all of the other screen lockers have a visual indication of at least the currently active keyboard layout and caps lock state. It makes a huge difference.

[na--]

Some examples from random locker screenshots found on the internet:

• see en_US in the upper right corner: https://xubuntu.org/wp-content/uploads/2014/03/xubuntu_lock_light-locker.png
• see en in the upper right corner again: https://vitux.com/wp-content/uploads/2018/08/word-image-94-768x432.png
• not sure about kde, but at least you seem to have the eye button that allows you to see what you've typed, so you can easily type test and see what state you're in without compromising your actual password: https://phabricator.kde.org/file/data/utcmshse2pn5j4vgyijj/PHID-FILE-nnprs6hnzbybuk6gr52q/KScreenLocker.png

[marmarek]

In short: it isn't really about language switch, but about keyboard layout switch.

[unman]

On Mon, Mar 29, 2021 at 04:04:03AM -0700, Marek Marczykowski-G??recki wrote: In short: it isn't really about language switch, but about keyboard layout switch.

Or display of current keyboard layout

[cfcs]

On Mon, Mar 29, 2021 at 04:04:03AM -0700, Marek Marczykowski-G??recki wrote: In short: it isn't really about language switch, but about keyboard layout switch.
Or display of current keyboard layout

Most users will not know what to do with that information if the keyboard layout is not the one they expect (ie the one printed on the keyboard).

[ninavizz]

Ok, so maybe we should create a new issue for QScreenSaver and track these feature needs, there? Only suggesting so important things for it, get tracked there.

[unman]

On Fri, Apr 02, 2021 at 12:51:00PM -0700, cfcs wrote: > On Mon, Mar 29, 2021 at 04:04:03AM -0700, Marek Marczykowski-G??recki wrote: In short: it isn't really about language switch, but about keyboard layout switch. > Or display of current keyboard layout Most users will not know what to do with that information if the keyboard layout is not the one they expect (ie the one printed on the keyboard).

I'm trying (and failing ) to find a case where a user has triggered a screensaver (of any sort) on a keyboard which does not match the language they are using **without** already being able to switch layout. Can you help me understand how that happens?

[cfcs]

@unman: So I've had to help Qubes users who were unable to unlock the screen where the solution was to type their password with us layout. I'm not sure how they ended up in that situation - if they pressed some magic combination to change the dom0 layout, or if they've perhaps just assigned local layouts to all their appvms and not noticed that dom0 was not using the local one (or didn't expect it). All I can tell you is that it's a real problem for some people, and it's not obvious that they suddenly need to type - to get a / instead of shift + 7, so even if they can see that us keyboard is used, it won't help them get back to work.

@na-- If you need a quick introduction to how typing works, regardless of keyboard layout, I'll help you: You press the buttons in front of you and text appears. It's definitely not for everybody, but it just might help make you come across less imbecile.

[unman]

On Sat, Apr 03, 2021 at 07:03:09AM -0700, cfcs wrote: @unman: So I've had to help Qubes users who were unable to unlock the screen where the solution was to type their password with `us` layout. I'm not sure how they ended up in that situation - if they pressed some magic combination to change the dom0 layout, or if they've perhaps just assigned local layouts to all their appvms and not noticed that dom0 was not using the local one (or didn't expect it). All I can tell you is that it's a real problem for some people, and it's not obvious that they suddenly need to type `-` to get a `/` instead of `shift + 7`, so even if they can see that `us` keyboard is used, it won't help them get back to work.

I'm still struggling to understand how they *got* to that state - how did they log in in the first place? It doesnt look like a screensaver problem to me.

@na-- If you need a quick introduction to how typing works, regardless of keyboard layout, I'll help you: You press the buttons in front of you and text appears. It's definitely not for everybody, but it just might help make you come across less imbecile.

I dont know who this comment is aimed at, but it's out of place here.

[Edan-Redmind]

@cfcs very easy. you start working, write an email in a non-englisg layout, then answer the phone and when you're done the screensaver is on and you need to unlock. now, was your last text was the email body (in a non-english layout) or was it the email address in english...? ;) just an example that happens to me.

________________________________ From: unman ***@***.***> Sent: Saturday, April 3, 2021 5:18:53 PM To: QubesOS/qubes-issues ***@***.***> Cc: Edan Igali - Redmind ***@***.***>; Mention ***@***.***>

Subject: Re: [QubesOS/qubes-issues] Change default screen locker from XScreenSaver (#1917) On Sat, Apr 03, 2021 at 07:03:09AM -0700, cfcs wrote: @unman: So I've had to help Qubes users who were unable to unlock the screen where the solution was to type their password with `us` layout. I'm not sure how they ended up in that situation - if they pressed some magic combination to change the dom0 layout, or if they've perhaps just assigned local layouts to all their appvms and not noticed that dom0 was not using the local one (or didn't expect it). All I can tell you is that it's a real problem for some people, and it's not obvious that they suddenly need to type `-` to get a `/` instead of `shift + 7`, so even if they can see that `us` keyboard is used, it won't help them get back to work.

I'm still struggling to understand how they *got* to that state - how did they log in in the first place? It doesnt look like a screensaver problem to me.

@na-- If you need a quick introduction to how typing works, regardless of keyboard layout, I'll help you: You press the buttons in front of you and text appears. It's definitely not for everybody, but it just might help make you come across less imbecile.

I dont know who this comment is aimed at, but it's out of place here. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#1917 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AM2W3KW4YU2LWOQBDA3SO4LTG4PU3ANCNFSM4CBGN27Q>.

[na--]

@na-- If you need a quick introduction to how typing works, regardless of keyboard layout, I'll help you: You press the buttons in front of you and text appears. It's definitely not for everybody, but it just might help make you come across less imbecile.

@cfcs, I was about to comment on your previous remarks earlier today, but deleted my reply just before posting it and left a simple 👎 instead, since I decided to give you the benefit of the doubt that you're not a condescending asshole. Sorry, my mistake... 🤷‍♂️

@unman, usually I get to the "unknown keyboard layout in XScreensaver" state exactly how @Edan-Redmind described. Not by locking my screen explicitly, but by the screen locker engaging automatically after some time has passed without any input. I guess one "solution" would be to edit xflock4 to always reset my keyboard layout to us before it actually locks the screen... 😅

[DemiMarie]

#2026 has been fixed, lowering priority and re-moving the “privacy” label.

Fixing this (and #3898) requires one of three changes:

1. Switch from X11 to Wayland (having the GUI daemon use XWayland is fine).
2. Use a nested X11 session (yuck).
3. Patching the X server so that if the screenlocker exits, the X server dies with it.

1 and 2 both have nasty problems (no tray icons support for 1, not sure how to even set up 2). @marmarek has stated that 3 is out as well unless I have missed something.

[DemiMarie]

This is fixed-by-wayland because Wayland actually provides decent ways to implement screenlockers, such that if the screenlocker crashes then either the session is terminated or a new screenlocker is respawned.