First pass on OLPC security modifications to DBus

[John (J5) Palmieri]

On Sat, 2007-08-18 at 09:14 -0400, Havoc Pennington wrote:

> > J5 had mentioned that setting up the bus connection was a relatively
> > slow operation, and in round two of these changes we want to be
> > calling out to Rainbow on all messages (in addition to all bindings)
> > to do authz on the source and destination names. If you think this
> > would be okay performance-wise I'll put it back.
> 
> Setting up the connection is slow, but dbus_bus_get() only sets up
> once, after that it just returns the value of a global variable.
> 
> While speculating on performance without profiling is always
> dangerous, I would be shocked if the performance hit of this feature
> wasn't virtually all from the call to the system bus. Right now a
> single message sent from app A to app B involves 4 "hops" (method call
> A->bus, bus->B, reply B->bus, bus->A).
> 
> Once you check every message and not just name ownership, this patch
> would add 8 more "hops" to do the two method calls to ask for security
> clearance - 4 for the method call, 4 for the reply. Since "hops"
> already dominate dbus performance, I would expect that this patch
> means 4 hops performance becomes 4+2x4 hops performance, so 3x
> slowdown.
> 
> Which does not necessarily matter, since in the context of a whole
> desktop this IPC stuff is probably sub-1% on the profile, but please
> don't do any dbus benchmarking with this enabled ;-)

On our system D-Bus can account for %50 or more (profiled) in startup
times when using blocking calls which everyone assumes is fast because
they have fast machines :)  The performance hit will need to be looked
at.  Personally I think we may need to have trusted services in which
rainbow authenticates it once and then the bus keeps track of it. The
vserver zero overhead mantra is a nice battle cry but as we see there
will be consequences of the decisions we make.

> You might want to skip the security check on the method reply, since
> dbus already only allows through a "solicited" method reply that
> matches a previously-allowed method call. Then you'd only have a 2x
> slowdown instead of 3x.

Trust the bus :)

-- 
John (J5) Palmieri <johnp at redhat.com>