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.
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.
Maybe using Xdummy instead of Xvfb would work better?
This wiki article makes such an approach look promising: https://xpra.org/trac/wiki/Xdummy
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.)
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.
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.
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?
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)
Its not an X11 problem.
(using bit.ly because he gives a testicle if referrer is HN :P)
> 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.
- 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!
I wonder why someone would setup a "bad result" for specific referrers ...
Just tested in Chrome and it works there as well.
https://brave.com/privacy-updates-5/
edit: see also: https://www.cookiestatus.com/brave/#referrer
Can't count on everyone having referrer turned off
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
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.
It seems like this whole class of bugs could be fixed pretty easily by having a simple process watchdog run xscreensaver as a child process, and re-launch it if it crashes without first signalling that the desktop has been unlocked.
> The screen locker is broken and unlocking is not possible anymore. In order to unlock, switch to a virtual terminal (e.g. Ctrl+Alt+F2), log in and execute the command: "loginctl unlock session c2". Afterwards switch back to the running session.
I think it's a reasonable design.
All screens lock together etc.
Besides screenlockers, having 2 screens with diffrent resolutions is way worse in KDE than in GNOME. (On X11)
From the point of view of the display manager, a screensaver/screenlocker crashing is just a simple app crash. There's nothing in the protocol to suggest that this is a security failure.
I'm imagining 2 processes:
1. Process monitor shows a fullscreen black window. Launches xscreensaver --lock or something as a child process
2. Xscreensaver shows the lock screen over the top of the process monitor, with a password prompt
When the correct password is entered, xscreensaver signals to its parent process. Then both processes close gracefully.
If xscreensaver crashes without signalling, the process manager silently restarts xscreensaver.
None of that requires any changes to X. You'd just want to be sure xscreensaver is displayed on top of the process manager's black window.
Argh. That would be the window manager, of course.
There is also xsecurelock [1] by Google.
Might be better to just exit the session or load a minimalistic replacement lock program (like the original xscreensaver) to avoid an infinite crash loop.
Also this bug (and probably most other bugs xscreensaver has had over the years) wouldn't result in an infinite crash loop anyway.
Edit: For me stuff
I have been recommending fedora to people for a while because their defaults are far more modern and sane rather than clinging on to python 2 and X11
> python 2
In contrast to Wayland that can be installed in parallel to python 3. So the only reason to remove it is if you enjoy breaking working software.
Also:
> In contrast to Wayland
I don't think Wayland is what you think it is.
To be fair to swaylock, they actually fixed some of those issues, in contrast to kscreenlocker which are just ignoring most edge-case bugs, because it's nearly impossible to fix them.
And really if you're being DDoSed by a small thing like HN comment links you really have to up your game :) Wait till you get featured on reddit (previously called slashdotting when slashdot was still a big thing).
Nor should he, not least because the redirect reliably results in ~90% of comments in any thread where jwz is mentioned being about the testicle in the eggcup rather than anything substantial.
PS: I have no idea what he means by "finance-obsessed"? I think the community at HN is tech-obsessed which is what I like about it. But finance? This is not yahoo finance or wherever all the finance guys hang out.
It sounds more like he had a clash with someone specific on a finance-related issue and bases his view of the HN community on that. The eggcup is a bit of an immature way to deal with this IMO. Especially as he has good points to make about X11 security, and this undermines them.
I like this site a lot, but I have a lot of patience when it comes to deciphering what is being affected by the Software Hub City Reality Distortion Bubble. Some people don't, hence the eggcup testicle, and people that think something like that undermines the technical argument aren't thinking clearly enough to even debate the technical point with anyway.
I don't know what prompted the redirect; it predates my awareness of Hacker News. I could guess, but why bother? The man has a nightclub to run, and I'm sure that's plenty all by itself to fill his days.
How do I get the testicle in an egg cup?
Otherwise, this is the image that gets displayed:
NSFW. This is a testicle in an egg cup.
An interesting website and blog, I like it! I wonder what their problem with HN is, although I don't mind being a testicle!
The thread was linked below (or above, to this same parent), or see: https://web.archive.org/web/20210116101222/https://www.jwz.o...
When I open it again, the desktop is accessible for a few seconds (sometimes long enough to launch programs) before the lock screen activates and I have to input my password. The workaround I use is to manually lock with Win+L before closing the lid.
I don't think I could interact with the screen in any way, but I could certainly take a picture of it, if I had any private information on the screen.
It will go to sleep, then when I wake it up, I get a flash of my desktop before the lock screen shows..
Too fast to write anything down by hand, but you could certainly point a 60fps camera at it and get something I'm sure.
* Do you use a nvidia GPU * Do you need to screen share from electron or other x11 only applications (MS teams, etc)
Its ready if you said no to both of those.
Log in, open firefox. Minimize the window, and the entire machine freezes. This is on an AMD GPU as well.
Every time I try Wayland, whether it be sway on my laptop or plasma on my desktop, I run into snags that did not exist in X. So back to X I go.
I'll switch to Wayland when it's ready "for real, actually, promise", and not a moment before. Maybe when Debian Stable switches to it by default.
Doesn't XWayland solve this?
Firefox supports Pipewire, Chrome has it behind experimental flag. Electron apps like Skype or Teams? Forget it.
I wasn't too concerned about it since it still blocked all user input, but if you had sensitive info visible it could definitely be an issue.
My guess is that these lock screens are all bolted on afterwards rather than being in the design from the ground up.
Really? I have never seen this in Windows. Don't get me wrong, I've seen plenty of lock screen failures in Windows, usually in the form of it suddenly being unresponsive, just never anything that actually gave me access to the locked session again.
The closest I've seen is when using RDP, if the Window has been minimized or hidden or otherwise has had reason not to update its display, then locked due to timeout, it will briefly show the last image it rendered when reactivated before updating and showing the lock screen.
P.S.: As other users have pointed out, Windows does have some known lock screen bypasses using accessibility and help dialogs, but in regards to merely crashing the lock screen, I haven't seen it behave in an insecure way.