Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760297AbaJ3OAX (ORCPT ); Thu, 30 Oct 2014 10:00:23 -0400 Received: from mail-la0-f46.google.com ([209.85.215.46]:43645 "EHLO mail-la0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760179AbaJ3OAU (ORCPT ); Thu, 30 Oct 2014 10:00:20 -0400 MIME-Version: 1.0 In-Reply-To: References: <1414620056-6675-1-git-send-email-gregkh@linuxfoundation.org> <20141029231106.GB16548@kroah.com> <20141029234001.GB16520@kroah.com>

From: Andy Lutomirski Date: Thu, 30 Oct 2014 06:59:57 -0700 Message-ID: Subject: Re: [PATCH 00/12] Add kdbus implementation To: Tom Gundersen Cc: Greg Kroah-Hartman , Jiri Kosina , Linux API , "linux-kernel@vger.kernel.org" , John Stultz , Arnd Bergmann , Tejun Heo , Marcel Holtmann , Ryan Lortie , Bastien Nocera , David Herrmann , Djalal Harouni , Simon McVittie , Daniel Mack , "alban.crequy" , Javier Martinez Canillas Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 30, 2014 at 4:52 AM, Tom Gundersen wrote: > On 10/30/2014 12:55 AM, Andy Lutomirski wrote:> It's worth noting that: >> >> - Proper credential passing could be added to UNIX sockets, and we >> may want to do that anyway. Also, the current kdbus semantics seem to >> be "spew lots of credentials and other miscellaneous >> potentially-sensitive and sometime spoofable information all over the >> place", which isn't obviously an improvement. (This is fixable, but >> it will almost certainly not be compatible with current systemd kdbus >> code if fixed.) > > Care to elaborate on what you think is spoofable, and what needs to be fixed? cmd and comm are trivially replaceable by any sender. > > Anyway, the idea is that by simply connecting to the bus and sending a > message to some service, you implicitly agree to passing some metadata > along to the service (and to a lesser extent to the bus). It's not > that this information is leaked, or that the peer could actively > access any of the sender's private memory. To me, this smells like bad design. By using kdbus, I implicitly agree to send everyone my command line?!? If I'm in a cgroup that policy decrees should be privileged, then I should invoke that privilege by specifically asking, *at the time of capture*, to send that cgroup. Otherwise it becomes unclear what things convey privilege when, and that will lead immediately to incomprehensible security models, and that will lead to exploits. Sorry, but "implicitly agree" sounds a lot like using my esteemed cellphone carrier. When I use it, some argue that I implicitly agree to have my identity prepended to all outgoing HTTP requests. This is *not* a good thing. > Also note that this kind of > metadata information is also available via /proc/$PID, and via > SCM_CREDENTIALS/SO_PEERCRED and the socket seclabel APIs. Not if you have a sensible LSM policy or if you use hidepid. And, once you've fixed the namespacing issues, not if the sender and receiver are in different PID namespaces or if they don't have /proc mounted at all. > > When credential information is passed between processes of different > (PID) namespaces most of the attached metadata is suppressed. This is a bug. It prevents users from usefully sandboxing themselves in a kdbus world. If you create and enter a user namespace, then your outside identity (which should be unchanged) is suppressed. (Note that anything that captures credentials other than at open time is also an issue for sandboxes in the other direction: it may interfere with selective privilege dropping.) > This > isn't too different from how SCM_CREDENTIALS works, which will zero > out the bits it cannot translate as well. SCM_CREDENTIALS translates the translatable parts. > There are some major benefits regarding performance: > > * fewer userspace context switches. For a full-duplex method call it's > down from five to two: instead of sender -> dbus daemon -> service -> > dbus daemon -> sender it's just sender -> service -> sender. > * fewer message copies in userspace. For a full-duplex method call > it's down from eight to two: instead of copying the method call data > into a socket, out of a socket, into a socket, out of a socket, and > the same for the method reply, we just copy one message directly to > the receiver, and the reply back. > * generally fewer syscalls involved. A synchronous method call is now > doable in a single ioctl on the sender side. > * memfds can be used for transport purposes of larger payload. This > way, we can cover substantial payload sizes instead of just small > control messages, with no extra copies. kdbus, in its transport layer, > makes sure only sealed memfds are passed in as payload, so the sender > cannot modify the contents while the receiver is already parsing it. There should be a number measured in, say, nanoseconds in here somewhere. The actual extent of the speedup is unmeasurable here. Also, it's worth reading at least one of Linus' many rants about zero-copy. It's not an automatic win. --Andy -- 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/