Change default screen locker to physlock

[mfc]

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.

[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.

[gutsle]

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/

[gutsle]

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.

[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?

[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).

[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

[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.

[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.

[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. :)

[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?

[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 ;)

[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.

[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?

[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]

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.

[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...

[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.

[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.

[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).

[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).

[ksoona]

Can I at least set a screensaver instead of just the black screen? I can't install xscreensaver-extras or anything.

[ksoona]

Can I at least set a screensaver instead of just the black screen? I can't install xscreensaver-extras or anything.

[cfcs]

@ksoona This thread is about making Qubes stop using an insecure screensaver, not about making the insecure screensaver prettier; you should probably file a new issue if that is what you want.

[cfcs]

@ksoona This thread is about making Qubes stop using an insecure screensaver, not about making the insecure screensaver prettier; you should probably file a new issue if that is what you want.

[h01ger]

FWIW, I just gave physlock a try and it worked great :) Is physlock available in fedora 25?

I also like its secure design, as opposed to other unsecure-by-design xscreenlockers... ;)

[h01ger]

FWIW, I just gave physlock a try and it worked great :) Is physlock available in fedora 25?

I also like its secure design, as opposed to other unsecure-by-design xscreenlockers... ;)

[TBK]

Apparently it is a hopeless cause on X11 - http://blog.martin-graesslin.com/blog/2015/01/why-screen-lockers-on-x11-cannot-be-secure/ the only way to solve it is to switch to Wayland (#3366).

I experienced this scenario for the first time a couple of days ago:
And yes that is the case: opening a context menu on any window prevents the screen locker from activating. - source: the link above

Luckily it happened at home and only gone for a short while.

Since then I have conducted several test on several machines and it is the same, context menu blocks the screensaver from activating.

[TBK]

Apparently it is a hopeless cause on X11 - http://blog.martin-graesslin.com/blog/2015/01/why-screen-lockers-on-x11-cannot-be-secure/ the only way to solve it is to switch to Wayland (#3366).

I experienced this scenario for the first time a couple of days ago:
And yes that is the case: opening a context menu on any window prevents the screen locker from activating. - source: the link above

Luckily it happened at home and only gone for a short while.

Since then I have conducted several test on several machines and it is the same, context menu blocks the screensaver from activating.

[cfcs]

@TBK I posted that link last year: #1917 (comment)

if you would care to read 10% the comments in the thread before replying you would have noticed that there is another way, physlock.

[cfcs]

@TBK I posted that link last year: #1917 (comment)

if you would care to read 10% the comments in the thread before replying you would have noticed that there is another way, physlock.

[TBK]

@cfcs My bad, should not have posted in the middle of the night.

[TBK]

@cfcs My bad, should not have posted in the middle of the night.

[cfcs]

@TBK No worries. You were completely right that it's hopeless on X11, and that this is a security flaw that is even documented in the FAQ of xscreensaver.

This three year old comment by @nvesely has a proposed fix to this security flaw in Qubes in case you want to secure your system (I don't think the Qubes upstream has made it clear by now that they don't consider screenlocking a security measure): #963 (comment)

[cfcs]

@TBK No worries. You were completely right that it's hopeless on X11, and that this is a security flaw that is even documented in the FAQ of xscreensaver.

This three year old comment by @nvesely has a proposed fix to this security flaw in Qubes in case you want to secure your system (I don't think the Qubes upstream has made it clear by now that they don't consider screenlocking a security measure): #963 (comment)

[TBK]

@cfcs Thanks, I will look into that.

Qubes OS is not the easiest project to to get a clear image of the state of things.

[TBK]

@cfcs Thanks, I will look into that.

Qubes OS is not the easiest project to to get a clear image of the state of things.

[nvesely]

I haven't used qubes in a while, but the services in this repo were working as of 3 years ago.

[nvesely]

I haven't used qubes in a while, but the services in this repo were working as of 3 years ago.

[dylangerdaly]

I'm hitting errors using physlock (muennich/physlock#44 (comment))

Issue looks to be related to PAM.

How are you guys using physlock? I want to stop relying on xscreensaver...

[dylangerdaly]

I'm hitting errors using physlock (muennich/physlock#44 (comment))

Issue looks to be related to PAM.

How are you guys using physlock? I want to stop relying on xscreensaver...

[dylangerdaly]

Rebuilding with SESSION=systemd and setting up the PAM module fixed it for me.

[dylangerdaly]

Rebuilding with SESSION=systemd and setting up the PAM module fixed it for me.

[Aekez]

It may not be feasible/desireable, but what are the prospects of using something like firejail on the various of different screensavers being considered, in order to minimize (make harder) bypassing with security exploits?

Firejail can sandbox any type of processes: servers, graphical applications, and even user login sessions.

• Quote source: https://firejail.wordpress.com/

Presumably, it could help increase the isolation layers within dom0 itself (or future stub-domain where lock-screen resides)?

[Aekez]

It may not be feasible/desireable, but what are the prospects of using something like firejail on the various of different screensavers being considered, in order to minimize (make harder) bypassing with security exploits?

Firejail can sandbox any type of processes: servers, graphical applications, and even user login sessions.

• Quote source: https://firejail.wordpress.com/

Presumably, it could help increase the isolation layers within dom0 itself (or future stub-domain where lock-screen resides)?

[cfcs]

@Aekez Using firejail on xscreensaver and the other X-based screensavers actually increases the likelihood that they will crash, meaning that it increases the attack surface for someone looking to bypass your lock screen. For physlock I don't think it would make much of a difference, but wouldn't hurt.

EDIT: What they mean by user login sessions in the highlighted part of the quote above is that it can sandbox a "user session," ie you can attempt to separate multiple processes running under the same PID (in Linux that is pretty hard to do effectively; if you allow those sessions to access X you largely lose the benefit of the sandboxing).

[cfcs]

@Aekez Using firejail on xscreensaver and the other X-based screensavers actually increases the likelihood that they will crash, meaning that it increases the attack surface for someone looking to bypass your lock screen. For physlock I don't think it would make much of a difference, but wouldn't hurt.

EDIT: What they mean by user login sessions in the highlighted part of the quote above is that it can sandbox a "user session," ie you can attempt to separate multiple processes running under the same PID (in Linux that is pretty hard to do effectively; if you allow those sessions to access X you largely lose the benefit of the sandboxing).

[Aekez]

@cfcs ah, that's unfortunate if it can make it even worse. Thanks for sharing the insight though.

[Aekez]

@cfcs ah, that's unfortunate if it can make it even worse. Thanks for sharing the insight though.