Re: WM enhancements to support accessible screen lock

[Lubos Lunak <l lunak suse cz>]

On Wednesday 24 of September 2003 22:34, Brian Cameron wrote:
> Lubos:
>
> Lubos Lunak wrote:
[snip]
> >
> >  It may be too crude, but it's the only way I'm aware of how to make the
> > locking really work and not just be something laughable. If you don't
> > grab the keyboard, you cannot really prevent other applications from
> > getting keyboard input (e.g. global shortcuts).
>
> Could you give an example of a global keyboard shortcut that would allow
> a problem behind the lockscreen window to grab focus.  It seems to me that
> the window manager could enforce that no prograb behind the lock screen
> window could get key/mouse focus under any circumstance.  But since you say
> otherwise, I must be overlooking something.

 For example KDE's Ctrl+Alt+Esc, which provides the same functionality like 
xkill. Just press it, click on the screensaver window -> boom, lock is gone. 
This one is actually provided by the window manager, so that could be handled 
I guess. A different example might be a keyboard shortcut for logging out - 
KDE has both shortcut for direct logout without asking, and even with asking, 
the logout dialog actually performs grabs. Moreover it's not handled by the 
WM, so that's another problem.

 Such things probably could be handled, but would it be possible to handle 
them all, and the effort be worth it?

>
>  > Even with mouse not being grabbed,
> >
> > the mouse could be used to get around the lock. And last but not least,
> > without an override redirect window that's constantly kept at top, other
> > applications could get higher, if they would use override redirect
> > windows themselves.
> >
> >  The last two problems could be perhaps handled by the window manager
> > keeping the lock window very high as currently the locking programs do,
> > but I don't think there's any solution for the keyboard problem.
> > Moreover, I simply don't
> > like the idea of using the window manager for this (based on personal
> > experience, unfortunately - some KDE versions actually used a managed
> > STAYS_ON_TOP window as the locking window and helped it to stay high by
> > watching for ConfigureNotify events which were followed by
> > XRaiseWindow(); it
> > wasn't really that difficult to break it). In other words, I have certain
> > doubts about quality and security of a screen locking application as
> > complex as a window manager.
>
> Please share your doubts in more detail.  Your current concerns seem a
> little vague to me.

 See above. Basically, window managers may be complicated applications, much 
more complicated than the locking ones, and it would take much more work to 
make sure it's done properly. You'd need to handle this, and take care of 
that, and not forget also that, and so on. That's why I don't like this - 
window managers are complicated enough even without it.

>
> >  Wouldn't it be much simpler if those accesibility windows had some
> > property
> > identifying them, but it would be the screen locking application that
> > would take care of their stacking and similar things? (Not that this
> > would be that
> > secure either - anybody could set that property then, and get around the
> > locking.)
>
> Yes, it really doesn't matter if the screen lock program or the window
> manager controls whether the AT programs stay on top.  Either way, though,
> I think we still need to create the appropriate WM specification for
> indicating what programs must remain on top.
>
> I recommend that the WM_TYPE_VISIBLE_WHEN_SCREEN_LOCKED message is only
> honored if it is set before the window is first shown on the screen (and
> managed by the window manager).  In other words, this message should not
> be dynamic.  The value of the message is set when a program starts, and
> changing it will have no effect.
>
> I would also recommend that no window that is started while the lock
> screen is displaying is ever shown on top of the lock screen, even if
> the WM_TYPE_VISIBLE_WHEN_SCREEN_LOCKED message is set.  This would prevent
> a malicious person from changing a window's
> WM_TYPE_VISIBLE_WHEN_SCREEN_LOCKED value and getting it to appear in front,
> or starting new applications and getting them to appear in front.  In other
> words, *only* programs with the WM_TYPE_VISIBLE_WHEN_SCREEN_LOCKED message
> set that were running before the user locked their screen should be allowed
> to be visible above the screen lock program.
>
> I think this makes things reasonably secure, since the user should be
> able to immediately identify any problem when they lock their screen.
> Also, I think that windows that have the WM_TYPE_VISIBLE_WHEN_SCREEN_LOCKED
> message set should be visibily different than other windows.  Perhaps with
> a different colored border, for example, or with a keyword in the window's
> title.  This way any such program can be immediately and easily identified
> as a program that will be visible when the screen is locked

 This sounds better, even though I'm not sure if security concerned people 
would find this acceptable ... not that I'm one of them.

 Technically, it's probably not necessary to have special window type for such 
windows. I think it should be just enough to have one extra property 
KEEP_ME_ABOVE_LOCK or something like that. The locking application would just 
search all toplevel windows including override redirect ones, and take care 
of their stacking order. Hmm, no, that wouldn't work with non-override 
redirect ones, the WM would win. If that actually matters.

 Perhaps we then could have special window type for such accessibility tools 
and similar windows, that should be always on top no matter what. What do 
others think?

>
> >  That way, those windows would be kept above the locking screen. The
> > input events would probably have to be forwarded to them, mouse events
> > should be simple, keyboard would be more difficult.
>
> Yes, a mechanism more sophisticated that the current grabs will likely
> be necessary to support an AT program like GOK.

 Do any of those tools actually need keyboard input?


-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l lunak suse cz , l lunak kde org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/