On Mon, Jan 10, 2011 at 3:45 PM, Roman Shtylman <shtylman@xxxxxxxxxxxx> wrote: > > On Monday, January 10, 2011 03:35:04 pm Jeff Layton wrote: >> On Mon, 10 Jan 2011 14:55:30 -0500 >> >> Roman Shtylman <shtylman@xxxxxxxxxxxx> wrote: >> > I have setup nfs4 with krb5 server and successfully mounted a client. Two >> > people can log into the client box and both access their respective >> > shares and not each other's. However, when one user (who lets say has >> > root privs) uses root to become the second user (using su) then that >> > user can now access the info of the user he became. >> > >> > I was under the impression that this should not be possible as the >> > tickets for access should still be tied to the first user they logged in >> > as. Is this true? Or do I have an error in my setup? >> > >> > Process: >> > Login as user A >> > (User B logs into the machine from another terminal) >> > sudo su B (to become user B on the machine) >> > <can now edit files which belong to B> >> >> That's correct, or is at least in accordance with the design. The >> credcache is (usually) a file in /tmp. The kernel has to upcall to >> userspace for that information. To do that, it passes along the uid of >> the owner of the credcache. I think this is governed by the fsuid. >> >> When you "su" to another user, all of the uid's associated with the >> process are changed (real, effective, fs and saved). So, the uid passed to >> the upcall in this case is B's and not A's. >> >> This could potentially be "fixable" by moving the krb5 credcache into >> the per-session keyring and then teach nfs to do keys API upcalls to get >> the right blob. Not a trivial project, but it's doable. This is >> something that would be nice for CIFS and maybe AFS too. > > AFS does not have this behavior. > > What is a best practice for handling this situation? Prevent "untrusted" > machines from connecting to the nfs server? Basically any machine where a > normal user can become root would be a potential problem? > > Thanks for the quick response. > > cheers, > ~Roman AFS uses a Process Authentication Group (PAG) to segregate use of credentials in the kernel. As far as I know, this doesn't prevent a user with root access on the "untrusted" machine from impersonating another user on the machine. (They can simply copy any existing kerberos credentials for use in their PAG.) I think it does prevent "accidental" use of the other user's credentials in this kind of situation. -- 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
