Re: [PATCH v4 00/14] Add kdbus implementation

[Andy Lutomirski]

On Tue, Mar 31, 2015 at 8:10 AM, Tom Gundersen <teg@xxxxxxx> wrote:
> On Tue, Mar 31, 2015 at 3:58 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
>>
>> IOW you're taking something that you dislike aspects of and shoving
>> most of it in the kernel.  That guarantees us an API in the kernel
>> that even the creators don't really like.  This is, IMO, very
>> unfortunate.
>
> This is a misrepresentation of what David wrote. We do want this API
> regardless of dbus1 compatibility, but compatibility is by itself a
> sufficient motivation. A further motivation is reliable introspection,
> since this meta-data allows listing current peers on the bus and
> showing their identities. That's hugely useful to make the bus
> transparent to admins.

I've heard the following use cases for per-connection metadata:

 - Authenticating to dbus1 services.

 - Identifying connected users for admin diagnostics.

I've heard the following use cases for per-message metadata:

 - Logging.

 - Authenticating to kdbus services that want this style of authentication.

The only reasonable conclusion I've been able to draw is that the dbus
community intends to use *both* per-connection and per-message
metadata for authentication.  This means that, as a general rule,
dropping privileges while you have an open kdbus connection has poorly
defined effects.

It's particularly alarming that, when I express a concern about
logging, the kdbus authors cite authentication as an alternate
justification, and, when I cite a concern about authentication, the
kdbus authors cite logging as an alternative justificaiton.

This is simply not okay for a modern interface, and in my opinion the
kernel should not carry code to support new APIs with weakly defined
security semantics.  It's important that one be able to tell what the
security implications of one's code is without cross-referencing with
the implementation of the server's you're interacting with.

To top that off, the kdbus policy mechanism has truly bizarre effects
with respect to services that have unique ids and well-known names.
That, too, is apparently for compatibility.

This all feels to me like a total of about four people are going to
understand the tangle that is kdbus security, and that's bad.  I think
that the kernel should insist that new security-critical mechanisms
make sense and be hard to misuse.  The current design of kdbus, in
contrast, feel like it will be very hard to use correctly.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/