Starting the kdbus discussions

[John Johansen]

On 01/02/2014 11:30 AM, Alberto Mardegan wrote:
> On 01/02/2014 06:23 PM, Marc Deslauriers wrote:
>> I'd rather use kdbus, but not at the expense of being able to enforce a central
>> fine-grained security policy like we are doing now on Ubuntu Touch, and will be
>> doing on the desktop in the near future. Sure, we could stick with dbus-daemon
>> for now, but ideally having dbus in the kernel would be beneficial from a
>> performance perspective (probably...would have to benchmark it...). Having a LSM
>> be able to perform fine-grained security decisions in kdbus would be ideal.
> 
> Does it really need to be centralized? Can't we patch GDBus and libdbus1
> to check the incoming messages against an apparmor profile?
> Given how GVariant serialization works, this should be feasible with a
> minimal impact on performance. And it should be possible to share the
> implementation of this check, and just have a 2-line patch in GDBus and
> libdbus1:
> 
> if (!apparmor_check_kdbus_message(fd, &message_gvariant))
>     return;
> 
> (assuming we can get the peer's apparmor profile via the kdbus fd)
> 
Its an incomplete solution that doesn't provide the same level of trust.

You have to trust an application/service to a degree within the confines of the
services you are allowing it to offer within your policy. But when an application
is enforcing policy you have to trust that it is enforcing all the policy and
not subverting it any way (offering extra services, being selective in its
enforcement etc), and you have to trust that the application is doing it correctly
(which the library helps with) but even with the enforcement hooks in the library,
applications can use their own code to by-pass it.

This is fine for application/services that have been audited and are in the archive
but isn't for the sandboxed apps/services that have limited or no auditing that are
being allowed to offer services (click apps in Ubuntu).

Having the app enforce policy for its services also has other limits. You may
not want to give it enough privilege to kill rogue applications that are
sending bad requests. It needs the privilege to log the denial or other policy
oriented messages. Its incurs the cost of logging or enforcement actions.

For better or worse we are moving to an environment where untrusted applications
are communicating and offering a limited set of services.