linux-kernel - Re: Sharing credentials in general (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:	Fri, 1 May 2015 18:48:02 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	David Herrmann <dh.herrmann@...il.com>
Cc:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Tom Gundersen <teg@...m.no>, Jiri Kosina <jkosina@...e.cz>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Daniel Mack <daniel@...que.org>,
	Djalal Harouni <tixxdz@...ndz.org>
Subject: Re: Sharing credentials in general (Re: [GIT PULL] kdbus for 4.1-rc1)

On Mon, Apr 27, 2015 at 9:33 AM, David Herrmann <dh.herrmann@...il.com> wrote:
> On Mon, Apr 27, 2015 at 6:13 PM, Andy Lutomirski <luto@...capital.net> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/