I haven't had much luck finding documentation on the dbus security model. In particular, how does one prevent one application from spoofing another application's "identity". That is, if I created an application that watched for new launches and managed to guess the activity ID of the launched application, registering a DBUS service for that activity before the activity got a chance, could I then impersonate it?

We have a convenient trusted-path for communicating with activities that we can set up with the overlay/chroot system; we can put a named pipe (unix socket) in the /tmp directory of the chroot. We can use that pipe to provide authenticated communication with the applications in the chroot (since that chroot is the only one with access to their /tmp overlay directory).

Not sure whether that pipe would be used for the actual requests or just to set up an authentication to be sure that activity X really is the thing at dbus address Y. Would depend on how safe dbus is for this kind of thing. To make the overlay system portable and easily integrated on any operating system I'd be tempted to use simple formatted text messages across the interface, with the overlay manager monitoring the pipes for communications using (non-blocking) file IO.

Anyway, will have to look into that when I get the time.

[Update] Key is to look at the specification, rather than the tutorials. The authentication mechanism is outlined here. It looks as though we just need to get a secret key to the application and we can then use that key to authenticate. Need to figure out how we restrict based on the authentication too I suppose. Also how to use the authentication mechanism so that we can always know to which activity (instance) we are talking so that we can prevent spoofing.