[LightDM] security of dm-tool lock

[Robert Ancell]

Hi Yves-Alexis,

On 29 January 2014 23:07, Yves-Alexis Perez <corsac at debian.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hi,
>
> I have a question about the dm-tool and especially the lock part. As I
> understand it, it's supposed to be used with a locker (like
> light-locker, but also stuff like gnome-screensaver and maybe a
> unity-sreensaver if that even exist).
>
> Correct me if I'm wrong, but the behavior is:
>
> - - someone calls dm-tool lock (is there a dbus way here?)
>

dm-tool look just calls Lock() on /org/freedesktop/DisplayManager/Seatn (as
got from $XDG_SEAT_PATH).


> - - lightdm reacts by switching vt and sends the dbus "lock" signal
>

lightdm launches a greeter, which causes a VT switch* and the existing
session to be locked via ConsoleKit / logind.

*when using traditional X and VT switching seats. When using Unity System
Compositor (Mir) it triggers the compositor to switch active session.


> - - the running locker receive the lock signal and locks the screen
>

Locker / screensaver / shell or whatever is listening on the ConsoleKit /
logind dbus interface.


>
> My concern is that calling dm-tool lock when no locker is running
> (wether because there's no locker installed, because it has crashed or
> not started or whatever) means that the system will be left on an
> insecure state (unlocked), but at the lightdm prompt, so an user might
> think it's correctly locked.
>

Correct - there's ultimately no way that LightDM can be sure the session is
locked since it just tells ConsoleKit/logind and it has no idea if that has
been successfully acted on. I don't know of a way around this in the
current architecture, but in Ubuntu we're working towards having a system
compositor that switches between sessions so it can enforce switching only
when allowed.


>
> It's pretty easy to reproduce on my Debian box, you just need to call
> dm-tool lock with no light-locker running.
>
> One solution would be to make sure noone ever calls dm-tool lock, but
> then I'm a bit puzzled at what's the exact usefullness of this tool. I
> hoped to add it to xflock4 (the Xfce lock wrapper), but it looks like a
> pretty bad idea right now (because of the above concern).
>

It's up to how you want to do screen locking. If your shell / session has
suitable lock screen support and you're happy with it then you probably
want to use that because you get tighter control.

If you want to simplify your lock screen and use the same GUI as the
greeter then use dm-tool/LightDM to do the locking. Using LightDM has the
advantage that a flaw in the greeter is unlikely to let you into a locked
session (the screen locker crashing will), but a crash in the screen locker
might leave the session unlocked and able to be gotten to using alt+ctrl+Fn
to VT switch.


>
> In the end, there's a need for a way to the caller (of dm-tool) to be
> sure that it doesn't leave the system in an insecure state. And it has
> to work in a heterogen system, too.


> I'm not sure how much feedback lightdm gets from the various calls, but
> maybe dm-tool could return an error if the locking failed, and switch
> back to the original vt?
>

It does handle the failure to launch a greeter but as stated it can't tell
if the session has actually locked itself.


> Does it need to send the lock signal *after* leaving the original vt,
> too?
>

The problem with sending the lock signal before switching is you might see
the lock for a split second before the switch occurs. And since we can
never know if / when the locking occurs you might as well send it after.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/lightdm/attachments/20140130/1062b7ba/attachment.html>