Starting the kdbus discussions

Thu Jan 2 06:40:45 PST 2014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/02/2014 09:23 AM, Kay Sievers wrote:
> On Thu, Jan 2, 2014 at 2:46 PM, Marc Deslauriers 
> <marc.deslauriers at canonical.com> wrote:
>> This is pretty interesting. Are there any benchmarks available to show
>> what the performance gains are when switching to kdbus?
> 
> No, not really. At least no direct comparison. Simple benchmarks to compare
> different systems are in the kdbus and systemd repos, but they do not
> compare to dbus-daemon: 
> https://plus.google.com/+KaySievers/posts/PrFZMYihbXS
> 
>> In the PORTING-DBUS1 document, you mention that the kernel will not do
>> access filtering by userspace payload, and that policy enforcement needs
>> to be done by the receiving process. This is quite a big change from the
>> current dbus-daemon, and is going to remove functionality we are
>> depending on.
> 
> Right, the actual payload is opaque to the kernel. Only metadata is added
> to a bloom filter, and the kernel filters on that data. Due to the nature
> of bloom filters, that cannot be used to provide any sort of security.
> 
>> We are about to submit a patch that adds AppArmor mediation alongside
>> the current SELinux mediation in dbus-daemon. This allows us to properly
>> confine untrusted applications with AppArmor and enforce a fine-grained
>> policy on path, interface and method names, not only for the system bus,
>> but for the session bus as well.
> 
> That cannot work in the kernel that way.
> 
>> Are there any plans on extending the kernel support to be able to parse
>> the userspace payload and ensure proper LSM integration? How do security
>> frameworks such as SELinux and AppArmor fit into kdbus?
> 
> They will probabaly work on the primitives only, like who can talk to which
> peer, who can own which set of names. Just like SELinux works for sockets,
> the kernel in this case will also never look into the payload of sockets.
> 
> It needs to be so sorted out, we haven't talked to the SELinux guys so far,
> it will happen soon.
> 

We already somewhat block which domains can dbus chat with with domains,
although I prefer to drop to the level of which domain can read/write on a
particular service.  This would need to be controlled at the application
server level.

What we would be interested in is controlling which process can assume the
service name.  IE NetworkManager_t could assume the NetworkManager Service,
and be blocked from assuming the AccountsDaemon Service name.