Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965015AbbD0O6K (ORCPT ); Mon, 27 Apr 2015 10:58:10 -0400 Received: from 251.110.2.81.in-addr.arpa ([81.2.110.251]:57811 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964784AbbD0O6H (ORCPT ); Mon, 27 Apr 2015 10:58:07 -0400 Date: Mon, 27 Apr 2015 15:57:32 +0100 From: One Thousand Gnomes To: David Herrmann Cc: Andy Lutomirski , Linus Torvalds , Greg Kroah-Hartman , Andrew Morton , Arnd Bergmann , "Eric W. Biederman" , Tom Gundersen , Jiri Kosina , "linux-kernel@vger.kernel.org" , Daniel Mack , Djalal Harouni Subject: Re: Sharing credentials in general (Re: [GIT PULL] kdbus for 4.1-rc1) Message-ID: <20150427155732.7e2fdbd4@lxorguk.ukuu.org.uk> In-Reply-To: References: Organization: Intel Corporation X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2316 Lines: 47 > 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 > 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. > 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". Given the daemon the other end already has the rights to perform the action the daemon can presumably be trusted to remember to check. > 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 ? Alan -- 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/