Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932083AbbDUIJn (ORCPT ); Tue, 21 Apr 2015 04:09:43 -0400 Received: from svenfoo.org ([82.94.215.22]:55429 "EHLO mail.zonque.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753154AbbDUIJj (ORCPT ); Tue, 21 Apr 2015 04:09:39 -0400 Message-ID: <553605BE.80801@zonque.org> Date: Tue, 21 Apr 2015 10:09:34 +0200 From: Daniel Mack User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: James Bottomley , Havoc Pennington CC: David Herrmann , Greg Kroah-Hartman , Jiri Kosina , Steven Rostedt , John Stoffel , Andy Lutomirski , Linus Torvalds , Andrew Morton , Arnd Bergmann , "Eric W. Biederman" , One Thousand Gnomes , Tom Gundersen , "linux-kernel@vger.kernel.org" , Djalal Harouni , "Paul E. McKenney" Subject: Re: [GIT PULL] kdbus for 4.1-rc1 References: <20150413190350.GA9485@kroah.com> <20150413204547.GB1760@kroah.com> <20150414175019.GA2874@kroah.com> <20150414192357.GA6107@kroah.com> <21805.29994.968937.364993@quad.stoffel.home> <20150414215135.GC6801@home.goodmis.org> <20150415083714.GD16381@kroah.com> <1429121536.2187.44.camel@HansenPartnership.com> <1429298858.1079.22.camel@HansenPartnership.com> <1429552902.2222.51.camel@HansenPartnership.com> In-Reply-To: <1429552902.2222.51.camel@HansenPartnership.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2312 Lines: 51 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. Thanks, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/