Message-ID: <CALCETrXxZxpnepu=5UqLqjirqCH6Wp9+4o2XZVarxy-s9he99g@mail.gmail.com>
Date:	Tue, 21 Apr 2015 11:25:30 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Daniel Mack <daniel@...que.org>
Cc:	James Bottomley <James.Bottomley@...senpartnership.com>,
	Havoc Pennington <hp@...ox.com>,
	David Herrmann <dh.herrmann@...il.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Kosina <jkosina@...e.cz>,
	Steven Rostedt <rostedt@...dmis.org>,
	John Stoffel <john@...ffel.org>,
	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>,
	Djalal Harouni <tixxdz@...ndz.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Subject: Re: [GIT PULL] kdbus for 4.1-rc1

On Tue, Apr 21, 2015 at 1:09 AM, Daniel Mack <daniel@...que.org> wrote:
> Hi,
>
> On 04/20/2015 08:01 PM, James Bottomley wrote:
>> On Fri, 2015-04-17 at 16:27 -0400, Havoc Pennington wrote:
>
>>> Do you have ideas on how to go about fixing it, whether in userspace
>>> or kernel dbus?
>>
>> Well, I've always suspected the solution would be for dbus to have a
>> hierarchical namespace of its own with the default policy be pass
>> message to parent namespace.  This would allow a container to determine
>> which services were serviced outside and which inside the container (if
>> you attach as a provider to the system bus in the container, that
>> attachment supersedes the parent).
>>
>> However, this doesn't solve the security problem: just because a
>> container hasn't attached an interior provider doesn't mean it should be
>> allowed complete access to all services provided from outside. This is
>> the nasty problem because it involves some type of filter on busses
>> which pass through containers.
>
> Fair point, we've been thinking about that as well. What we implemented
> for that is something we call 'custom endpoints', which is described in
> kdbus.endpoint(7).
>
> In short, an endpoint is an entry point to the bus. Each bus provides a
> default endpoint node that enforces the bus-wide policy rules that
> define which well-known names a peer may own, see, or talk to. Custom
> endpoints can be added to carry additional policy rules for peers
> connected through it, and redirecting a task or container to the custom
> endpoint instead of the default one is as easy as bind-mounting the
> node. systemd units actually have support for that since a while, which
> is how we tested this feature. This implementation doesn't even add much
> code to kdbus, because we do have the policy code around anyway, so
> that's just a matter of which policy database to look at during runtime.
>
> That said, it would actually even be easy to implement a way to allow
> overriding names on custom endpoints too, so that services inside a
> container can replace such that already exist on the bus. It's just that
> so far, we haven't yet seen a use case for this.

This is part of why I think that kdbus is the wrong design.  All of
this is great, but this is the kind of policy that IMO belongs in
userspace.  If nothing else, it means that you can add things like
this in the future without any kernel changes.

dbus-daemon can do all of this (in principle, anyway) already -- just
stick another dbus-daemon-like program in the container that proxies
things as appropriate.  I think that a good kernel-accelerated design
could do the same thing without having to put any of this type of
policy in the kernel.

(As an example, capability-based IPC gets all of this for free.)

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

Powered by blists - more mailing lists