Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932390AbbD0IRy (ORCPT ); Mon, 27 Apr 2015 04:17:54 -0400 Received: from mail-qc0-f169.google.com ([209.85.216.169]:36429 "EHLO mail-qc0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752696AbbD0IRu (ORCPT ); Mon, 27 Apr 2015 04:17:50 -0400 MIME-Version: 1.0 In-Reply-To: References: Date: Mon, 27 Apr 2015 10:17:49 +0200 Message-ID: Subject: Re: Sharing credentials in general (Re: [GIT PULL] kdbus for 4.1-rc1) From: David Herrmann To: Andy Lutomirski Cc: Linus Torvalds , Greg Kroah-Hartman , Andrew Morton , Arnd Bergmann , "Eric W. Biederman" , One Thousand Gnomes , Tom Gundersen , Jiri Kosina , "linux-kernel@vger.kernel.org" , Daniel Mack , Djalal Harouni Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2829 Lines: 56 Hi On Fri, Apr 24, 2015 at 12:08 AM, Andy Lutomirski 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/