
X11 screen locking: a secure and modular approach - luu
http://leahneukirchen.org/blog/archive/2020/01/x11-screen-locking-a-secure-and-modular-approach.html
======
kstenerud
My experiences with screen locking on Linux over time, using various machines:

* The screen doesn't lock, and remains on while the lid is closed.

* The screen doesn't lock, but does turn off when the lid is closed.

* The screen locks, but the machine doesn't suspend when the lid is closed.

* The screen doesn't turn on after the lid is opened. Key commands work, though.

* The screen turns on after the lid is opened, but is blank (no unlock requestor).

* The machine doesn't resume from suspend, requiring a hard reset.

* The screen locker gets completely bypassed and you're dumped into the desktop (possibly a fresh desktop because the entire environment crashed and restarted).

Throw remote desktop into the mix and you're in for a world of hurt.

I just disable screen locking, and make suspend a manual operation to keep my
sanity intact. The trackpad still stops responding sometimes though...

~~~
hpaavola
Interesting. The only issue I've encountered regarding screen locking was that
in the past the desktop would be visible for a split second after opening the
laptop lid and before the screenlock is displayed. Haven't seen that behaviour
in couple years, I think. I use latest Ubuntu at home and latest Ubuntu LTS at
work. Typically Lenovo and HP laptops, some Asus Zenbooks also in the past.

~~~
wlll
Interestingly this has _started_ happening on my mac, as of a few years ago.
Obviously unrelated to Linux.

~~~
AnIdiotOnTheNet
Is it really unrelated? I dunno, maybe my distaste for certain development
styles is leading me to see things that aren't there, but I fell like the
Linux Desktop hacked-together "it's good enough for me" way of doing things is
creeping into paid OSs like Mac and Windows.

~~~
bitwize
"The desktop" is suffering from the same complexity breakdown that AAA gaming
suffers from. It's hard -- and getting harder -- to produce a cohesive
properly developed and QA'd AAA game because gamers now expect something way
beyond the capabilities of a surgical team of 10-50 people. To even ship a AAA
title requires a team of hundreds and a budget of tens to hundreds of
millions. and when you're dealing with an wndeavor that large, it's difficult
to enforce quality and cohesiveness at every level throughout the development
process.

Desktop environments are now reaching that threshold because users demand
"modernity" and fanciness. They would be fantastically served by a desktop
with the capabilities of Windows 9x, MacOS 7.x, or AmigaOS 3.x, but they
demand much more than that, and the Windows and MacOS teams (and code bases!)
have bloated in size to meet this demand.

These problems showed up much earlier in Linux because in order to release a
desktop OS, you need someone exercising strict control over all aspects of the
system from the kernel (and even lower than the kernel, like the hardware and
firmware) all the way up to the shell, GUI toolkit, and other user-visible
features. You need that leadership to define and prioritize work and even
prioritize OS concerns. (For example, a desktop OS should handle
keyboard/mouse interrupts IMMEDIATELY.) You need to enforce a _single_ set of
user concerns on everybody, and fire anyone who doesn't play ball. And with
Linux and open source, good luck getting everybody on the independent kernel,
libc, X, and GUI projects to cooperate this way.

Me, I've always been content with like fvwm95 (or lately, i3) and whatever
independent programs I needed for desktop tasks. And if I have to say 'pm-
suspend' at a command prompt to put my computer tk sleep, so be it. I can see
the many hands all making the world a slightly better place, and since their
work is all loosely coupled, it all sort of hangs together and is very robust.
Conventional desktops are brittle to start with, and made even more so under
Linux because of those issues I mentioned.

~~~
AnIdiotOnTheNet
> Desktop environments are now reaching that threshold because users demand
> "modernity" and fanciness.

Do they? Do they really? Because I struggle to think of a change made in how I
or anyone I know's desktop works that we actually think made things better.
The last one I can think of was when Windows added start-typing-search to the
start menu back in, what, 7?

I'm not dismissing that other people might be demanding some "modern"/"fancy"
features, but if so what the heck are they? What I see is GUI redesign for the
sake of it, or hiding of options in order to promote more "desired" (by the
vendor) options.

------
cycloptic
These are good suggestions, but it seems that xsecurelock still can't provide
a workaround for the bug where the screen doesn't lock if a popup menu happens
to be open or the pointer is grabbed in any other way [0]. I couldn't find any
good way to fix this and the only suggested workaround seems to be to switch
to Wayland. I've switched on all of my machines (for this and for other
reasons) but please make sure you know the details of this if you still use
Xorg.

[0] [https://github.com/google/xsecurelock#known-security-
issues](https://github.com/google/xsecurelock#known-security-issues)

~~~
Jasper_
There is no way to fix it. Also, X11 has several ways of writing keyloggers to
get around input locks. I've written one here
[https://github.com/magcius/keylog](https://github.com/magcius/keylog)

------
anaphor
It's worth reading this article as well, "Why screen lockers on X11 cannot be
secure". I'm not sure how xsecurelock bypasses all of these issues.

[https://blog.martin-graesslin.com/blog/2015/01/why-screen-
lo...](https://blog.martin-graesslin.com/blog/2015/01/why-screen-lockers-
on-x11-cannot-be-secure/)

~~~
asveikau
This mentions writing the screen lock UI in QT. jwz, maintainer of
xscreensaver, had a rant about why he avoids the use of a big toolkit. The
short version is he wants minimal code size because the consequence of a crash
is to unlock the screen. The rant was prompted because of a real life gtk+ bug
which made another screen locker crash.

I would find a link and include it but jwz is hostile to links with HN as a
referrer.

~~~
cycloptic
The author mentions what they did to mitigate this in the previous post in the
series, see the part about XScreenSaver: [https://blog.martin-
graesslin.com/blog/2014/05/screenlocker-...](https://blog.martin-
graesslin.com/blog/2014/05/screenlocker-architecture-in-plasma-next/)

~~~
asveikau
> the screen content can be exposed. Consider for example the linked
> screenshot.

That's funny, because the effect there is obviously intended, because, uh, it
looks cool.

> For a screen saver of the last millennium this was a suitable solution

It's true that this particular effect was much more impressive in the 90s.
Personally I use the 'blank' demo in xscreenaver. Which I guess I could
replace with the script in TFA without noticing much.

> Today users also expect the current time, battery state and many more
> information on the lock screen. We need to provide accessibility features
> which is not possible in XScreenSaver.

I don't see why this is not possible with Xlib. Yes I have written Xlib code.
Seems to be just an "omg xlib is so old" argument, and things being old does
not by itself make them incorrect.

> We need DBus integration

> and logind integration

Says who? I certainly don't need these.

~~~
cycloptic
I don't have any opinion on those. Regardless of how you or I feel about any
extra features, the author does seem to have an answer to the security
concern.

------
hendry
I'm getting by mostly by `xss-lock -- /usr/bin/slock`
[https://github.com/kaihendry/dotfiles/blob/master/.xinitrc#L...](https://github.com/kaihendry/dotfiles/blob/master/.xinitrc#L66)

But yeah, one of those things that's surprisingly tricky to get right.

~~~
rdslw
That's what I'm also recommending and working more/less reliably in terms of
locking.

One thing which I'm also analysing recently is electron shit^H^H^Happs,
triggering XSS (X screen saver) idle detection on some internal app events
(not user actions!).

Being: if you dont move mouse, nor touch keyboard, plus you're receiving slack
messages, XSS considers youre NOT idle, in result not allowing lock to work if
relying on xss-idle-detection.

needing it as I'm expermineting with some cool X11 software from 199x. I added
XSS support, as original detection engine(*) dont work reliably on modern X11.

Anyone?

------
ubercow13
I prefer
[https://github.com/muennich/physlock](https://github.com/muennich/physlock)

It seems more secure as it bypasses X, and you can be sure (can you? I just
assume this, I don't really know) your input is not even being passed to X
when your screen is locked. In practice I've found it very reliable.

~~~
eximius
never been able to get it to work. I've been using i3lock on my machines, not
sure how well it does on suspend, though.

~~~
secure
I recommend to combine i3lock with xss-lock to get automatic screen locking on
suspend:

xss-lock --transfer-sleep-lock -- i3lock --nofork

------
tomcooks
suckless' sloc works great and it's very customizable

[https://tools.suckless.org/slock/](https://tools.suckless.org/slock/)

~~~
klibertp
> it's very customizable

Yeah, lots of features and options in this one. Worth a look! ;)

I rewrote it in Nim some time ago to see how it works, and it was a good
lesson in X11 and POSIX APIs. Short and to the point.

------
quotemstr
I don't understand why we don't just lock screens by switching to a different
virtual terminal running a different X server. If the lock screen doesn't
share an X server with the user session, a lot less information can leak. This
entirely-separate-session approach is what Windows uses, and it works great
there.

~~~
JdeBP
It's a separate desktop, but _not_ a separate window-station, let alone a
separate _session_. The clipboard and atom table are not separate, because
they belong to the window station; and a session is something rather different
on Windows NT.

* [http://jdebp.uk./FGA/windows-nt-session.html](http://jdebp.uk./FGA/windows-nt-session.html)

~~~
quotemstr
Ah, right. I remembered incorrectly. My larger question stands though.

------
haecceity
Linux kernel needs to support something like a secure attention sequence.

------
anthk
openbsd, apmd, xidle, slock (base has xlock, but slock is much smaller (no
fX), thus, maybe more reliable.

