First pass on OLPC security modifications to DBus

[Havoc Pennington]

Hi,

On 8/17/07, Noah Kantrowitz <kantrn at rpi.edu> wrote:
> >  - isn't there some name for this feature other than "olpc"? something
> >    specific to the security architecture or whatever?
>
> It could also be called "bitfrost", but I thought "olpc" was a bit
> less cryptic.

As long as OLPC is the only thing ever to use this setup ;-) Well, I
will leave this to you to decide, I don't really know anything about
it.

> >  - the config file setting should be like <fork/> where its presence
> > means "true"
>
> I would like this to take an argument (when I get to it) rather than
> hard coding the name/path/function strings for what is now Rainbow.

You're saying it would allow specifying the system bus name for
something implementing the security interface? That sounds ok.

> 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 ;-)

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.

> I'm still not totally sure I grok this convention. We have been using
> different interfaces to split up our API, but none of it is really
> object-oriented, so we have left them on /. What is the value in
> encoding the API into both the object and interface names?

I have a somewhat rant-ish explanation here that may help:
http://log.ometer.com/2007-05.html

The short answer is that not all interfaces are intended only for
singletons, and not all singletons are implemented by the same code.
(If you had two modules or libraries in one process each providing a
singleton, they would each register a separate callback under a
different object path on the same connection.)

> Which file are the dbus ones in?

I think it's called dbus-types.h or something like that. Just grep for
dbus_int32_t in dbus/dbus/*.h

Havoc