[PATCH] Introduce the authorizer protocol

[Pekka Paalanen]

On Wed, 2 Dec 2015 12:28:33 +0200
Giulio Camuffo <giuliocamuffo at gmail.com> wrote:

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

Right. The point is to stop advertising the old global in wl_registry.

What you would do in addition to that is up for debate: would it be
enough to just advertise it on a different name?

There is the point of view that making an interface restricted
retroactively constitutes breaking the protocol. This is why I advocate
having the interface spec define restrictions in the first place.

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

The DRM authentication mechanism comes to mind as an example.

But then, if you need another authentication/authorization handshake in
the interface itself, do you need the authorizer in that case at all?

In general, I don't want to shoot down this proposal even if it sounds
like it a bit. I'm trying to poke some holes in it to make it
better. ;-)

It seems an interesting experiment. I just wonder if a real use case
for the retroactive restriction will ever emerge.


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/20151203/d4455d01/attachment.sig>