Re: kdbus: add code for buses, domains and endpoints

[Alex Elsayed <eternaleye-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

Andy Lutomirski wrote:

> On Thu, Oct 30, 2014 at 11:08 AM, Djalal Harouni
> <tixxdz-Umm1ozX2/EEdnm+yROfE0A@public.gmane.org> wrote:
>> Hi Andy,
>>
>> On Thu, Oct 30, 2014 at 07:58:04AM -0700, Andy Lutomirski wrote:
>>> On Thu, Oct 30, 2014 at 7:48 AM, Djalal Harouni
>>> <tixxdz-Umm1ozX2/EEdnm+yROfE0A@public.gmane.org> wrote:
>>> > On Thu, Oct 30, 2014 at 05:15:04AM -0700, Eric W. Biederman wrote:
>>> >> Djalal Harouni <tixxdz-Umm1ozX2/EEdnm+yROfE0A@public.gmane.org>
>>> >> writes: What others are doing makes it very hard to safely use allow
>>> >> those ioctls in a tightly sandboxed application, as it is
>>> >> unpredictable what the sandboxed ioctl can do with the file
>>> >> descriptor.
>>> >>
>>> >> Further an application that calls setresuid at different times during
>>> >> it's application will behave differently.  Which makes ioctls that do
>>> >> not have consistent behavior after open time inappropriate for use in
>>> >> userspace libraries.
>>> > We are consistent in our checks, you say that the application will
>>> > behave differently when it calls setresuid() sure! If it changes its
>>> > creds then regain of course it will behave differently! and the checks
>>> > are here to make sure that setresuid() and alike work correctly when
>>> > the application changes its creds and calls-in.
>>> >
>>>
>>> Except that it isn't consistent.
>>>
>>> If I open a postgresql socket that wants me to be root and then I drop
>>> privileges, I can keep talking to postresql.  This is a good thing,
>>> because it means that I can keep talking to postgresql but I lose my
>>> privilege to do other things.
>> Yes, that's nice :-)
>>
>> But here you are not following about those capable() checks in ioctl(),
>> here you are referring to the send (talking) logic! which is another
>> thing. But hey we do not break that use case, we support it.
> 
> I don't understand.  If postgres starts checking the credentials of
> the sender of a query (behind the sender's back, because the current
> kdbus code does it implicitly), then this *doesn't work*.  Postgres
> will see that the sender of the query has the wrong credentials, and
> it will reject.
> 
>>
>>
>>> The new kdbus model breaks this.  If I start as root and drop
>>> privileges to UID_PRIVSEP, then my attempts to communicate over
>>> already-open connections shouldn't consider UID_PRIVSEP.  In the, they
>>> shouldn't tell the other endpoints that UID_PRIVSEP exists at all
>>> unless I've explicitly asked the kernel for this behavior.
>> Yes, but kdbus tries to follow D-Bus which is primarily an RPC system,
>> not just a stream of bytes.
>>
>> So we really want to be able to perform real time checks and authorise
>> method calls on the bus, and not just connections. I mean yes we do our
>> kdbus talk access checks on send (Talk) requests using creds of the
>> connection at creation time, but in the other hand we also need and have
>> to deal with D-Bus method requests which is the primary usecase here.
> 
> I'm sympathetic to this use case (RPC authorization).  I do think that
> you can achieve it by making a new connection at the time at which
> authorization is needed, since kdbus is supposed to be lightweight,
> but that could be an annoying requirement.
> 
> *However*, if an RPC client is making an RPC call that needs
> authorization, it should know that it needs authorization, and it
> should know what authorization it needs, and it should send that
> authorization explicitly.
> 
> If you need lots of data for logging, then have the process sending
> the log message send that data to the logging daemon.  If the logging
> daemon gets less data than it wants, then it can indicate that in the
> logs or return an error.
> 
> [snip]
> 
>> 2) To get the creds of the sender of the message during send time. This
>> is specially relevent to authorize specific D-Bus method calls, by
>> checking the creds of the caller, not the one who created the kdbus
>> connection.
> 
> Please humor me here: can you describe, concretely, a case where
> authorization of the principal issuing a method call is more correct
> than authorization of the principal who connected to the object being
> acted on?
> 
> I suspect that such examples are actually quite difficult to find.
> 
> --Andy

The simple answer is that this is a misaimed question - you don't connect to 
the object being acted on.

You connect to the _same bus_ as other clients have connected to. You then 
act on objects they have made available on the bus.

You might have connected to a restricted endpoint, which provides a narrowed 
view of the bus, but that's neither the same thing nor mandatory.