Re: [nfsv4] allowed delayed writes via AUTH_GSS

andros@citi.umich.edu

Subject: Re: [nfsv4] allowed delayed writes via AUTH_GSS 
From: "William A.(Andy) Adamson" <andros@citi.umich.edu>
Message-Id: <20031002132413.F1B5D20825@citi.umich.edu>
Date: Thu, 02 Oct 2003 09:24:12 -0400

> [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

wait a minute: for #3 to happen, the file permissions have to allow the user 
nfs/host1@KERBEROS.REALM to write. are you proposing that machine creds have 
acl's in exported filesystems?

> 
> 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
> 

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