From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753502AbaCaSNN (ORCPT ); Mon, 31 Mar 2014 14:13:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38796 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753299AbaCaSNK (ORCPT ); Mon, 31 Mar 2014 14:13:10 -0400 Date: Mon, 31 Mar 2014 14:12:55 -0400 From: Jeff Layton To: Trond Myklebust Cc: "Theodore Ts'o" , Andy Lutomirski , Jim Lieb , "Eric W. Biederman" , LSM List , "Serge E. Hallyn" , Kees Cook , Linux FS Devel , "linux-kernel@vger.kernel.org" , Dr Fields James Bruce Subject: Re: Thoughts on credential switching Message-ID: <20140331141255.008e2b4a@tlielax.poochiereds.net> In-Reply-To: <58D59025-ADA1-44CB-88E4-36BCEE763B64@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 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 31 Mar 2014 14:06:01 -0400 Trond Myklebust wrote: > > On Mar 31, 2014, at 7:51, Jeff Layton wrote: > > > On Sun, 30 Mar 2014 09:03:29 -0400 > > "Theodore Ts'o" wrote: > > > >> On Thu, Mar 27, 2014 at 07:08:02AM -0700, Jeff Layton wrote: > >>> I had some time to think about this last night... > >>> > >>> While using a fd to pass around credentials is convenient, the danger > >>> 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 change. > >> > >> I don't think that's a particularly tough problem. In general, the fd > >> isn't something that you would want to pass around, and so the process > >> which generated it will know exactly what it contained. > >> > > > > I think there's a bit more of a use-case for passing around such an fd > > via socket... > > > > Part of the problem is that the traditional uid/gid switching glibc > > wrappers are per-process. If we're proposing doing something like: > > > > seteuid() > > setegid() > > setgroups() > > fd = open() > > (...and then revert the creds using same syscalls) > > > > ...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. > > Umm… open() isn’t the only operation that you want to be able to do with an assumed user identity. You want mknod(), mkdir(), link(), unlink(), … Pretty much any interaction with the underlying filesystem needs to use the right identity. > The proposal that Al originally had was to have userland set up the credentials that it wanted to use, and then open("/dev/null", ...) to get a fd that has those creds attached. Then, we'd add a syscall that takes such an fd and switches to the creds attached to it. So the open() in the above example isn't to do an actual operation but rather to create a fd to act as a credential "handle". > > 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. > > How about using the keyrings interface to atomically cache and retrieve 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? > That's an interesting idea. -- Jeff Layton From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Layton Subject: Re: Thoughts on credential switching Date: Mon, 31 Mar 2014 14:12:55 -0400 Message-ID: <20140331141255.008e2b4a@tlielax.poochiereds.net> 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 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: "Theodore Ts'o" , Andy Lutomirski , 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: Trond Myklebust Return-path: In-Reply-To: <58D59025-ADA1-44CB-88E4-36BCEE763B64@primarydata.com> Sender: linux-security-module-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Mon, 31 Mar 2014 14:06:01 -0400 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=85 open() isn=92t the only operation that you want to be able to = do with an assumed user identity. You want mknod(), mkdir(), link(), un= link(), =85 Pretty much any interaction with the underlying filesystem = needs to use the right identity. >=20 The proposal that Al originally had was to have userland set up the credentials that it wanted to use, and then open("/dev/null", ...) to get a fd that has those creds attached. Then, we'd add a syscall that takes such an fd and switches to the cred= s attached to it. So the open() in the above example isn't to do an actua= l operation but rather to create a fd to act as a credential "handle". > > 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 retrie= ve these user identities? We already have support for different types o= f keys that store/retrieve different types of structured information. H= ow is this so different? >=20 That's an interesting idea.=20 --=20 Jeff Layton -- To unsubscribe from this list: send the line "unsubscribe linux-securit= y-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html