[PATCH] Introduce the authorizer protocol

[Pekka Paalanen]

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.

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

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?

> > > > > 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151126/f4460ba0/attachment.sig>