Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751548AbbEBBs1 (ORCPT ); Fri, 1 May 2015 21:48:27 -0400 Received: from mail-lb0-f178.google.com ([209.85.217.178]:35754 "EHLO mail-lb0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750785AbbEBBsY (ORCPT ); Fri, 1 May 2015 21:48:24 -0400 MIME-Version: 1.0 In-Reply-To: References: <20150427155732.7e2fdbd4@lxorguk.ukuu.org.uk> From: Andy Lutomirski Date: Fri, 1 May 2015 18:48:02 -0700 Message-ID: Subject: Re: Sharing credentials in general (Re: [GIT PULL] kdbus for 4.1-rc1) To: David Herrmann Cc: One Thousand Gnomes , Linus Torvalds , Greg Kroah-Hartman , Andrew Morton , Arnd Bergmann , "Eric W. Biederman" , Tom Gundersen , Jiri Kosina , "linux-kernel@vger.kernel.org" , Daniel Mack , Djalal Harouni Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2852 Lines: 62 On Mon, Apr 27, 2015 at 9:33 AM, David Herrmann wrote: > On Mon, Apr 27, 2015 at 6:13 PM, Andy Lutomirski wrote: >> 2. This is a nice thought, but it doesn't work in practice. Sorry. >> I can give you a big pile of CVEs from last year if you like, or I can >> try explaining again. >> >> The issue boils down to what type of privileges you want to assert and >> over what object you want to assert them. Suppose I have a method >> "write". When I call it, I do Write(destination, text). In your >> model, it's basically never safe to do: > > You're correct. So don't create such APIs. > In fact, never ever accept FDs or file-paths from a less privileged > caller. It might be FUSE backed and under their full control. Really? So writing to stdout is not okay? So what if it's on FUSE? At worst it should be a DoS, unless you screw up the security model (as the kernel did) and it's privilege escalation or system state corruption. How about privileged services that mediate interactions between client-provided objects and other client-inaccessible things? FWIW, all these threads seem to have spawned tons on comparisons between dbus, COM, Binder, etc. I don't know too much about all of these technologies, but one difference springs to mind. COM and Binder both have very clear concepts of capability-passing. COM calls it "marshalling an interface". Binder calls it "IBinder". Quoting from the reference [1]: The data sent through transact() is a Parcel, a generic buffer of data that also maintains some meta-data about its contents. The meta data is used to manage IBinder object references in the buffer, so that those references can be maintained as the buffer moves across processes. Wikipedia suggests CORBA has "objects by reference". I think that Wayland's "new_id" type is effectively an object reference. I have no clue what Mac OS X and iOS do. AFAICT D-Bus is completely missing any corresponding concept. I'm rather confused how Samsung thinks they can cleanly layer Binder over kdbus unless they use kdbus as a completely dumb transport and implement object references in userspace. If they do that, then I don't see the point of using kdbus at all -- sockets would be fine. One can certainly debate the merits of capability-based security, but I've (so far) never heard anyone claim that passing object references around is a bad idea. Havoc, am I missing something here? If I'm right about this aspect of D-Bus, then I'm a bit surprised. [1] http://developer.android.com/reference/android/os/IBinder.html --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/