On Thu, 11 Dec 2014 14:55:27 -0500 "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > On Thu, Dec 11, 2014 at 02:50:29PM -0500, Jeff Layton wrote: > > On Thu, 11 Dec 2014 14:32:40 -0500 > > "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > > > > > On Thu, Dec 11, 2014 at 06:45:37AM -0500, Jeff Layton wrote: > > > > For instance: module loading clearly needs to be done in the "context" > > > > of the canonical root init process. That's what call_usermodehelper was > > > > originally used for so we need to keep that ability intact. > > > > > > > > OTOH, keyring upcalls probably ought to be done in the context of the > > > > task that triggered them. Certainly we ought to be spawning them with > > > > the credentials associated with the keyring. > > > > > > Isn't the idmapping done as a keyring upcall? You don't want ordinary > > > users of the filesystem to be able to pollute the id<->name cache. > > > > > > > Yes, it is done as a keyring upcall. You wouldn't need to allow random > > users to pollute the cache. When you do a keys upcall the process gets > > an authorization key that allows it to instantiate the key. > > > > AFAIU, that's what guards against random processes polluting the > > keyring, not any particular capabilities or anything. > > That doesn't stop it from instantiating the key with the wrong > information. > I guess I'm unclear on the attack vector you're talking about. The difference is the credentials that we give the process when its run by call_usermodehelper. Why would it be inherently more secure for that to be given root credentials rather than something non-privileged? The only way you can add keys to a keyring you don't own is to have an authorization key, and that would only be given to the process that got spawned by the kernel. > > > And in the gssd case, userland doesn't just find the right cred, it also > > > does the rpcsec_gss context setup with the server. A random user of the > > > filesystem might not be able to do that part. > > > > > > > I don't see why not. We already do that today as an unprivileged user > > in gssd. process_krb5_upcall forks and changes identity before getting > > a ticket and setting up the context and then handing that back to the > > kernel. I don't think that requires any special privileges. > > Why couldn't you give a task access to an nfs filesystem but wall it off > in a network namespace where it doesn't even have access to the > interface that the mount was done over? > That's a pathological case. ;) I suppose you could do that, at which point you'd be screwed. That's the unfortunate side of having all of these disconnected types of namespaces. You can use these Lego bricks to build something either awesome or completely non-functional. I don't think we can really solve all possible use-cases since some of them are non-sensical anyway. I think all we can do is target the use-cases that we think make sense and take it from there. While we're on the subject, having the userland process establish the GSS context over an entirely separate connection is a hack anyway. We really ought to be doing that using the same connection. Simo had some arguments against that scheme a while back, but I don't recall the details -- seems like maybe it breaks channel bindings? While we're talking about rejiggering all of this, that would be a good thing to change as well. > (And similarly what's to guarantee that a user of the filesystem is > capable of doing the ldap calls you might need for idmapping?) > Yeah, that certainly could be a problem. I'm not sure we'd really want to do the idmapping upcalls as the user that triggered them in the case of the idmapper. Perhaps there ought to be a specific set of credentials associated with the keyring that the idmapper uses instead? Those don't necessarily need to be root creds of course. -- Jeff Layton <jlayton@xxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
