Subject: [nfsv4] allowed delayed writes via AUTH_GSS

From: [email-masked]
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/[email-masked] 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/[email-masked]

Now, if the principal nfs/[email-masked] (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/[email-masked] 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 1 Oct 2003 16:01:36 -0700

> semantic, since access is checked at Open only.)

I think a reasonable compromise is to allow the client's hostbased
principal to renew state on behalf of its users, using the same
CLIENTID.

In fact, the protocol already allows this, I think.  So users with
expired creds on clients that have hostbased creds won't lose state, but
their dirty data won't be flushed either.   Oh well.

I think this is quite fine.

> vulnerabilities does that open up?

I don't think we can have the client's hostbased principal do anything
else that might be destructive on behalf of open owners authenticated
with different user principals.  But if we really wanted to do so we'd
have to address two thorny security issues: a) how do we identify which
principal the client can use for this, b) how do we make sure that all
these GSS contexts are sufficiently bound to the CLIENTID.  One
possibility might be to have a new operation by which a user could
delegate write/close/unlock authority to another principal.  But I don't
think we need go there if allowing the client hostbased principal to
renew state for its users, which I think it can.

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 1 Oct 2003 21:57:54 -0700

> principal to renew state on behalf of its users, using the same

And DELEGRETURN.  Unfortunately the client's hostbased principal will
generally not be able to perform a DELEGRETURN on behalf of its users.
Sigh.

Nico
--

---

From: "William A.(Andy) Adamson" <[email-masked]>
Date: Thu, 02 Oct 2003 09:24:12 -0400

> 	principal is nfs/[email-masked]

wait a minute: for #3 to happen, the file permissions have to allow the user 
nfs/[email-masked] to write. are you proposing that machine creds have 
acl's in exported filesystems?