Re: WM enhancements to support accessible screen lock

[Brian Cameron <Brian Cameron Sun COM>]

Lubos:

Lubos Lunak wrote:
> On Tuesday 23 of September 2003 22:04, Brian Cameron wrote:
>  > Perhaps the largest remaining accessibility hole on the GNOME desktop today
>  > is the lack of an accessible screen lock mechanism.  In order for the lock
>  > screen to be properly accessible, the relationship between the  screensaver
>  > and the window manager will likely need to become more intimate.
> [snip]
>  > Most current lock screen programs run as "override redirect" windows, to
>  > ensure that they get placed on top of all windows, and use GrabKey and
>  > GrabPointer in order to ensure that the screen lock program is
>  > appropriately secure.  However, I believe these mechanisms are simply too
>  > crude to support an AT program such as GOK.
>  >
>  > To support accessibility, the job of controlling window stacking order
>  > should perhaps instead be controlled by the window manager.  In other
>  > words, the screen saver would no longer run as "override redirect" and
>  > instead the screen manager would ensure that the screen lock program would
>  > be at the appropriate stacking order.
>
>  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.

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

>  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

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

--

Brian