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: [email protected] >>> >>> Issued Expires Principal >>> Feb 5 11:20:49 Feb 5 21:20:47 krbtgt/[email protected] >>> # 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@ 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 >> >> _______________________________________________ >> [email protected] mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "[email protected]" >> > 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. _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
