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 16:25:19 +0200
From:	Martin Steigerwald <martin@...htvoll.de>
To:	David Herrmann <dh.herrmann@...il.com>
Cc:	Stephen Smalley <sds@...ho.nsa.gov>,
	Greg KH <gregkh@...uxfoundation.org>,
	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

Am Freitag, 10. Juli 2015, 16:20:44 schrieb Martin Steigerwald:
> Am Freitag, 10. Juli 2015, 15:43:08 schrieb David Herrmann:
> > Hi
> 
> 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.
> 
> Wow, do I get this right, that this credential faking – I do think that
> the  last two words are already completely sufficient to show the
> insanity of it at least when I apply something to it that is commonly
> called common sense, credential *what*? – is just for supporting
> something that is broken in userspace already?

Ok, I think I now get the dbus-1 userspace probably didn´t need credential 
faking to provide this functionality of providing seclabels to dbus clients. 
So it is more:

"ok, we have some userspace functionality that we need to be compatible to 
it, but in order to do this, we need to do something in the kernel that is 
broken by design"

I vote for keeping the functionality inside userspace then.

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