wayland screen locker and security in general

[Michal Suchanek]

On 12 April 2011 21:04, Iskren Chernev <iskren.chernev at gmail.com> wrote:
> 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

The problem is that "screen locking" is in fact several generic things in one.

While it is completely possible to have a "screenlock plugin" that
does just that but soon you will need "fullscreening plugin", "vnc
plugin", ...

A screensaver needs
 - event spying (to know when the user is active/idle) - also useful
to IM clients, input methods (to get the actual events), magnifying
glass application (to know cursor position), keyboard launchers (which
launch an application whenever a special button is pressed)
 - event grabbing - to prevent other applications receiving events
while the screensaver, and especially the unlock dialog is running -
also useful to games and remote desktop clients (to lock input in
window), possibly drag and drop implementation (to allow dragging
objects over foreign windows), input methods (to get all events while
the method is active)
 - screen grabbing - the ability to paint over whole screen,
preventing anything else doing so - also useful to various other
applications

Some things that a screensaver does not require but other special clients might
 - event injection - vnc server, input methods (both text input
methods and pointer gesture filters)
 - screen spying - used traditionally by some screensaver effects and
useful for magnifying glass application and other effect applications

Some things that a "normal" applicationis expected to do but can be
still limited in some cases
 - create arbitrary amount of window(s) of arbitrary size
 - refresh the window content as often as the application wishes, eg.
million times per second
 - receive events that happen "over" the application window - some
windows may not require input and should be marked so so that they
don't get focus either
 - set an receive paste buffers
 - register paste buffer format convertor

These are not that many operations, and given a protocol that includes
the concept of security and granting applications arbitrary subsets of
these possible access permissions should accomodate pretty much any
current application.

But the replies so far aside from yours can bu summarized as "Shush,
we don't need that, we can just add a hack to the compositor for
this".


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

Other OSes do try, eg NT based Windows.

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

Since on POSIX the unit of security is UID no cryptography is
required, a magic cookie like ~/.Xauthority suffices to prove that the
application is running under that user on that machine. This should
make it possible to run Wayland applications using sudo and not have
those applications take over the user's session.

The default policy should include some limit on the amount of
resources an application can allocate to prevent Wayland going down or
being littered by hundreds of windows. It should be possible to raise
the limit when needed, and since it is supposed to be something not
hit very often it is probably acceptable for this to be implemented
interactively  - eg. a compositor or a policy monitor opens a dialog
box saying "Application 'awdsaf' is trying to open more than 20
windows, do you want to allow it to open another 20?". Of course,
there is a possibility that a separate connection will be made for
each window and that should be dealt with as well. Since there is no
security on POSIX the dialog or associated process manager can provide
quite a bit of information about the process(es) opening the offending
windows.

On systems with real security the magic cookie should be replaced with
kernel protected handle which provides a process with the authority to
perform some operation(s) on the server that issued the handle. This
should also prevent resource exhaustion as the server should not give
out handles for more resources than it possesses.

Thanks

Michal