From mboxrd@z Thu Jan 1 00:00:00 1970 From: Trond Myklebust Subject: Re: Thoughts on credential switching Date: Mon, 31 Mar 2014 16:14:33 -0400 Message-ID: <3E5CB7F4-0CB6-4D50-85DC-D19FC47FCBD8@primarydata.com> References: <20140326194847.0e994d0b@ipyr.poochiereds.net> <20140326202535.7d9b6f78@ipyr.poochiereds.net> <20140327070802.124fb34c@ipyr.poochiereds.net> <20140330130328.GB7172@thunk.org> <20140331075145.4bd76872@tlielax.poochiereds.net> <58D59025-ADA1-44CB-88E4-36BCEE763B64@primarydata.com> Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Layton Jeff , Theodore Ts'o , Jim Lieb , "Eric W. Biederman" , LSM List , "Serge E. Hallyn" , Kees Cook , Linux FS Devel , "linux-kernel@vger.kernel.org" , Dr Fields James Bruce To: Andy Lutomirski Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Mar 31, 2014, at 15:26, Andy Lutomirski wrote: > On Mon, Mar 31, 2014 at 11:06 AM, Trond Myklebust > wrote: >>=20 >> On Mar 31, 2014, at 7:51, Jeff Layton wrote: >>=20 >>> On Sun, 30 Mar 2014 09:03:29 -0400 >>> "Theodore Ts'o" wrote: >>>=20 >>>> On Thu, Mar 27, 2014 at 07:08:02AM -0700, Jeff Layton wrote: >>>>> I had some time to think about this last night... >>>>>=20 >>>>> While using a fd to pass around credentials is convenient, the da= nger >>>>> is that it's pretty opaque. You have a fd that you know has creds >>>>> attached to it, but it's hard to be certain what is going to chan= ge. >>>>=20 >>>> I don't think that's a particularly tough problem. In general, th= e fd >>>> isn't something that you would want to pass around, and so the pro= cess >>>> which generated it will know exactly what it contained. >>>>=20 >>>=20 >>> I think there's a bit more of a use-case for passing around such an= fd >>> via socket... >>>=20 >>> Part of the problem is that the traditional uid/gid switching glibc >>> wrappers are per-process. If we're proposing doing something like: >>>=20 >>> seteuid() >>> setegid() >>> setgroups() >>> fd =3D open() >>> (...and then revert the creds using same syscalls) >>>=20 >>> ...during the time that you're doing all of that, you can't really >>> allow any thread in the process to be doing something that requires >>> _other_ creds until you've completed the above. >>=20 >> Umm... open() isn't the only operation that you want to be able to d= o with an assumed user identity. You want mknod(), mkdir(), link(), unl= ink(), ... Pretty much any interaction with the underlying filesystem n= eeds to use the right identity. >>=20 >>> So, I could envision a program like ganesha firing up a separate >>> process to handle the credential switching and fd creation and then >>> handing those back to the main process via a unix domain socket. >>=20 >> How about using the keyrings interface to atomically cache and retri= eve these user identities? We already have support for different types = of keys that store/retrieve different types of structured information. = How is this so different? >=20 > This sounds considerably more complicated than just using fds. What'= s > the advantage? The advantage is that it=92s considerably _less_ complicated because it= uses interfaces that were designed to carry security related informati= on, and to share them across threads. > I guess using keys for local fs credentials fits in with using keys t= o > access things like AFS, but I'm still not sure I see why this helps > here. All you want to do is atomically store and retrieve a user identity (in= practice a credential) and share it between members of a thread. As I = said, that kind of storage/retrieval of structured data is what keyring= s do. As far as I know, there are already LSM interfaces in place (see = security_key_alloc/permission/free), and the generic keyring/keyctl int= erface exists with appropriate process sharing/inheritance rules via th= e kernel keyring interface. So basically, the recipe is: - You set up a kernel key type that takes a reference to the current pr= ocess credential on instantiation (no upcalls, etc needed). Ganesha can= then use standard libkeyutils methods to create the key and store it i= n its user, process or thread keyring. - You add a new keyctl (KEYCTL_APPLY?) that enables any thread/process = that has access to the key, via the keyring in which it is stored, to a= pply the stored process credential to itself (and perhaps cache it=92s = old credential in a new key?). _________________________________ Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@primarydata.com