[TUHS] NFS & Kerberos woes...

[Theodore Y. Ts'o]

On Tue, Dec 25, 2018 at 06:01:19PM -0800, Larry McVoy wrote:
> I'm an NFS guy, learned it a bit at uwisc and then a lot more at Sun. 
> But Sun didn't do the Kerberos stuff, at least while I was there.
> 
> Didn't Kerberos come from MIT?  If so, I bet anything that Ted Ts'o
> would know the details.  My guess is it was part of project athena
> and I think that overlaps with Ted.  Yo, Ted, Merry Christmas,
> what about this Kerberos authentication stuff?  :)

So the way Kerberized NFS was used at Project Athena was that after
you authenticated as some Kerberos principal, say, such as
"tytso at ATHENA.MIT.EDU", there was mapping function/database which
would map that Kerberos authentication to a user id --- say, 15806.

On the Athena client, at login time /bin/login (or a PAM module) would
do a Hesiod lookup for (tytso, passwd) in the athena.mit.edu Hesiod
domain.  This translate to a DNS lookup for class=HS, type=TXT, for
tytso.passwd.ns.athena.mit.edu:

<tytso at cwcc> {/usr/projects/xfstests-bld/build-64}   (master)
1067% hesinfo -lb tytso passwd
hes_to_bind(tytso, passwd) expands to
tytso.passwd.ns.athena.mit.edu
which resolves to
tytso:*:15806:101:Theodore Y. Ts'o,E40-343,38091,:/mit/tytso:/bin/athena/tcsh

Because of the Kerberos authentication for tytso at ATHENA.MIT.EDU, the
Kerberos-authenticated NFS server would map all NFS requests
(regardless of the uid/gid in the NFS RPC) to the uid in the mapping
database --- in my case, 15806.  The mapping database and the Hesiod
DNS zone files are created from administration management system
called Moira.

This is important, because access checks are going to both be done on
the client side, as well as the server side.  And the Kerberos NFS
mapping only affects the uid/gid in the used for server-side access
control checks (e.g., it replaces the uid/gid in the NFS RPC request).
It does *not* affect the uid/gid returned by stat(2) / getattr
request.

All of this is saying, yes, of *course* Kerberos authenticated NFS
turns off no_root_squash.  The whole point of using Kerberos
authentication is so the server is willing to blindly trust the
uid/gid asserted by the client and grant access on that basis.  If you
are going to allow the the NFS server to go, "Hurr, durr... you are
claiming a uid of 0 --- OK!  You can do whatever you want." ---- why
bother with Kerberos authentication at all in the fairst place!?!

Now, I believe you *could* configure in the mapping database that
authentication from some Kerberos principal such as
"tytso/root at ATHENA.MIT.EDU" or "host/cwcc.mit.edu at ATHENA.MIT.EDU" (you
can use service principals from a Kerberos keytab as a client
principal for the purposes of machine authentication) should be mapped
to uid 0.

This wasn't somethingh we generally did, though, since the general
model we used is that root on the local client should mean _nothing_.
Indeed, on Public Athena workstations, the assumption was that anyone
could get root (since MIT students had physical access, and there's
nothing quite as dangerous than a bored MIT student).  Hence, during
thet time when I was an undergraduate, the public root password as
"mrroot".  Anyone could su to root thus eliminating the challenge of
"breaking root".

As a result, we never tried to give uid 0 special server-side
permissions, since it went against the model that IP address-based
authentication and blind-faith trust in assertions of uid==0 from NFS
clients as just being silly.

Cheers,
	
						- Ted