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]
Message-ID: <553605BE.80801@zonque.org>
Date:	Tue, 21 Apr 2015 10:09:34 +0200
From:	Daniel Mack <daniel@...que.org>
To:	James Bottomley <James.Bottomley@...senPartnership.com>,
	Havoc Pennington <hp@...ox.com>
CC:	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>,
	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>,
	Djalal Harouni <tixxdz@...ndz.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Subject: Re: [GIT PULL] kdbus for 4.1-rc1

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@...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

Powered by Openwall GNU/*/Linux Powered by OpenVZ