wayland screen locker and security in general

[Iskren Chernev]

I don't think this lengthy discussion led to any concrete answers, but I do
think that the questions are important and need such answers.

I'll try to summarize the problems that need attention:
1. screen locking
1.1 who is going to implement it: compositor/compositor plugin/app
1.2 inhibit locking for movie players, slide-shows etc
1.2.1 what protocol to use to make sure screen saver wont stay inhibited
forever because of broken app
1.2.2 what communication mechanism to use: compositor/dbus/other
2. Full screen apps -- need a way to specify that no other windows should be
displayed on top of this one. What if multiple apps want to claim the
screen?
3 Security issues
3.1 Protect from bad clients allocating too much pixmap space (and maybe
other resources)
3.2 Make sure that the password requesting prompts are genuine, i.e. no app
is going to look like another one (screen saver) and request the user pass
in the same way so the user is tricked to enter it inside. I don't think any
other OS tries to do this, but I might be wrong.
4. In case we choose to use apps to implement special features as screen
locking (opposed to compositor[-plugins]) then I don't understand how can an
app authorize itself for the compositor. For example the screen saver app
should tell the compositor that it is that exact app, so the compositor will
grant special privileges (or proxy or arbiter, whatever). So is this process
going to involve asymmetric cryptography, and if yes where is the private
key going to be stored. This may be a very stupid question, but I haven't
seen anything of that sort so I'm wondering how its going to be made.

I may be missing some, so please note them if you find any.

Regards,
Iskren

On Tue, Apr 5, 2011 at 11:59 AM, Michal Suchanek <hramrach at centrum.cz>wrote:

> Hello,
>
> what is the plan for screensave/screenlocker support in wayland?
>
> The support in X is a fail in several ways.
>
> First off there is no way to select all events. While you can spy on
> mouse position or key events you can't spy on mouse events so the
> screensaver activates when only mouse buttons/wheel are used.
>
> Second the way to lock the screen is to grab the X input (pointer and
> keyboard) so that other applications can't get them while the screen
> is locked. This fails when a grab already exists because X has only
> one grab and it is acquired on first-come first-serve basis. A
> technical issue with X protocol also requires the grab to be taken for
> pulldown menus and drag and drop operations in any application.
>
> Third is that you can't cover the screen. xscreensaver creates a
> fullscreen window to show the cool effects (or cool blackness) and
> raises it to top but subsequently created windows can get on top of
> it. xscreensaver works around it by raising the window every few
> minutes but there is no way to ensure that the screen is covered.
>
> There are other issues as well. In X any application can allocate any
> amount of pixmaps eventually crashing the X server.
>
> There should be a mechanism that allows limiting the damage a single
> application can do.
>
> There are several options here.
>
> One is to have some policy in the wayland server/compositor eg people
> suggest that applications should not be able to lock the screen, and
> the screenlocker binary be in a specific place, the wayland compositor
> implements a toolbar with a lock button, and whenever the button is
> pressed that binary is executed and granted the privilege to lock the
> screen.
>
> Another option is to use a proxy. The compositor and screenlocker
> would connect to the server directly while applications would connect
> through a proxy that denies some requests. The proxy can implement
> some policy like allowing up to 5MPix of screen data in up to 5
> windows refreshed up to once per vsync.
>
> Yet another option is to have policy advisor to which  the server
> talks through a separate connection. Whenever an application sends a
> request to the server it asks a policy advisor if the request should
> be honored.
>
> Compared to the proxy solution there are advantages and disadvantages.
>
> The disadvantage is that the server has to process even requests that
> are denied.
>
> The advantage is that the server can talk to the application directly.
> eg the application selects some events, the policy allows selecting
> them, and then the application can receive events directly.
>
> A non-trransparent protocol could have advantages of both. The
> application first talks to the policy server, and if the request is
> allowed it gets a handle which can be used to perform the request on
> the display server, input driver, or whatever other component
> implements it.
>
> With either the advisor or the proxy the policy can be dynamic and
> negotiated between the advisor and the application by arbitrary
> protocol independent of wayland protocols. With either the system
> fails when the policy component fails - either the proxy goes down and
> stops forwarding requests and repliesor the advisor goes down and
> every new request is denied.
>
> Thanks
>
> Michal
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20110412/d5515aa8/attachment.htm>