linux-kernel - Re: [PATCH v4 00/14] Add kdbus implementation

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: <CANq1E4QSja-KhVL2p-d406uLJT600zMpK2UAcwsb0LkMwa8F7w@mail.gmail.com>
Date:	Fri, 3 Apr 2015 13:51:34 +0200
From:	David Herrmann <dh.herrmann@...il.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Tom Gundersen <teg@...m.no>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Jiri Kosina <jkosina@...e.cz>,
	Linux API <linux-api@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Daniel Mack <daniel@...que.org>,
	Djalal Harouni <tixxdz@...ndz.org>
Subject: Re: [PATCH v4 00/14] Add kdbus implementation

Hi

On Tue, Mar 31, 2015 at 8:29 PM, Andy Lutomirski <luto@...capital.net> wrote:
> On Tue, Mar 31, 2015 at 8:10 AM, Tom Gundersen <teg@...m.no> wrote:
>> On Tue, Mar 31, 2015 at 3:58 PM, Andy Lutomirski <luto@...capital.net> wrote:
>>>
>>> IOW you're taking something that you dislike aspects of and shoving
>>> most of it in the kernel.  That guarantees us an API in the kernel
>>> that even the creators don't really like.  This is, IMO, very
>>> unfortunate.
>>
>> This is a misrepresentation of what David wrote. We do want this API
>> regardless of dbus1 compatibility, but compatibility is by itself a
>> sufficient motivation. A further motivation is reliable introspection,
>> since this meta-data allows listing current peers on the bus and
>> showing their identities. That's hugely useful to make the bus
>> transparent to admins.
>
> I've heard the following use cases for per-connection metadata:
>
>  - Authenticating to dbus1 services.

Not necessarily authentication, but we need to support the legacy API,
for whatever reason it was used by old applications. But..

>  - Identifying connected users for admin diagnostics.
>
> I've heard the following use cases for per-message metadata:
>
>  - Logging.
>
>  - Authenticating to kdbus services that want this style of authentication.

..please note that authentication on DBus has always been done with
per-message metadata (see polkit history). However, this had to be
reverted some years ago as it is racy (it used /proc for that, which
can be exploited by exec'ing setuid binaries). However, the
per-message metadata authentication worked very well for _years_
(minus the race..), so this is already a well-established scheme. With
kdbus we can finally implement this in a race-free manner.

[...]
> This is simply not okay for a modern interface, and in my opinion the
> kernel should not carry code to support new APIs with weakly defined
> security semantics.  It's important that one be able to tell what the
> security implications of one's code is without cross-referencing with
> the implementation of the server's you're interacting with.

Again, I disagree. Our concepts are established and used on UDS and
DBus for decades.

Yes, we provide two ways to retrieve metadata, but the kernel offers
several more paths to gather that information. Just because those APIs
are available does not mean they should be used for authentication. We
mandate per-message metadata. If applications use per-connection
metadata, /proc, netlink, or random data, they're doing it wrong.

Furthermore, dbus provides pretty complete and straightforward
libraries which hide that from you. If you use glib, qt or sd-bus, you
don't even need to deal with all that.

> To top that off, the kdbus policy mechanism has truly bizarre effects
> with respect to services that have unique ids and well-known names.
> That, too, is apparently for compatibility.
>
> This all feels to me like a total of about four people are going to
> understand the tangle that is kdbus security, and that's bad.  I think
> that the kernel should insist that new security-critical mechanisms
> make sense and be hard to misuse.  The current design of kdbus, in
> contrast, feel like it will be very hard to use correctly.

Native kdbus clients are authenticated with their credentials at time
of method call. Legacy clients will always have their credentials at
time of connect in effect. No fallbacks, no choices. It's a simple
question whether it's a legacy client or not.
Sounds simple to me.

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