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:	Mon, 27 Apr 2015 17:50:12 +0200
From:	David Herrmann <dh.herrmann@...il.com>
To:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Cc:	Andy Lutomirski <luto@...capital.net>,
	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)

Hi

On Mon, Apr 27, 2015 at 4:57 PM, One Thousand Gnomes
<gnomes@...rguk.ukuu.org.uk> wrote:
>> But this is not how authorization with polkit works (or anything
>> similar to polkit). The authorization-framework is totally separated
>
> Thats a detail which is changeable

It's not a detail, it's a design choice. But see at the end..

>> from the client that accesses a service. The client asks a service
>> provider to perform an action. The service provider then asks the
>> authorization-framework, whether the client is authorized to run the
>> action.
>
> This is not good design IMHO. The client should always be indicating it
> intends to pass on the credentials it has. That stops privileges leaking
> or programs being tricked into things.

If all you pass along is your identity, you cannot "leak a privilege".
If you run a program as someone privileged and you don't want the
program to run as such a user, well, then you better not run it as
such a user..

We don't do setuid or setcap. A caller always has full control who to
run a program as. Choose that wisely, don't make the program protect
itself against the user. On the contrary, if a program is called with
elevated privileges, then this is an explicit decision of the caller
we must respect.

>> The authorization-framework is explicitly separated from
>> credential-passing. It has a separate configuration that is neither
>> controlled by the client nor the service-provider (the default is
>> usually provided by the latter, though). Therefore, credentials that
>> are passed are not associated with an action, but rather with the
>> identity of the client. If a client does not want to run an operation
>> as its current identity, it better does not call it.
>
> You still want such a usage to involve a client sending a message flag
> which says "and this message is an authority to use the following
> credential". [...]

No, I really don't.

>> Without LSM, we don't have such a unique identifier. Therefore, we
>> send the UIDs+GIDs+CAPs+NAMEs combination. Those we pass on to the
>> authorization framework, to decide on whether the peer is privileged.
>> And we believe those should be mandatory, not optional, just like the
>> seclabel we send if an LSM is active.
>
> The mashed up caps and names really ought to be replaced by something
> better. Especially the names. Would it make sense to put some kind of
> security label on the executable and pass that instead ? So instead of
> all the caps and names crap you label the executable itself as having
> "kbus:awesomerebootpower" or whatever so the kernel can see that cleanly
> as a label that's basically a kbus namespace capability ?

(it would be lovely if you did not call my code 'crap')

But this is the essential difference in our design. We don't want code
to be aware of their privileges. We want privileges to be attached
externally to an identity. Thus, a program should always assume it is
privileged to do whatever its purpose is. If its purpose does not fit
you, you better not call it. In all other cases, a "privilege leak"
would just result in the program running as expected.

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/