From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753996AbaCaKpV (ORCPT ); Mon, 31 Mar 2014 06:45:21 -0400 Received: from lxorguk.ukuu.org.uk ([81.2.110.251]:55054 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753467AbaCaKpS (ORCPT ); Mon, 31 Mar 2014 06:45:18 -0400 Date: Mon, 31 Mar 2014 11:44:59 +0100 From: One Thousand Gnomes To: Andy Lutomirski Cc: Jim Lieb , "Eric W. Biederman" , LSM List , "Serge E. Hallyn" , Kees Cook , Linux FS Devel , "Theodore Ts'o" , "linux-kernel@vger.kernel.org" , bfields@redhat.com, Jeff Layton Subject: Re: Thoughts on credential switching Message-ID: <20140331114459.4b3638f8@alan.etchedpixels.co.uk> In-Reply-To: References: Organization: Intel Corporation X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.20; x86_64-pc-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 On Wed, 26 Mar 2014 17:23:24 -0700 Andy Lutomirski wrote: > Hi various people who care about user-space NFS servers and/or > security-relevant APIs. > > I propose the following set of new syscalls: > > int credfd_create(unsigned int flags): returns a new credfd that > corresponds to current's creds. > > int credfd_activate(int fd, unsigned int flags): Change current's > creds to match the creds stored in fd. To be clear, this changes both > the "subjective" and "objective" (aka real_cred and cred) because > there aren't any real semantics for what happens when userspace code > runs with real_cred != cred. What is the sematic of a simultaneous ptrace racing a credfd_activate on another processor core ? What are the rules for simultaneous threads doing I/O and and credential changes ? What is the rule for a faulting of an mmapped page in a multithreaded app one thread of which has changed credentials ? Who owns a file created while you are changing credentials ? > - credfd_activate fails (-EINVAL) if dumpable. This is because we > don't want a privileged daemon to be ptraced while impersonating > someone else. That's one of the obvious problems but if you have that problem then you've got races against signals and ptrace etc to deal with. One way to implement it I think safely but which requires a fair bit more work elsewhere is to apply the debug and signal type checks as 'you may only do X if you also posess the right to do so for *all* credentials accessible to this task' which I think is the correct logical check. Alan