linux-kernel - Re: Issues with capability bits and meta-data in kdbus

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: <CA+55aFzL22XjeyPuapc+mYe1fEco8ZY7doJzSF9vPLwGU9taXA@mail.gmail.com>
Date:	Tue, 21 Apr 2015 19:32:42 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Tom Gundersen <teg@...m.no>, Jiri Kosina <jkosina@...e.cz>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Daniel Mack <daniel@...que.org>,
	David Herrmann <dh.herrmann@...il.com>,
	Djalal Harouni <tixxdz@...ndz.org>
Subject: Re: Issues with capability bits and meta-data in kdbus

On Tue, Apr 21, 2015 at 6:54 PM, Andy Lutomirski <luto@...capital.net> wrote:
>
> If kdbus were a general purpose IPC tool

 .. but it's not ..

>                                     and if the libraries would
> expose nice knobs like "set this flag if and only if you want to
> assert CAP_WHATEVER to the server", then maybe this would be okay.

I really don't agree.

The whole notion that you should be able to be anonymous when
communicating is *wrong*.

Now, when you talk across machines using TCP, there's no identity that
you can trust, so anonymity is kind of enforced. But locally, if you
want to connect with somebody else, I actually think that tryin gto be
anonymous is just stupid - and more than that - plain wrong.

Yeah, if you do a pipe, that's one thing. You don't "connect" to
somebody else with a pipe, you just create both end points. So there
is little point in having identifying information for pipes. But when
you connect to a service, it just *makes sense* for the other end to
know about you. They should know your user ID, they should know your
identity (pid or whatever), and they should know your capabilities.

If you don't want that, then you use some anonymizing service, and it
because *your* problem. But a server that gets connected by different
people should know who it gets connected by.

Unix domain sockets simply got this wrong.

I don't think thi sis the problem of kdbus. There may be *other&*
problems, but I think it's very reasonable to just have as a basic
*requirement* that when you get connected, you get to know who
connects you, and what their rights are. Because it really *is*
something fundamental, and something important to know. Is it some
random nobody, or is it a system service?

If I was a service writer, that would be *the* most basic requirement
I would have. No ifs, buts or maybes about it.

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