[LightDM] security of dm-tool lock

[Yves-Alexis Perez]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Thu, Jan 30, 2014 at 09:39:52AM +1300, Robert Ancell wrote:
> Hi Yves-Alexis,

Hi, thanks for the reply!
> 
> On 29 January 2014 23:07, Yves-Alexis Perez <corsac at debian.org> wrote:
> > - - 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).

Ok.

> > - - 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.

ConsoleKit/logind gets the information from dbus message sent by
lightdm, I guess?
> 
> *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.

Ok.

> > 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.

Yeah, that's not really something generic we can handle at the Debian
level, I think.

> > 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.

Here, I'm not really talking about myself personally (I use
light-locker, lightdm and lightdm-gtk-greeter and it seems to work just
fine. I'm more interested in providing Debian users (especially Debian
Xfce users, but not only) a nice and secure solution.

Right now, locking is usually done in Xfce by calling xflock4 (for
example with a ctrl-alt-suppr or because xfce4-power-manager started it)
or because xscreensaver (or another “standard” screensaver) timeout
kicked in.

> 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.

I want to (reasonably) support whatever case the end user will want, if
possible without breaking standard behavior (exposed above). I'm not
against behavior changes, but I can't really force too much stuff onto
the user.

> > 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.


Then I guess dm-tool lock is really not something we can include in
locking setups right now.

I'm really puzzled at the whole freedesktop.org stack in that matters,
there's a lot of interactions between various components, which are
actually not interchangeable and won't even support properly if one
other component is missing.

Thanks for the clarification anyway.

Regards,
- -- 
Yves-Alexis Perez
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBCgAGBQJS6W3+AAoJEG3bU/KmdcClLE8H/0rT7G3dzb9UOkl0PMM5r3Zg
IiD9iK6SeTMuvG2bXmqFjFZxlpNplwd+KhQgQLBzLEq78OtNW2JcoOP0gwOusoMH
N8pu6ABIM4inLZhByHDRWXUeTP7+oR0s9XhlmFmfU4wXWNLxfdCpQjzD41LMS2NZ
pYLGc147vrORFqYGIxy/2REwqvg6zOqnJK8E2qe58nSAENei7jb5kq2FQEMuocJe
MyEMchTn/wp22JcHBO7F1rFW0avqulO3pUQ5RUqY7C64pznE0/qiV6Mh/XgJE1nk
bHII8rwAYyMOBUoAP8jKK26gAC1/GXezCgCjWXks44C4+tMAlgJ7gB/gQg/9fCM=
=Aiqd
-----END PGP SIGNATURE-----