[RFC] Interface for injection of input events

[Christopher James Halse Rogers]

On Wed, Mar 29, 2017 at 9:33 AM, Jordan Sissel <jls at semicomplete.com> wrote:



On Tue, Mar 28, 2017 at 2:44 PM, Christopher James Halse Rogers <
christopher.halse.rogers at canonical.com> wrote:



On Tue, 28 Mar 2017 at 22:31 Pekka Paalanen <ppaalanen at gmail.com> wrote:

On Tue, 28 Mar 2017 16:20:28 +0900
Carsten Haitzler (The Rasterman) <raster at rasterman.com> wrote:

> On Wed, 22 Mar 2017 13:59:43 +0200 Pekka Paalanen <ppaalanen at gmail.com>
said:
>
> > > == Authentication/Identification ==
> > > The goal is to filter clients based on some white/blacklist, so that
e.g.
> > > xdotool can access this interface but others cannot.
> >
> > Hi,
> >
> > if one allows a generic tool that essentially exposes everything at
> > will, there isn't much point in authenticating that program, because
> > any other program can simply call it.
>
> This is where right now I might lean to some environment variable with a
> cookie/key the compositor provides *and that may change from session to
session
> or on demand).
>
> So compositor might putenv() then fork() + exec() something like a
terminal
> app.. and then this terminal app and anything run from it inherits this
env
> var... and thus now has the secret key to provide...
>
> This also allows the compositor to run any such process that passes the
> key/cookie along to other processes/tools it determines are safe. It would
> require the compositor have a "safe user initiated or approved" way to
run such
> things.

Hi,

that doesn't sound too bad. Initially the cookie could be passed in the
env, until something better comes around. Also the restrictions and
privileges carried with a cookie could vary based on how it was
generated, e.g. cookies created for a container could be invalid for
clients outside that specific container. Or require matching to SElinux
or SMACK or whatever attributes. Or none of these at first. Completely
up to the compositor.

So now we need a spec for the cookie. An opaque binary blob with
variable size, limited by some maximum size? 1 kB max?

(To ensure e.g. Wayland can relay the maximum sized cookie in one
message.)

This could be the generic starting point for all privileged interfaces,
Wayland and others. How the client will get the cookie in the first
place is left undefined. The cookie should probably be optional too, in
case another scheme already grants the privileges.

Giulio, how about incorporating such a cookie scheme in your
restricted_registry design?

OTOH, a spec that uses cookies but does not tell where you might get
one, is that useful? Do we have to spec the env variable?


FWIW, an HMAC cookie is how we handle various privileged actions in Mir
(raise window, drag & drop [because most of D&D is handled
out-of-compositor]), so this would be easy to integrate for us.


I am interested in the security concerns here, but are there reliable
barriers between different processes run by the same user in the same
desktop session? What is the threat model y'all are defending against?


At least on Ubuntu ptrace is restricted to child processes or root, so
while a malicious process could potentially attack a privileged process via
crafted input it's not a simple matter of attaching a debug probe to it.

Also there's the migration(ish) to applications distributed via flatpak and
snap, both of which provide robust (at least under Wayland/Mir) isolation
from each other and the general system.

So, at least one threat model is “we're going to download and run arbitrary
code from the internet, and it shouldn't be able to surreptitiously spawn a
terminal and exfiltrate our GPG keys”.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20170329/7e9f2734/attachment-0001.html>