Message-ID: <CALCETrU9nzyZf82jhVqOwGujBdeQqUTjVx3i_dFWUMyAnrR3Yw@mail.gmail.com>
Date:	Mon, 31 Mar 2014 14:25:46 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Trond Myklebust <trond.myklebust@...marydata.com>
Cc:	Layton Jeff <jlayton@...hat.com>, "Theodore Ts'o" <tytso@....edu>,
	Jim Lieb <jlieb@...asas.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	LSM List <linux-security-module@...r.kernel.org>,
	"Serge E. Hallyn" <serge@...onical.com>,
	Kees Cook <keescook@...omium.org>,
	Linux FS Devel <linux-fsdevel@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Dr Fields James Bruce <bfields@...hat.com>
Subject: Re: Thoughts on credential switching

On Mon, Mar 31, 2014 at 1:14 PM, Trond Myklebust
<trond.myklebust@...marydata.com> wrote:
>
> On Mar 31, 2014, at 15:26, Andy Lutomirski <luto@...capital.net> wrote:
>
>> On Mon, Mar 31, 2014 at 11:06 AM, Trond Myklebust
>> <trond.myklebust@...marydata.com> wrote:
>>>
>>> On Mar 31, 2014, at 7:51, Jeff Layton <jlayton@...hat.com> wrote:
>>>
>>>> On Sun, 30 Mar 2014 09:03:29 -0400
>>>> "Theodore Ts'o" <tytso@....edu> 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.
>>>
>>>> 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?
>>
>> This sounds considerably more complicated than just using fds.  What's
>> the advantage?
>
> The advantage is that it's considerably _less_ complicated because it uses interfaces that were designed to carry security related information, and to share them across threads.
>
>> I guess using keys for local fs credentials fits in with using keys to
>> 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 keyrings do. As far as I know, there are already LSM interfaces in place (see security_key_alloc/permission/free), and the generic keyring/keyctl interface exists with appropriate process sharing/inheritance rules via the kernel keyring interface.
>
> So basically, the recipe is:
>
> - You set up a kernel key type that takes a reference to the current process credential on instantiation (no upcalls, etc needed). Ganesha can then use standard libkeyutils methods to create the key and store it in 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 apply the stored process credential to itself (and perhaps cache it's old credential in a new key?).

I can see pros and cons of using keys instead of fds:

Pros:
 - You can change may_ptrace to check that you can legally ptrace any
creds in the keyring.  (It's debatable how useful this is.)
 - You could plausibly stick subsidiary uids into a user keyring and
use them for uid_map, removing the need for newuidmap.

Cons:
 - You can't send them via SCM_RIGHTS.  I still think that the ability
to do that is extremely useful.

Neutral: What happens if the filesystem you're trying to share
requires keys?  I don't think that credfd or credkeys can really do
this.  I suppose that if the keys live in the user keyring
corresponding to the user being impersonated, everything just works
regardless of how this is implemented.

Cue brain explosion: thread_keyring lives inside struct cred.  I
suspect that any sane implementation of credential switching will need
to change that.  Sigh.


Anyway, the actual parts that seem like they need solving one way or
another are:

 - The keyring pointers in struct cred are a problem.  (Solved with
credkeys, but only if credkeys can only live on the thread keyring.
Also, there will be a problem with circular references.)

 - may_ptrace and all its users (e.g. procfs).  "Solved" by
real_creds, but no one has really defined the semantics of real_creds,
since it's not currently available to userspace.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists