[RFC] Interface for injection of input events

[Jordan Sissel]

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?

-Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20170328/19440f85/attachment.html>