[nfsv4] allowed delayed writes via AUTH_GSS

rick@snowhite.cis.uoguelph.ca

From: rick@snowhite.cis.uoguelph.ca
Message-Id: <200310012244.SAA16509@snowhite.cis.uoguelph.ca>
Subject: [nfsv4] allowed delayed writes via AUTH_GSS
Date: Wed, 1 Oct 2003 18:44:31 -0400 (EDT)

[Disclaimer: I'm far from a security or Kerberos wiz, so I might be
   way off the mark here.]
I've been thinking about delayed writes when using AUTH_GSS some more
and I think it might be ok in certain situations. (This would seem to
be nice, since clients with write delegations might delay the writes
for a very long time. It also gives the client a "more POSIX like"
semantic, since access is checked at Open only.)

[Nicolas Williams wrote]
> It would still be nice for clients with hostbased princs/creds to be
> able to flush dirty data using the clients' hostbased creds, which
> requires binding of the clients' contexts to the same quantity.

Just suppose the following:
1 - Client does a SetClientID with AUTH_GSS, where the principal is
	nfs/host1@KERBEROS.REALM and gets clientid0
2 - Client Opens file "X" for writing, using clientid0 and AUTH_GSS, where
	the principal is <user>@KERBEROS.REALM successfully
	getting stateid0
3 - Client Writes to file "X" using stateid0 and AUTH_GSS, where the
	principal is nfs/host1@KERBEROS.REALM

Now, if the principal nfs/host1@KERBEROS.REALM (which is the one the server saw
for the SetClientID the Open is associated with) is considered acceptable, what
vulnerabilities does that open up?

A bad guy could easily do a fake #3, if it has the right keytab file and
the correct stateid (stateid0). So, it seems to me the above is ok if
you can trust the client machine to keep a keytab file secure. (For a typical
MIT Kerberos installation, "root" on the machine can access both the
keytab and the user's file that the tgt ticket is stashed in, so a bad
guy with "root" on the client machine could cobble to-gether an AUTH_GSS
with either nfs/host1@KERBEROS.REALM or <user>@KERBEROS.REALM, couldn't they?)

If the sysadmin was lazy and created one keytab file with "nfs@host1,
nfs@host2,..." in it and put that file on all the hostN, then it would
be more vulnerable, but...

The bad guy also has to get the right stateid, which wouldn't be that
easy if they're not on the same machine (snooping isn't as easy with
switched hubs, etc.) and downright difficult for the Privacy case.

It seems to me it just comes down to how trustworthy the client's keytab
file is vs how trustworthy the user passwords and stashed tgt is?

Other vulnerabilities, such as pasting bogus Ops onto a valid AUTH_GSS, etc.
are handled via Integrity or Privacy, in either case.

Does this make sense? rick

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4