Security Audit Request for Screenlocker Branch

[Martin Gräßlin]

On Tuesday 11 October 2011 17:34:10 Oswald Buddenhagen wrote:
> On Tue, Oct 11, 2011 at 03:55:15PM +0200, Thomas Lübking wrote:
> > Am Tue, 11 Oct 2011 15:33:39 +0200 schrieb Torgny Nyblom <nyblom at kde.org>:
> > > Does this mean that I will be focred to use a screensaver with
> > > password unlock? If so why is that not a vaild usecase? It's what I
> > > use at home all the time.
> > 
> > So you want to do that again why?
> 
> "because it's pretty"?
> on a more serious note, now do you handle the lock grace time?
this is actually not affected by the changes. Dim Display and turning off the 
screen are decoupled from the screen locking.
> 
> On Tue, Oct 11, 2011 at 04:00:17PM +0200, Martin Gräßlin wrote:
> > yes if you have a terminal open and if it is the top most of stacking
> > order it is possible to start another window manager.
> 
> [in fact ... oh, scratch that, thomas already answered]
> 
> > I think there is hardly anyone here on the list who is as experienced
> > as I am with situations where you don't have a window manager running
> > ;-)
> 
> sorry, but that's an utter nonsense argument from a security pov. you
> are basically arguing for security by obscurity.
Yes, sorry that comment was not meant seriously.
> 
> > KWin has currently one reproducable crash listed in bko.
> 
> irrelevant. there will always be new crashes, also outside kwin's
> control.
irrelevant for all implementations - also the existing ones. If we want to be 
secure against crashes introduced by dependencies we have to write something 
which does not link anything except Xlib. Of course KWin is a more complex 
application than others, but given what we need in a screen locker the 
difference becomes marginal IMHO.
> 
> > I myself have never run into a situation where KWin did not restart
> > [...]
> 
> even if it restarts, you still have a non-trivial racing window.
> additionally, it probably allows a waiting app (some popup) to grab
> input and thus make the subsequent re-lock fail.
ok, this is a concern I have not yet considered. Any ideas how we could handle 
such a situation?
> 
> the correct architecture, as far as i'm concerned:
> 
> 1) ideal solution:
> - everything wayland
> - user switching and consequently desktop locking are handled by kdm,
>   which acts as the top-level wayland proxy server. the new process
>   structure within kdm is to be determined yet.
> - no kwin involvment at all. kwin effect plugins may be used for some
>   bling.
agree on this ideal solution which fails at point one
> 
> 2) suboptimal solution (kicks in when no wayland-enabled kdm runs):
> - the saver engine (which currently resides in krunner for historical
>   reasons) is made stand-alone
> - the lock engine is re-integrated into the saver engine, thus removing
>   the now obsolete process separation (it was only meant to isolate the
>   locker from kdesktop/krunner crashes)
> - if an X based compositing kwin is running:
>   - kwin is instructed to take the locker window and do something magic
>     with it. same for the unlock dialog, plasma, etc.
>   - the residence and implementation (qwidget, plasma, qml) of the
>     unlocker dialog is orthogonal to kwin integration and can thus stay
>     where it is; the general architecture of the plasma overlay can be
>     retained and extended as needed
>   - if kwin crashes, there is only a short unredirection flash
Having the locker outside of the compositor brings back the issues which I 
wanted to solve in the first place:
* windows can get on top of the screen locker
* screen is not correctly blanked
* how to tell KWin about a screen locker window in a secure way?
> - if a wayland based kwin is running:
>   - input handling is now a native task of the compositor, and a
>     crashing compositor takes the whole desktop down anyway, so it is
>     reasonable to fully integrate the locker into kwin
* that is one of the reasons why the lock screen work was started: having a 
solution for both X and Wayland
>   - but for the same reason it may make sense to extract the core
>     compositor from the bigger kwin
>   - whether code sharing with the X based solution happens via source
>     sharing and some #ifdefs, a small shared library with some virtuals,
>     or not at all, remains to be seen
> 
> > If you want to discuss about the screen saver animations please start
> > a new thread and preferable not on kcd but on workspace relevant
> > mailing lists such as kwin or plasma-devel.
> 
> in fact, kcd *is* the relevant list. you can dispute that if you agree
> to assume full responsibility for kscreensaver-bugs-null at kde.org.
well kcd is not the place anymore where the workspace development happens. 
That's what I meant.

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20111011/18ffaf6c/attachment.sig>