linux-kernel - Re: [GIT PULL] kdbus for 4.1-rc1

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, 15 Apr 2015 13:22:12 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Havoc Pennington <hp@...ox.com>
Cc:	Rik van Riel <riel@...hat.com>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Kosina <jkosina@...e.cz>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Tom Gundersen <teg@...m.no>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Daniel Mack <daniel@...que.org>,
	David Herrmann <dh.herrmann@...il.com>,
	Djalal Harouni <tixxdz@...ndz.org>
Subject: Re: [GIT PULL] kdbus for 4.1-rc1

On Wed, Apr 15, 2015 at 9:44 AM, Havoc Pennington <hp@...ox.com> wrote:
> On Wed, Apr 15, 2015 at 12:00 PM, Rik van Riel <riel@...hat.com> wrote:
>> On 04/15/2015 07:06 AM, One Thousand Gnomes wrote:
>>
>>>> that anyone here does either.  In the many years I've spent working on
>>>> this, dbus has seemed to be odd, and strange, to the way that the kernel
>>>> has normally worked, because it is.  And that's not a bad thing, it's
>>>> just different, and for us to support real needs and requirements of our
>>>> users, is the requirement of the Linux kernel.
>>>
>>> There are I think a set of intertwined problems here
>>>
>>> - An efficient delivery system for multicast messages delivered locally
>>>   (be that MPI, dbus whatever - it's not "dbus or nothing")
>>>
>>> - A kernel side dynamic namespace to describe what goes where
>>>
>>> - A kernel side security model to describe who may receive what, and
>>>   which additional information/tags/cred info
>>>
>>> - Something that provides state to stuff that needs it (and probably
>>>   belongs in userspace - dbus name service etc)
>>>
>>> - Something that maps dbus and other models onto the kernel security
>>>   model (and we have tools like EBPF which are very powerful)
>>>
>>> - Something that maps the kernel layer onto models like MPI-3
>
> When trying to split apart problems, for dbus it's important to keep
> ordering guarantees.
>
> That is, with dbus if I send a broadcast message, then send a unicast
> request to another client, then drop the connection causing the bus to
> broadcast that I've dropped; then the other client will see those
> things in that order - the broadcast, then the request, and then that
> I've dropped the connection.

This leads me to a potentially interesting question: where's the
buffering?  If there's a bus with lots of untrusted clients and one of
them broadcasts data faster than all receivers can process it, where
does it go?

At least with a userspace solution, it's clear what the OOM killer
should kill when this happens.  Unless it's PID 1.  Sigh.

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