It's not an X11 design flaw. The very concept of locking the screen is flawed. A flaw that also haunts Wayland, BTW.

The concept of screen lockers is having a special layer, that can't be bypassed, which a locker creates. The whole security then hinges on the locker not crashing. X11 does have such a layer. Wayland compositors also implement it through such a layer. And for either the situation is, that if the locker crashes, that layer is destroyed by implication and the session exposed.

That's a flawed concept.

What you really want is detachable graphics session. On the text console one can effortlessly use screen or tmux and to "lock" the session simply detach and exit to the regular login getty.

You want exactly the same, but for X11. And there's no obstacle in printiple to implement this. It's just that the Xorg server can't detach. Almost all of the required code is there, fundamentally it'd be the same code that's executed during a VT switch.

In the meantime one can use Xpra with Xvfb to create detachable X11 sessions, which then however lack GPU acceleration.

The architecture you're describing would also be good for other reasons. For example, you could start a local session, lock it, and then remotely connect to the same session over VNC without local users at the workstation being able to see or interfere with what you are doing, just as on Windows.

Mac OS almost gets this right, except it annoyingly defaults to sharing the remote session with the local console unless someone is already logged in locally.

It’s amazing to me that The most popular display managers on Linux have this flaw. Perhaps there is a workaround involving switching to another tty?

that's a really good point! your comment reminded me that that is what we used to do in the lab at university, a long time ago. switching to a different terminal, then locking that, was much more fool proof. perhaps not for security, but rather because X11 was so damned buggy and crashy, that you might need to have access to that terminal to get back into your workstation without forcing a reboot.

Perhaps outside of display servers altogether, implementing an authentication system that keeps track of what user currently owns what v.t., and allowing only that user, or root, to switch to that v.t..

I'm curious what other OS which avoid X11/Wayland do, such as Android. Do they implement an architecture like what you mention?

Windows has a secure desktop that host lock screen. Crash that gives you a bsod or at worst a blank screen (your window did not host on it, whta did you expect?)

> In the meantime one can use Xpra with Xvfb to create detachable X11 sessions, which then however lack GPU acceleration.

Maybe using Xdummy instead of Xvfb would work better?

This wiki article makes such an approach look promising: https://xpra.org/trac/wiki/Xdummy

I agree with your explanation but I would still call that a method of "locking the screen".

X11 design flaws you say?

https://github.com/swaywm/swaylock/issues/162 https://github.com/swaywm/swaylock/issues/158 https://github.com/swaywm/swaylock/issues/10

I’m not familiar with the details of the design flaw and whether or not Wayland fixes it, but those links don’t contradict this being an X-specific design flaw. I get the impression that swaylock is a direct port of i3lock, and thus stands a fair chance of being written and architected in an X style, rather than taking advantage of any superior form that Wayland may support but X didn’t.

Expressed otherwise: just because someone’s written one piece of bad software for Wayland doesn’t mean Wayland doesn’t allow you to write good software. (Whereas I get the impression from what I’m reading that X makes it impossible to write a good screen locker, if by that you require that it be crash-proof and use the usual platform toolkit for the UI.)

(Remember in this that I’m saying I don’t know. I’d like to hear if Wayland does have a good answer to this, or from anyone with definite knowledge that it doesn’t.)

I think they're simply saying that lock screens are hard to get right and that shitting on x11 at every chance you get doesn't help anything.

If you've ever looked in the bugtracker of a big X11 screenlocker, you would love to have this small amount of bugs. In fact, some of the bugs you posted are alread solved and I can't find one bug related to displaying. Giving the display to the user could also lie in other code parts. We'll see how this ends, but it's already a huge gain that not every Everyday Linux user has experienced such things by themselves.

The underlying design issues are:

a) there's no Xserver concept of a lock screen which would be hard to fix, I suspect. How would you signal X to lock/unlock; what would it do if the lock client wasn't connected, etc.

b) there's no atomic way to transfer mouse/keyboard grab to another window, which means you can't have a reliable, crash reduced screen locker that supervises a beautiful password checking program; it has to be the same program. This could probably be fixed with an X extension; yes, an extension is a lot of work, and yes, you'd have to deal with fragmentation, but you could keep the untoolkited password dialog in case the extension isn't present, nobody would see it unless they did something odd, so it's fine.

Another issue is that I think I've seen some linux systems don't launch the screen locker until resume, instead of locking before suspend; that's not ideal, because the screen locker will take time to launch and lock the screen (more so if it's got a fancy initialization routine and is a large binary/many libraries to load).

An option could be running a dedicated screen lock Xserver on a different VT, and (securely) switching to that one somehow. But that would probably involve changes to multiple layers at the same time, which is hard to pull off in Linux. People would complain about the bloat of running a second Xserver, regardless of the actual bloat or imcreased utility.

> Another issue is that I think I've seen some linux systems don't launch the screen locker until resume, instead of locking before suspend; that's not ideal, because the screen locker will take time to launch and lock the screen (more so if it's got a fancy initialization routine and is a large binary/many libraries to load).

This particular issue is fixed in logind, when you ask it to lock the season/suspend/hibernate it first calls the lock screen, wait it to signal it finishes and them it proceed to suspend/hibernate.

Not saying you need systemd to fix this issue, but it is one of the things that systemd allows you to do correctly without reinventing the wheel.

> and yes, you'd have to deal with fragmentation,

Why not just require that it is there? Is there even a valid reason for someone to keep the extension out unless it is to give another "this is the reason X sucks" speech?

Because, IIRC, xscreensaver is launched on demand (idle timer, power management), and that's a terrible time to detect the extension and tell a user that they won't be able to resume their session, because their Xserver is too old.

Also, because of piecemeal releases, and remote X. You might update Xscreensaver, but not your X server or desktop environment. You might have a dedicated X terminal which can't easily have its server component updated, but you run remote sessions that have an updated Xscreensaver. (Btw, if you do this, you're pretty dedicated in 2021)

What is todays alternative to remote sessions?

Most of what I've seen has migrated towards a virtual display on the session server, streamed via vnc/rdp/? to a thin client.

I like the dedicated VT, as DE users usually have a DM to login and for wayland that prob must a separate VT any way. The question is how to securely do this.

JWZ has been complaining about these screensavers for a decade. His screensaver from 20 years ago still doesn't have these issues.

Its not an X11 problem.

- https://bit.ly/3o2qekz

- https://bit.ly/38Y6pGO

(using bit.ly because he gives a testicle if referrer is HN :P)

In fact jwz himself says in that very post that it is a fundamental problem with X11:

> X11 ... was designed with no security to speak of, and so lockers have to run as normal, unprivileged, user-level applications. ... This mistake of the X11 architecture can never, ever be fixed.

He also claims in the second post that Xscreensaver is actually vulnerable to exactly the same kind of attack:

> The xscreensaver daemon is a critical piece of security software. The reason for this is that, as a screen locker, any bug in the program that causes it to crash will cause the screen to unlock. As soon as xscreensaver is no longer running, the screen is no longer locked. Therefore, great care must be taken to ensure that the daemon never crash.

I don't understand the part about JWZ's testicles, so here are the links without bit.ly tracking for those whose ad blockers don't allow them:

- https://www.jwz.org/blog/2021/01/i-told-you-so-2021-edition/

- https://www.jwz.org/xscreensaver/toolkits.html

[Edit]: I understand now. My browser doesn't send referrer URLs, and I think that's the real fix instead of using something like bit.ly!

You still get the testicles if you click this link, at least using Chrome you do. It's because the referrer field is set to HN so they know where the traffic is coming from.

In Firefox set network.http.referer.XOriginPolicy and network.http.referer.XOriginTrimmingPolicy.

Source: https://wiki.mozilla.org/Security/Referrer

I'm using Chrome with uMatrix and uBlock Origin... I assume one of those blocks the data because, somehow strangely, I feel left out that all I'm getting is the websites.

I wonder why someone would setup a "bad result" for specific referrers ...

All good with Brave as far as I can tell. I don't know what everyone is talking about with testicles, but I don't see any with Brave.

In Firefox, right-click and open in a new private window and the links will work.

Just tested in Chrome and it works there as well.

In mobile Safari tap and hold, then tap the preview or the open button

Time to switch to Firefox and give Google less data. Firefox doesn't seem to send the referrer :)

Hmmm. I think somebody is following this thread because I got testies using ff on linux by clicking the bitly links above.

haha, same. jwz really wants us to see the testes!

Brave does not send the referrer as well.

Yes it does. I use brave and I get testicles if I click the link.

I've tested it multiple times, as have others. Perhaps you are running an ancient version?

https://brave.com/privacy-updates-5/

edit: see also: https://www.cookiestatus.com/brave/#referrer

Can confirm on android, Linux and windows

just tried it in chrome, i got only one testicle

Does anyone know how to make this right? Would simply removing the mate-screen-saver package work?

haha, yeah. I don't like using URL shorteners either there is just a balance to be made between them tracking you and getting redirected to testicles.

Can't count on everyone having referrer turned off

To others, you'll definitely still want to copy paste that URL into a new tab rather than clicking directly. :~)

Xscreensaver has crashed twice in my life and opened the desktop. That's still a good statistic but it may have crashed because of the animation.

Savers can crash without the screen unlocking. Are you sure it was xscreensaver you were running, and not one of the innumerable incompetent knockoffs?

I've also seen some xscreensaver crashes a while ago: https://news.ycombinator.com/item?id=21224179

Sounds like you were probably using gnome-screensaver or some of the many other poorly written alternatives like cinnamon that do this. I don't believe there is any way for xscreensaver to unlock the desktop even if it does crash

Incorrect. It’s a limitation of X11 that if the screensaver daemon crashes, including xscreensaver, the desktop will be unlocked. See the JWZ links that are posted in this thread.

xscreensaver has had some issues, for example: https://security-tracker.debian.org/tracker/CVE-2015-8025

Which can be found via this thread: https://news.ycombinator.com/item?id=11412081 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819703#400

I'm surprised he doesn't mention XSecureLock. Its entire focus is on preventing issues like this with modularity and redundancy.

https://github.com/google/xsecurelock

I fear it's as secure as vsftpd: Secure until a large amount of users use it and find bugs.

I do not understand. There's an xl and its PAM-checking derivative xl-more that just work.

They do nothing fancy - paint a window over everything and wait for the password to be typed in. No animation. No graphics. No anything. No enter unlock password dialog. I am sure there could be some edge cases but I'm having a hard time identifying them.