Date:	Mon, 27 Apr 2015 10:17:49 +0200
From:	David Herrmann <dh.herrmann@...il.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	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>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	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 Fri, Apr 24, 2015 at 12:08 AM, Andy Lutomirski <luto@...capital.net> wrote:
> Enter kdbus.  We now have an unbounded number of possible kdbus calls,
> and somehow users are supposed to keep track of which privileges the
> hold affect which kdbus calls.  Either each method should document
> which privileges it looks at (and then carefully never change it or,
> if they do, carefully fix up the holes a la the setuid fixup) [3], or
> the library should just suck it up and make users assert privileges
> explicitly.

But this is not how authorization with polkit works (or anything
similar to polkit). The authorization-framework is totally separated
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. If yes, the action is performed. The client does not have to
know which "privileges" the service provider looks at. It's of no use
to them, they expect the call to succeed, otherwise they wouldn't call
it.

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.

Note that we use those implicit credentials for authorization _only_.
If an operation needs credentials for more than authorization (eg.,
creating a file as a given user), you better encode that in the
object-path (or a method parameter) and validate that the caller is
privileged to do this.

This is quite similar to LSM in general: a seclabel describes the
identity of a process/object, and the identity only. It does not tell
you whether you're allowed to perform an action. Instead, a separate
database maps your identity to your privileges. It's a single (or,
combined) label you pass along. You cannot split it nor choose to send
something else (or not send it at all). You always perform the action
as the identity you are.

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.

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/

Powered by blists - more mailing lists