[RFC] Interface for injection of input events

[Carsten Haitzler (The Rasterman)]

On Tue, 28 Mar 2017 14:31:24 +0300 Pekka Paalanen <ppaalanen at gmail.com> said:

> 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

Just saying... it's the first (and best) idea that comes to mind.

We use SMACK in Tizen to sandbox apps. But I am sure others will use other
schemes. If every OS/distro has some other sandboxing scheme it'll be REALLY
hard for compositors to be portable as they then have to support every possible
security scheme to auth privileged clients.

If i make the assumption that a sandboxing scheme will at a minimum disallow
apps that are not meant to have access to the environment of a process to read
it (i.e. /proc/PID/environ), and that an app given a cookie will be careful not
to pass it on (via publicly readable files, IPC, or execution) to other apps it
does not also trust as much as itself...

Then an environment variable actually works nicely. An app can read it then
putenev()/unsetenv() it after it's already been used or stored elsewhere (or
before forking+executing anything untrusted).

This should work irrespective of the MAC/sandboxing mechanism and thus would
provide some kind of method "we all agree on" for granting some kind of
privileges to some client.

If there is a better idea, please do share. This is not necessarily the best.
It's just the best one that popped int my little head. :)

> env, until something better comes around. Also the restrictions and

I think that we should specify the environment variable much like XDG does too.
If it is otherwise shared via another mechanism, at least for now that could be
"implementation defined" based on the sharing/IPC protocol or whatever between
those processes.

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

I see no reason why a compositor can't impose EXTRA restrictions like the
above. E.g. check cookie AND then also check client container or smack label
or... whatever. So if the cookie leaked outside of this sandbox it would be
invalid anyway. Each cookie can indeed also represent different access
privileges so a cookie would only at best grant access to what it was intended
to gain access to and nothing more (if the compositor did it right).

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

I'm pretty agnostic on what it is. I might lean to a string, not a binary blob.
Because This is easily embedded in an environment variable as-is.

I would suggest that the compositor use something like a SHA256 hash and then
base64 encode it (so it'd end up being 48 bytes of a string + 0 byte).

But perhaps an opaque binary blob in protocol and define the environment
variable to be a base64 encoding of that?... or hex? ...

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

I would agree with making it optional if the compositor can determine some
other way that this request from a client (dbnus, wl protocol... doesn't
matter) is already allowed.

I really just want us to have a "single mechanism" we can agree on for doing
this that isn't OS dependent and "unportable".

I still would lean to, for now, defining an environment variable as that's a
pretty basic guarantee of at least 1 way to get it.

Any user who can get a cookie from their compositor can "empower" their shell
with an easy:

export WL_PRIV_COOKIE="77fa767c28c73782988910eee0abcd8824894"

or whatever. :)

> 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?
> 
> 
> Thanks,
> pq


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com