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 15:04:47 -0700
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Stephen Smalley <sds@...ho.nsa.gov>
Cc:	David Herrmann <dh.herrmann@...il.com>,
	Daniel Mack <daniel@...que.org>,
	Djalal Harouni <tixxdz@...ndz.org>,
	lkml <linux-kernel@...r.kernel.org>,
	LSM <linux-security-module@...r.kernel.org>,
	Paul Osmialowski <p.osmialowsk@...sung.com>,
	Casey Schaufler <casey@...aufler-ca.com>,
	Paul Moore <paul@...l-moore.com>
Subject: Re: kdbus: credential faking

On Fri, Jul 10, 2015 at 10:47:32AM -0400, 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)?

Yes.

There are also programs that use "native" dbus libraries written in
other languages than C that use the unix-socket to talk the dbus
protocol to the system.  As a specific example, Go has one of these
libraries, and it's built statically into go binaries, so there is no
"system library" that could be updated for these binaries to avoid this
interface.

I'm sure over time that these libraries will move toward using kdbus
"directly" if it is present, but at the moment, we don't have that
luxury.

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

I wish we could, but we can't break programs that are currently running
today, that would be pretty mean.

thanks,

greg k-h
--
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/