1. 14
  1.  

  2. 23

    What does this have over Xscreesaver, which has already been designed for security? And have they taken into consideration everything that XScreensaver has? Rewrites of XScreensaver have repeatedly managed to include flaws that jwz wrote extensively about guarding against in the included documentation. In one case he wrote about a strawman example, and it later was realized in GNOME’s screenlocker!

    jwz has blogged about these problems for almost twenty years, now.

    2003: https://www.jwz.org/blog/2003/02/the-cadt-model/

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

    2005: https://www.jwz.org/xscreensaver/man1.html#8

    2011: https://www.jwz.org/blog/2011/10/has-gnome-3-decided-that-people-shouldnt-want-screen-savers/

    2014: https://www.jwz.org/blog/2014/04/the-awful-thing-about-getting-it-right-the-first-time-is-that-nobody-realizes-how-hard-it-was/

    2015: https://www.jwz.org/blog/2015/04/i-told-you-so-again/

    If you don’t want to bother to following those links:

    I wrote this document in 2004, explaining the approach to privilege separation that xscreensaver has taken since 1991. Of course, the people doing needless rewrites of xscreensaver have ignored it for that whole time, and have then gone on to introduce exactly the bug that I described in this document as a hypothetical strawman! And – this would be hilarious if it weren’t so sad – have introduced it multiple times. As I said in 2015:

    If you are not running xscreensaver on Linux, then it is safe to assume that your screen does not lock. Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy.

    There’s little that I can do to make the screen locker secure so long as the kernel and X11 developers are actively working against security. The strength of the lock on your front door doesn’t matter much so long as someone else in the house insists on leaving a key under the welcome mat.

    1. 4

      Feature-wise, xsecurelock is surely less impressive than xscreensaver. However, in terms of it actually working, I’ve had far more success.

      At $job, we have many RHEL-based workstations. Whenever users would choose any of the fancy animations with xscreensaver, they would occasionally return to their desk to find the screen totally unlocked. My hunch was that the fancy graphics had a bug causing xscreensaver to crash - we made a policy to only allow the “blank” screensaver and this issue went away.

      The next issue was that, depending on their desktop environment and notification daemon used, occasionally people’s notifications would pop-up OVER xscreensaver’s lock screen. Not exactly best case scenario to have a calendar/email notification for “Friday, 3pm: Fire John Doe” to pop up while you’re in a meeting.

      We rolled out xsecurelock and no longer have either of these issues. JWZ is extremely talented, but his hubris leaves many to believe his software is bug free. The X11 protocol is broken and does not give any real provisions for a screenlocker. Most of the current implementations are basically hacks - sadly this is just the state of the Linux desktop today it seems.

      I will note that GNOME’s screen locker now integrates with GDM - rather than just showing a full screen window with a PAM login box in your existing session - so it’s probably better now. Of course the downside is you can’t really swap it out for a custom screen lock application.

      For a truly secure screenlocker your best bet is probably physlock, though it’s not the best UX for non-technical users.