On 6 Feb 2010, at 09:44, George Mamalakis wrote: > Rick Macklem wrote: >> >> >> On Fri, 5 Feb 2010, George Mamalakis wrote: >> >>> Dear all, >>> >>> I am running FBSD8-STABLE on an nfsv3 server and an nfsv3 client. My configuration is based on http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup. My goal is to share filesystems securely through kerberos authentication. Everything works fine, until I try to kdestroy my tickets or kinit to some other user, where the system insists to think that I am the user that initially obtained their ticket. To be more extensive, my story is as follows: >>> >> [good stuff snipped] >>> >>> >>> and both client and server have the correct entries about each other (and themselves) in their /etc/hosts, so heimdal works just fine. >>> >>> Both client and server have their respective keytabs stored in /etc/krb5.keytab, and I use two users in my example (that both exist in both systems with the same uid,gid): mamalos and testakis. >>> >> >> Unless you have applied the experimental patch, a keytab entry is >> meaningless in the client. Without that, it was assumed that "root" >> would never "kinit" as anyone. Basically, it was assumed that "root" >> would only do the mount and a user, like "mamalos" or "testakis" >> would be logged in and kinit'd as that user. >> >> The short answer is that any principal with TGT in the credentials >> cache for uid==N will be used to authenticate that user. Once >> authenticated, that "handle" for the user can be used until it >> expires (up to the server, but usually set to when the TGT that >> it found in the credential cache is due to expire). >> >>> So, when I mount the exported filesystem on the client giving: >>> >>> # mount -o nvfsv3,sec=krb5 server.example.com:/exports /mnt >>> # mount >>> /dev/da0s1a on / (ufs, local, soft-updates) >>> devfs on /dev (devfs, local, multilabel) >>> server.example.com:/exports on /mnt (nfs) >>> >>> and try to access the share: >>> # ls /mnt >>> ls: mnt: Permission denied >>> >>> I get the error I am expecting, since root does not have any kerberos tickets assigned, yet. Let's see what happens when I kinit as mamalos: >> >> Yep, as expected. >>> # klist >>> Credentials cache: FILE:/tmp/krb5cc_0 >>> Principal: mamalos_at_EXAMPLE.COM >>> >>> Issued Expires Principal >>> Feb 5 11:20:49 Feb 5 21:20:47 krbtgt/EXAPMLE.COM_at_EXAMPLE.COM >>> # ls -la /mnt/ >>> total 8 >>> drwxr-xr-x 4 root wheel - 512 4 Feb 19:03 ./ >>> drwxr-xr-x 21 root wheel - 512 3 Feb 11:27 ../ >>> drwx------ 2 mamalos wheel - 512 5 Feb 11:11 mamalos/ >>> drwx------ 2 testakis wheel - 512 4 Feb 19:06 testakis/ >>> # touch /mnt/mamalos/myfile >>> # ls -la /mnt/mamalos/myfile >>> rw-r--r-- 1 mamalos wheel - 0 5 Feb 11:22 /mnt/mamalos/myfile >>> >>> Which is the exact behavior that is expected. Now when I kdestroy: >>> # kdestroy >>> # klist >>> klist: No ticket file: /tmp/krb5cc_0 >>> # touch /mnt/mamalos/myfilethatshouldnotbe >>> # ls -la /mnt/mamalos/myfilethatshouldnotbe >>> -rw-r--r-- 1 mamalos wheel - 0 5 Feb 11:24 /mnt/mamalos/myfilethatshouldnotbe >>> >> >> Yes, this is a "bug/limitation" in the current implementation. I believe >> that "kdestroy" should do some sort of system call to inform the NFS >> client that "credentials for uid==N" should be invalidated. This is not >> implemented in FreeBSD8 (or Linux for that matter, last I checked). >> I don't know if dfr_at_ was planning on doing this and whether or not he >> thinks it is appropriate to do so? >> >> Without that implemented, the "handle" continues to work until the >> server expires it, normally when the TGT for "mamalos" would have >> expired if you hadn't kdestroy'd it. >> >>> And I can do everything in that share as if I were still mamalos, even though I kdestroyed my kerberos ticket. The same thing will happen even if I kinit to testakis after that. klist shows testakis' ticket this time, but I am not allowed to access (rwx) tetakis' files/folders, and I still have full control over mamalos' files and folders. >>> >>> In order to be able to do something as testakis, I have to unmount the share and remount it while having testakis' ticket (or having no ticket at all, and giving kinit testakis after mounting the share). >>> >> >> Actually, logging in as "testakis" should allow that user to access the >> mount as "testakis" once kinit'd as "testakis". The trick is that the >> credential cache entry needs to be in /tmp/krb5cc_N (where 'N' is the >> uid assigned to "testakis"). Same would apply to "mamalos" if that >> user were logged in with a non-0 uid. >> >>> I am not an NFS expert, but I suppose that this behavior is not the one to be expected, except if I am missing some fundamental information about kerberized NFS that explains it. Even so, it would be quite unwise to behave so, since even if the users kdestroys their tickets, they have still all permissions as when they obtained their ticket. >>> >> >> Yes, as noted above, I believe that "kdestroy" should get rid of the >> Kerberized NFS "handles" for the corresponding "uid". It's on my >> "to discuss with dfr and maybe do" list, but unfortunately not near >> the top of it. (I'd also like to come up with a good way to do >> initiator credentials from a keytab entry. The experimental patch >> is considered unacceptable for FreeBSD-current etc.) >> >> Hope that clarifies things, rick >> >> _______________________________________________ >> freebsd-stable_at_freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe_at_freebsd.org" >> > Rick, > > thank you for all your answers. I am planning on setting up the computer labs of my department using kerberized nfsv3 (since v4 seems to be "more" experimental) with a FreeBSD nfs server and Linux nfs clients. I was wondering "how stable" such an implementation would be; meaning that I wouldn't want to end up with an unstsable setup when receiving requests from 50-60 simultaneous clients, because that would be my everyday scenario. > > Thanks again for all your explanations (you covered me fully) and for your understanding of my remarks. I think all that is needed is for kdestroy to make a syscall on the client to flush cached credentials - the server clean up automatically after the cred expires. As long as the client deletes its cached cred (and the associated keying materials), there should be no security issues. I believe Solaris does it this way.Received on Thu Feb 11 2010 - 15:47:14 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:00 UTC