[PATCH] Introduce the authorizer protocol

[Giulio Camuffo]

2015-11-26 10:21 GMT+02:00 Pekka Paalanen <ppaalanen at gmail.com>:
> On Wed, 25 Nov 2015 17:39:25 +0100
> Mariusz Ceier <mceier+wayland at gmail.com> wrote:
>
>> Hi,
>>
>> On 25 November 2015 at 16:14, Pekka Paalanen <ppaalanen at gmail.com> wrote:
>>
>> > On Tue, 24 Nov 2015 18:07:34 +0100
>> > Mariusz Ceier <mceier+wayland at gmail.com> wrote:
>> >
>> > > Hi,
>> > >
>> > > On 24 November 2015 at 17:35, Giulio Camuffo <giuliocamuffo at gmail.com>
>> > > wrote:
>> > >
>> > > > 2015-11-24 18:16 GMT+02:00 Mariusz Ceier <mceier+wayland at gmail.com>:
>> > > > > Hi,
>> > > > >   How the clients will know:
>> > > > > a) which interface is restricted and which is not ?
>> > > >
>> > > > It doesn't, but does it need to know it? It can still ask for
>> > > > authorization even if the interface is not.
>> > > >
>> > > >
>> > > I think it should - otherwise client, that wants to run on as many
>> > > compositors as possible, would have to send authorize requests for every
>> > > interface, since different compositors can implement different policies
>> > and
>> > > interface in one compositor can be unrestricted while in another
>> > > restricted.
>> >
>> > Why should we separate restricted interfaces in the registry level? Or
>> > at all?
>> >
>> >
>> Because binding restricted interface kills client and since interface
>> specification doesn't tell if that interface is restricted or not, binding
>> would be a gamble for client. Also to authorize the client to use of
>> restricted interface, authorizer object needs to be created - that means
>> restricted interfaces can't be bound before authorizer object is announced,
>> and that means restricted interfaces can't be announced before authorizer
>> is announced, unless client can bind them later (which I don't think is a
>> case).
>
> As said, all clients must be able to deal with arbitrary advertising
> orders. There is nothing hard with that, even toytoolkit supports it.

Agreed.

>
>> The interface specification needs to say whether it is restricted or
>> > not. If a compositor does not care about restricting it, it'll just
>> > always answer "yes."
>> >
>>
>> Even if interface specification would include information whether it's
>> restricted or not, that information would have to be included in protocol -
>> since later versions of protocol can become restricted.
>
> If later versions become restricted, that changes nothing here. Clients
> using earlier versions will bind an earlier version and avoid the
> security check. A client implementing support for the restricted version
> obviously also implements support for getting the authorization,
> because that is part of the spec.
>
> If you mean retroactively restricting, see below.
>
>> > When you design a new protocol extension, I can't imagine that you
>> > would not know if it needs to be restricted or not. Do you have any
>> > example to the contrary?
>> >
>>
>> I think it may be the case during development and even after it gets
>> stabilized.
>> It may be unrestricted at first, but then someone might find security bug
>> (in design) or request requiring privileged access could be added - in
>> these cases compositors probably would like to restrict access to that
>> interface.
>> In v1 of authorizer that would mean, that clients which assumed that
>> specific interfaces are unrestricted would be killed by compositor.
>> And in v2 authorizer clients would know that they need to send authorize
>> request first - since interface wouldn't be available in wl_registry but
>> only in wl_restricted_registry.
>
> Ok, that makes some sense, but I'm still skeptical.
>
> If there is an app using a global Foo, that is then discovered insecure
> and becomes retroactively restricted, it would no longer be advertised
> in the normal registry. If the app relied on Foo, it no longer works
> without changes. If Foo was optional for the app, the app continues to
> work without it, but getting it back would again require changes in the
> app to get it to look for it from the restricted registry. If it has
> code to look in the restricted registry, it could still be denied the
> authorization.

However if an app can work even without the Foo global, or just wants
to display a nice user friendly dialog saying Foo is not available
instead of just dying, moving the global from wl_registry to
wp_restricted_registry would allow the app to realize Foo is not
available, while just making the global in wl_registry restricted
would mean the app would unknowingly try to bind it and it would get
killed. So i'd say the restricted registry is more app/user friendly
here.

>
> So this would work like a per-client selective interface deprecation
> assuming that clients support searching for globals from both
> registries.
>
> It is a nice mechanism, but I have the feeling that this is a too
> generic solution to a problem that is only hand-waving at this point.
>
> Continuing with the speculation, what if the authorization request
> would need interface specific parameters?

Interesting question. I'd say that if an interface needs that it
should have some custom request to be used after the bind. I'm not
sure what those parameters could be though... a client can always lie
when passing parameters to a request, the only thing a compositor can
trust when authorizing it is the wl_client credentials.


--
Giulio

>
>> > > > > b) that the compositor implements restricted interface ? should they
>> > be
>> > > > > visible in the registry ?
>> > > >
>> > > > Well, they are normal globals so they will are available in the
>> > > > registry. If needed, this interface could
>> > > > send out a list of the restricted ones, but i'm not sure it is.
>> > > >
>> > > >
>> > > If they're normal globals - registry will contain a mix of restricted and
>> > > unrestricted interfaces, and in current state clients won't know which is
>> > > restricted and which is not, and binding to restricted interface will
>> > kill
>> > > client - are we playing russian roulette ? ;)
>> >
>> > Clients do not go binding random globals without knowing the
>> > specification.
>> >
>>
>> Still specification doesn't say which protocol is restricted and which is
>> not. In v1 authorizer clients can't assume that specific interface is
>> always unrestricted (it could become restricted in later version or
>> compositor could implement different policy), so they would have to send
>> authorize request for each interface they use.
>
> My premise is that the spec *should* say if a global is restricted.
> Otherwise it's free for all if the spec is installed publicly.
>
> The exception I can think to that is that a single interface would be
> exposed as several global instances, some of which are restricted and
> some are not. But then this seems like an inferior solution, because an
> app still has to try an bind these blind to see what they actually are,
> restricted or not.
>
>> > > I think something like wl_registry but for restricted interfaces only,
>> > may
>> > > be a better solution.
>> >
>> > I see no need for this.
>> >
>> > > Also since authorizer is another global, it would have to be announced
>> > > before any restricted interface, right ?
>> > > That requirement probably should be added to description.
>> >
>> > There is no such requirement. Clients *must* deal with arbitrary
>> > announcements orders anyway.
>> >
>> > Except they would get killed for trying to bind  restricted interface
>> without sending authorize request - and they can't send it before getting
>> authorizer object (in v1). So v1 introduces weak order here.
>
> No, no ordering in advertisements must be required. For one,
> libwayland-server API makes no guarantees on the ordering.
>
> Clients can easily collect all existing global advertisements during
> their init, and then look at what they want to bind. Clients also have
> to maintain the list of globals anyway, because globals can also
> disappear and you might want to bind something later.
>
>
> Thanks,
> pq