Starting the kdbus discussions

Marc Deslauriers marc.deslauriers at canonical.com
Thu Jan 2 07:24:11 PST 2014


On 14-01-02 10:03 AM, Lennart Poettering wrote:
> On Thu, 02.01.14 08:46, Marc Deslauriers (marc.deslauriers at canonical.com) wrote:
> 
>> 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.
> 
> The kernel enforces simple Unix-ACL-like access control. i.e. for each
> service the policy contains whether a specific user can send to, receive
> from or own it. Any more finegrained access control then eneds to be
> done by the services themselves. I think in most cases simply checking
> the client's capability set is sufficient for the various methods a
> service might provide, the same way as the kernel statically checks
> specific capabilities of clients calling syscalls. For the cases where
> where more complex access checks should be done we recommend people to
> use PolicyKit, as it is a lot more expressive and supports interactive
> authentication and suchlike.

This has the unfortunate side effect that now every single existing daemon needs
to be modified to add access control, and possibly security framework specific
code. Although it may be a reasonable solution for the system bus, I am more
worried about how to handle access control on the session bus. In order to
properly confine applications, there needs to be a way of enforcing file-grained
access control to the session bus, depending on the specific permissions we give
to the confined application.

> 
>> 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?
> 
> I figure this will be pretty close to the AF_UNIX+SOCK_DRGAM model for
> these LSMs.

That's unfortunate. Everything uses dbus now, an all or nothing access control
isn't sufficient to enforce a reasonable policy for confining untrusted
applications.

Marc.



More information about the dbus mailing list