Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752150Ab0DVE50 (ORCPT ); Thu, 22 Apr 2010 00:57:26 -0400 Received: from mail-pz0-f194.google.com ([209.85.222.194]:51881 "EHLO mail-pz0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751294Ab0DVE5Y convert rfc822-to-8bit (ORCPT ); Thu, 22 Apr 2010 00:57:24 -0400 MIME-Version: 1.0 In-Reply-To: References: <20100421012749.GA21338@us.ibm.com> <20100421012908.GB24251@us.ibm.com> <20100421102739.6ad932fb@lxorguk.ukuu.org.uk> <20100421133917.GB16326@us.ibm.com> <20100421151917.5ae20265@lxorguk.ukuu.org.uk> <20100421150900.GB31880@us.ibm.com> From: Kyle Moffett Date: Thu, 22 Apr 2010 00:57:03 -0400 Message-ID: Subject: Re: [PATCH 3/3] p9auth: add p9auth driver To: "Eric W. Biederman" Cc: "Serge E. Hallyn" , Alan Cox , lkml , David Howells , Ashwin Ganti , Greg KH , rsc@swtch.com, ericvh@gmail.com, linux-security-module@vger.kernel.org, Ron Minnich , jt.beard@gmail.com, Andrew Morton , Andrew Morgan , oleg@us.ibm.com, Eric Paris , linux-api@vger.kernel.org, Randy Dunlap Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3091 Lines: 70 On Wed, Apr 21, 2010 at 15:15, Eric W. Biederman wrote: > "Serge E. Hallyn" writes: > >> Ignoring namespaces for a moment, I guess we could do something like >> >> struct credentials_pass { >>       pid_t global_pid; >>       unsigned long unique_id; >>       uid_t new_uid; >>       gid_t new_gid; >>       int num_aux_gids; >>       gid_t aux_gids[]; >> } > > This looks surprising like what I am doing in passing uids and pids > through unix domain sockets. > > So if this looks like a direction we want to go it shouldn't be too > difficult. Hmm... for an alternative idea: We have this nice "kernel keyring" infrastructure that lets us stuff arbitrary things into "keys" and grant/revoke them between processes. What if we created a relatively generic way for processes to package up privileges (of whatever form) into a "key" that could be granted to another process (via UNIX-domain socket)? Then the other process would use a setuid()-ish syscall which would instead apply a specific key as your credentials, possibly including the audit context and/or namespaces it came from. By using the keyring system, such tokens could be kept around across multiple processes easily (as opposed to FDs), in the same style as a "sudo" ticket file, for example (even with an expiration time). Types of credentials you could pass around: * Capabilities * Filesystem UID/GID in a particular UID namespace (for FS operations) * Process UID/GID in a particular UID namespace (for kill(), etc) * Audit contexts * SELinux/etc security labels All of the above could be optionally limited to effectively require a bprm-secure-style exec() with specific args. So for example, instead of making "/usr/sbin/passwd" a setuid program, you could make it be an unprivileged helper. It would connect to a privileged daemon and ask for a password-change cookie for that particular user. The daemon would create what is essentially a "delayed exec" key which grants a specific UID and capabilities when that process performs an execkey(). So as an example, you could rewrite "sudo" as a partially-privileged daemon and an unprivileged helper. The unpriv helper would send across a request (optionally including the command and environment) which would be checked by the daemon. It would then issue a key to allow the unpriv helper to perform a limited exec. Another option would be to rewrite network login programs (eg OpenSSH) to use this for privilege separation. The listening process would get a non-expiring key to allow it to exec a partially-privileged password-checking program. If the password-checking program likes the password it generates a single-use key to pass back to the forked network process that allows it to exec a program as that user. Cheers, Kyle Moffett -- 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/