On Thu, Oct 30, 2014 at 11:08 AM, Djalal Harouni <tixxdz@xxxxxxxxxx> 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@xxxxxxxxxx> wrote: >> > On Thu, Oct 30, 2014 at 05:15:04AM -0700, Eric W. Biederman wrote: >> >> Djalal Harouni <tixxdz@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
