Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964836AbbD0Qd1 (ORCPT ); Mon, 27 Apr 2015 12:33:27 -0400 Received: from mail-qk0-f178.google.com ([209.85.220.178]:36597 "EHLO mail-qk0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753044AbbD0QdZ (ORCPT ); Mon, 27 Apr 2015 12:33:25 -0400 MIME-Version: 1.0 In-Reply-To: References: <20150427155732.7e2fdbd4@lxorguk.ukuu.org.uk> Date: Mon, 27 Apr 2015 18:33:24 +0200 Message-ID: Subject: Re: Sharing credentials in general (Re: [GIT PULL] kdbus for 4.1-rc1) From: David Herrmann To: Andy Lutomirski Cc: One Thousand Gnomes , 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 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: 4239 Lines: 89 Hi On Mon, Apr 27, 2015 at 6:13 PM, Andy Lutomirski wrote: >>>> 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. > > Who is "you"? In the future universe where kdbus takes over as the > main way of doing privileged things, people most certainly will run > kdbus clients setuid or setcapped. They're free to do that. But they need to deal with the consequences. We encourage people not to do that. >>>> 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. >> > > Two answers: > > 1. This is severely inconsistent with other things I've heard recently > from the kdbus camp. Lennart wants clients to use caps and adjust > them. This would involve those clients being very much aware of their > privileges, and their privileges would not "be attached externally to > an identity". Please make sure you actually understand your security > model before you try to justify it. Granting an application a capability is not equivalent to the application being aware of that capability. In fact, I'd assert the application doesn't care at all whether it gains the privilege due to a capability or polkit. It's not hard-coded in the application, but the unit/polkit configurations. Exception obviously being if we directly access syscalls. > 2. This is a nice thought, but it doesn't work in practice. Sorry. > I can give you a big pile of CVEs from last year if you like, or I can > try explaining again. > > The issue boils down to what type of privileges you want to assert and > over what object you want to assert them. Suppose I have a method > "write". When I call it, I do Write(destination, text). In your > model, it's basically never safe to do: You're correct. So don't create such APIs. In fact, never ever accept FDs or file-paths from a less privileged caller. It might be FUSE backed and under their full control. 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/