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:	Mon, 20 Apr 2015 11:01:42 -0700
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	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>,
	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

On Fri, 2015-04-17 at 16:27 -0400, Havoc Pennington wrote:
> Hi,
> 
> On Fri, Apr 17, 2015 at 3:27 PM, James Bottomley
> <James.Bottomley@...senpartnership.com> wrote:
> >
> > This is why I think kdbus is a bad idea: it solidifies as a linux kernel
> > API something which runs counter to granular OS virtualization (and
> > something which caused Windows to fall behind Linux in the container
> > space).  Splitting out the acceleration problem and leaving the rest to
> > user space currently looks fine because the ideas Al and Andy are
> > kicking around don't cause problems with OS virtualization.
> >
> 
> I'm interested in understanding this problem (if only for my own
> curiosity) but I'm not confident I understand what you're saying
> correctly.
> 
> Can I try to explain back / ask questions and see what I have right?
> 
> I think you are saying that if an application relies on a system
> service (= any other process that runs on the system bus) then to
> virtualize that app by itself in a dedicated container, the system bus
> and the system service need to also be in the container. So the
> container ends up with a bunch of stuff in it beyond only the
> application.  Right / wrong / confused?

Right.  Consider named as the unix equivalent.  In most application
containers, it's provided from outside.  However, any container that
wants it provided inside simply intercepts and overrides the well known
socket.  We can do this in UNIX because there's no global bus handling
these queries, it's simply a matter of knowing where the socket is.  In
windows you can't pick and choose the services you consume from outside.
Either you pull the whole OLE namespace into the container, and thus
have to provide everything from within, or try to run with none of it
provided by the container.  It's this everything or nothing that's the
problem.  Container virtualisation is about being granular and a system
bus (or global OLE namespace) is about being monolithic.

> I also think you're saying that userspace dbus has the same issue
> (this isn't a userspace vs. kernel thing per se), the objection to
> kdbus is that it makes this issue more solidified / harder to fix?

Yes, it does.  We have problems containerising Linux desktops as well.
However, most of our server stuff is daemon and socket based, so that
containerises nicely.  In windows, OLE has been absorbed even into the
server model which is why they have a bigger problem.

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

James

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