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:	Thu, 16 Apr 2015 14:13:44 +0200
From:	David Herrmann <dh.herrmann@...il.com>
To:	James Bottomley <James.Bottomley@...senpartnership.com>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Kosina <jkosina@...e.cz>,
	Steven Rostedt <rostedt@...dmis.org>,
	John Stoffel <john@...ffel.org>,
	Andy Lutomirski <luto@...capital.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Tom Gundersen <teg@...m.no>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Daniel Mack <daniel@...que.org>,
	Djalal Harouni <tixxdz@...ndz.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Subject: Re: [GIT PULL] kdbus for 4.1-rc1

Hi

On Wed, Apr 15, 2015 at 8:12 PM, James Bottomley
<James.Bottomley@...senpartnership.com> wrote:
> For me the biggest issue is the container problem: it's really hard to
> containerise kdbus because of the stateful nature of the protocol and
> the fact that it has a well known system bus.  Separation into domains
> works for OS containers, but application containers need more fluidity.
> It's not unlike the same problem on windows: Windows application
> containers are very difficult to do because the global registry means
> that OLE handlers all have to run inside your container as well
> (effectively making it an OS container).  I'm sure, since we already
> have a lot of containers people going to plumbers, that we can get them
> to turn up for the discussion.

kdbus actually works very well in OS containers that mount a new
kdbusfs inside the container. This new instance of kdbus will be
entirely seperated from any other on the system. We've designed it
that way especially with OS containers in mind. This is explained in
kdbus.fs(7). It's very similar to devpts' container support, where you
mount a new instance of devpts into each container instance you run.

For Docker-style (i.e. app-focused) containers, it's a more complex
story. kdbus will not solve this for you, but at least one thing
deserves being mentioned: for this kind of sandboxing kdbus certainly
makes things *easier*, compared to dbus1. Why? because the kernel
gains a notion of individual messages and method call transactions,
something that is completely unavailable if you stick to dbus1 where
all the kernel sees is a raw stream of AF_UNIX/SOCK_STREAM bytes. In
fact, kdbus as it is right now even contains minimal but explicit
support for sandboxing, by allowing creation of multiple bus endpoints
to the same bus that carry additional, more restrictive policy.

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