linux-kernel - Re: kdbus: credential faking

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 10 Jul 2015 07:57:38 -0700
From:	Alex Elsayed <eternaleye@...il.com>
To:	linux-kernel@...r.kernel.org
Cc:	linux-security-module@...r.kernel.org
Subject: Re: kdbus: credential faking

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).

<snip>

--
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/