Message-ID: <55A004E2.4020000@schaufler-ca.com>
Date:	Fri, 10 Jul 2015 10:46:10 -0700
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	Alex Elsayed <eternaleye@...il.com>, linux-kernel@...r.kernel.org
CC:	linux-security-module@...r.kernel.org
Subject: Re: kdbus: credential faking

On 7/10/2015 9:30 AM, Alex Elsayed wrote:
> Casey Schaufler wrote:
>
>> On 7/10/2015 7:57 AM, Alex Elsayed wrote:
>>> Stephen Smalley wrote:
>>>
>>>> On 07/10/2015 09:43 AM, David Herrmann wrote:
>>>>> Hi
>>>>>
>>>>> On Fri, Jul 10, 2015 at 3:25 PM, Stephen Smalley <sds@...ho.nsa.gov>
>>>>> wrote:
>>>>>> On 07/09/2015 06:22 PM, David Herrmann wrote:
>>>>>>> To be clear, faking metadata has one use-case, and one use-case only:
>>>>>>> dbus1 compatibility
>>>>>>>
>>>>>>> In dbus1, clients connect to a unix-socket placed in the file-system
>>>>>>> hierarchy. To avoid breaking ABI for old clients, we support a
>>>>>>> unix-kdbus proxy. This proxy is called systemd-bus-proxyd. It is
>>>>>>> spawned once for each bus we proxy and simply remarshals messages
>>>>>>> from the client to kdbus and vice versa.
>>>>>> Is this truly necessary?  Can't the distributions just update the
>>>>>> client
>>>>>> side libraries to use kdbus if enabled and be done with it?  Doesn't
>>>>>> this proxy undo many of the benefits of using kdbus in the first
>>>>>> place?
>>>>> We need binary compatibility to dbus1. There're millions of
>>>>> applications and language bindings with dbus1 compiled in, which we
>>>>> cannot suddenly break.
>>>> So, are you saying that there are many applications that statically link
>>>> the dbus1 library implementation (thus the distributions can't just push
>>>> an updated shared library that switches from using the socket to using
>>>> kdbus), and that many of these applications are third party applications
>>>> not packaged by the distributions (thus the distributions cannot just do
>>>> a mass rebuild to update these applications too)?  Otherwise, I would
>>>> think that the use of a socket would just be an implementation detail
>>>> and you would be free to change it without affecting dbus1 library ABI
>>>> compatibility.
>>> Honestly? Yes. To bring up two examples off the bat, IIRC both Haskell
>>> and Java have independent *implementations* of the dbus1 protocol, not
>>> reusing the reference library at all - Haskell isn't technically
>>> statically linked, but its ABI hashing stuff means it's the next best
>>> thing, and both it and Java are often managed outside the PM because for
>>> various reasons (in the case of Haskell, lots of tiny packages with lots
>>> of frequent releases make packagers cry until they find a way of
>>> automating it).
>> There is absolutely no reason to expect that these two examples don't have
>> native kdbus implementations in the works already.
> The Haskell one, at least, does not. I checked.

OK, I stand corrected. A bit surprised, but corrected.

>> That's the risk you take when you eschew the "standard" libraries.
>> Further, the primary reason that developers deviate from the norm is (you 
> guessed it!) performance.
>
> Or, you know, avoiding the hassle of building and/or linking to code in 
> another language via FFI. That's my recall of the primary reason for the 
> Haskell one - and I don't think it's any coincidence that the two pure 
> reimplementations are in managed-but-compiled languages.

That's a design choice, and I expect that performance is going to matter
more to Java than to Haskell. I have not got a lot of experience with
Haskell programmers, but I do with the Java variety. The Java folks are
going to want the performance.

>> The proxy is going to kill (or at least be assumed to kill) that
>> advantage, putting even more pressure on these deviant applications to
>> provide native kdbus versions.
> ...sure, if performance was the object. But it went through the old D-Bus 
> daemon either way, so I'm rather dubious of your assertion - whether due to 
> being in userspace or just poor implementation, it's no speed daemon so to 
> speak.

That's a whole different thread. If dbus performance got fixed there'd be
no selling point for kdbus. 

>> Backward compatibility shims/libraries/proxies only work when it's the
>> rare and unimportant case requiring it. If it's the common case, it won't
>> work. If it's the important case, it won't work. If kdbus is worth the
>> effort, make the effort.
> They also work if they require no configuration or effort from the legacy 
> side, allowing those who need the (possibly rare *but also* important) 
> benefits of the new system to benefit without causing harm to others.

Sorry, but there are no unicorns dancing on that rainbow.
It sounds good, but you always hit outliers that use things
in a perverse or unnatural, but technically permitted way.
The "first, do no harm" mantra may work when you're carving
on someone's spleen, but it is pretty destructive when you're
building significant software infrastructure.

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

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

Powered by blists - more mailing lists