Date: Thu, 11 Feb 2010 16:46:41 +0000 From: Doug Rabson <dfr@rabson.org> To: George Mamalakis <mamalos@eng.auth.gr> Cc: Rick Macklem <rmacklem@uoguelph.ca>, freebsd-stable <freebsd-stable@freebsd.org>, freebsd-current@freebsd.org Subject: Re: Kerberized NFSv3 incorrect behavior Message-ID: <0DDBB542-5BCF-485B-ACF9-0EE977E74A92@rabson.org> In-Reply-To: <4B6D3A18.2030304@eng.auth.gr> References: <4B6BE7A2.6000402@eng.auth.gr> <Pine.GSO.4.63.1002051224510.27442@muncher.cs.uoguelph.ca> <4B6D3A18.2030304@eng.auth.gr>
next in thread | previous in thread | raw e-mail | index | archive | help
On 6 Feb 2010, at 09:44, George Mamalakis wrote: > Rick Macklem wrote: >>=20 >>=20 >> On Fri, 5 Feb 2010, George Mamalakis wrote: >>=20 >>> Dear all, >>>=20 >>> 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: >>>=20 >> [good stuff snipped] >>>=20 >>>=20 >>> and both client and server have the correct entries about each other = (and themselves) in their /etc/hosts, so heimdal works just fine. >>>=20 >>> 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. >>>=20 >>=20 >> 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. >>=20 >> The short answer is that any principal with TGT in the credentials >> cache for uid=3D=3DN 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). >>=20 >>> So, when I mount the exported filesystem on the client giving: >>>=20 >>> # mount -o nvfsv3,sec=3Dkrb5 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) >>>=20 >>> and try to access the share: >>> # ls /mnt >>> ls: mnt: Permission denied >>>=20 >>> 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: >>=20 >> Yep, as expected. >>> # klist >>> Credentials cache: FILE:/tmp/krb5cc_0 >>> Principal: mamalos@EXAMPLE.COM >>>=20 >>> Issued Expires Principal >>> Feb 5 11:20:49 Feb 5 21:20:47 krbtgt/EXAPMLE.COM@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 >>>=20 >>> 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 >>>=20 >>=20 >> 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=3D=3DN" 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? >>=20 >> 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. >>=20 >>> 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. >>>=20 >>> 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). >>>=20 >>=20 >> 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. >>=20 >>> 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. >>>=20 >>=20 >> 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.) >>=20 >> Hope that clarifies things, rick >>=20 >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" >>=20 > Rick, >=20 > 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. >=20 > 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. =20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0DDBB542-5BCF-485B-ACF9-0EE977E74A92>