linux-kernel - Re: [PATCH 00/12] Add kdbus implementation

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:	Wed, 29 Oct 2014 19:27:54 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Linux API <linux-api@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	John Stultz <john.stultz@...aro.org>,
	Arnd Bergmann <arnd@...db.de>, Tejun Heo <tj@...nel.org>,
	Marcel Holtmann <marcel@...tmann.org>,
	Ryan Lortie <desrt@...rt.ca>,
	Bastien Nocera <hadess@...ess.net>,
	David Herrmann <dh.herrmann@...il.com>,
	Djalal Harouni <tixxdz@...ndz.org>,
	simon.mcvittie@...labora.co.uk, daniel@...que.org,
	alban.crequy@...labora.co.uk, javier.martinez@...labora.co.uk,
	Tom Gundersen <teg@...m.no>
Subject: Re: [PATCH 00/12] Add kdbus implementation

On Wed, Oct 29, 2014 at 3:27 PM, Greg Kroah-Hartman
<gregkh@...uxfoundation.org> wrote:
> On Wed, Oct 29, 2014 at 03:15:51PM -0700, Andy Lutomirski wrote:
>> (reply 1/2 -- I'm replying twice to keep the threading sane)
>>
>> On Wed, Oct 29, 2014 at 3:00 PM, Greg Kroah-Hartman
>> <gregkh@...uxfoundation.org> wrote:
>> > kdbus is a kernel-level IPC implementation that aims for resemblance to
>> > the the protocol layer with the existing userspace D-Bus daemon while
>> > enabling some features that couldn't be implemented before in userspace.
>> >
>>
>> >  * Support for multiple domains, completely separated from each other,
>> >    allowing multiple virtualized instances to be used at the same time.
>>
>> Given that there is no such thing as a device namespace, how does this work?
>
> See the document for the details.

They seem insufficient to me, so I tried to dig in to the code.  My
understanding is:

The parent container has /dev mounted.  It sends an IOCTL (which
requires global capabilities).  In response, kdbus creates a whole
bunch of devices that get put (by udev or devtmpfs, I presume) in a
subdirectory.  Then the parent container mounts that subdirectory in
the new container.

This is IMO rather problematic.

First, it enforces the existence of a kdbus domain hierarchy where
none should be needed.

Second, it's incompatible with nested user namespaces.  The middle
namespace can't issue the ioctl.

Third, it requires a devtmpfs submount in the child container.  This
scares me, especially since there are no device namespaces.  Also, the
child container appears to be dependent on the host udev to arbitrate
everything, which seems totally wrong to me.  (Also, now we're exposed
to attacks where the child container creates busses or endpoints or
whatever with malicious names to try to trick the host into screwing
up.)

ISTM this should be solved either with device namespaces (which is
well known to be a giant can of worms) or by abandoning the concept of
kdbus using device nodes entirely.

What if kdbus were kdbusfs?  If you want to use it in a container, you
mount a brand-new kdbusfs there.  No weird domain hierarchy, no global
privilege, no need to name containers, obvious migration semantics, no
dependence on udev/devtmpfs at all, etc.

Eric, any thoughts here?

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