[Grml-devel] Shared screen locking solution for live distributions in Debian

Klaus Knopper knopper at knopper.net
Tue Jan 13 00:58:30 CET 2015


Hello Sajolida,

On Wed, Dec 31, 2014 at 02:03:15PM +0000, sajolida wrote:
> Hi,
> 
> I'm part of the people working on Tails, a live distribution that aims
> at preserving privacy and anonymity: https://tails.boum.org/. Tails is
> currently lacking a screen locker and this has been a frequent feature
> request. See https://labs.riseup.net/code/issues/5684.
> 
> For example, as Tails is been adopted more and more by journalists,
> they want to be able to leave their computer unattended in their
> office to go to the toilets for a minute and have their screen locked.
> 
> I'm writing this emails to various Live distributions based on Debian
> (Knoppix, Grml, Jondo, Kali, Debian Live, and Tanglu). I'm also
> putting Micah Lee in copy as he has shown particular interest in this
> feature.
> 
> I've been investigating the screen locking mechanism of those various
> Debian based live distributions, and I found out that none of them had
> a real mechanism to do so. They either:
> 
>   - Do not provide any screen locking mechanism (Knoppix, Grml,
>     Jondo Live).

Actually, Knoppix disables/circumvents the standard Debian screen
locking mechanism because there is no unlocking possible once the
screenlock is active. All passwords are invalid and locked.

>   - Either rely on their default password to unlock the screen (Kali,
>     Tanglu, Debian Live).
> 
> The purpose of this email is to know whether you would be interested
> in working on a common Debian package to provide a generic screen
> locking solution for Debian based live distributions.
> 
> The core usability issue that we are facing here is the one of the
> unlocking password. As we are live distributions, there either is no
> password or a default one.

"no password" in the sense of "there is no valid authentication
password", i.e. no backdoor. Sometimes, people mean "ANY password" if
they say "no password", which is not the case for Knoppix. Again, all
passwords are invalid and locked.

> Still, screen locking only make sense if
> the user is able to use a custom password.

Also, screen locking makes only sense if there is the apparent
possibility that someone else has physical access to the computer while
the user is not paying attention. Why would I lock the screen if I'm the
only one using the computer in a safe environment, and shut it down and
remove the live medium when I'm done with my work.

> As an interesting exception,
> note that in Jondo Live, the user is prompted for a user password on
> boot.

Knoppix design is not to ask anything from the boot screen till the
running graphical desktop, with the possible exception of an encrypted
personal overlay.

> In Tails the user can set up an administration password but this
> is disabled by default for security reasons so we cannot rely on this
> for screen locking.
> 
> During our last monthly meeting we came up with the idea of asking for
> a custom password *in the process of locking the screen* for the first
> time.

So, when is the right time to lock the screen? Debian does this by
default when the computer goes to standby or the notebook lid is closed.
In this case, the user will hardly pay attention to a dialog asking for
a password.

> For example, in GNOME, when doing Meta+L for the first time, the
> user would be prompted to enter a screen locking password, then only
> the screen would get locked. If she locks the screen again, the same
> password would be reused.

A "voluntary screenlock button", asking for a new screenlock (not
necessarily a login) password could be worth a try.

Regards
-Klaus


More information about the Grml-devel mailing list