allowed delayed writes via AUTH_GSS

[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 <at> KERBEROS.REALM and gets clientid0
2 - Client Opens file "X" for writing, using clientid0 and AUTH_GSS, where
	the principal is <user> <at> KERBEROS.REALM successfully
	getting stateid0
3 - Client Writes to file "X" using stateid0 and AUTH_GSS, where the
	principal is nfs/host1 <at> KERBEROS.REALM

Now, if the principal nfs/host1 <at> 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

Re: allowed delayed writes via AUTH_GSS

On Wed, Oct 01, 2003 at 06:44:31PM -0400, rick <at> snowhite.cis.uoguelph.ca wrote:
> [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.)

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.

> [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 <at> KERBEROS.REALM and gets clientid0
> 2 - Client Opens file "X" for writing, using clientid0 and AUTH_GSS, where
> 	the principal is <user> <at> KERBEROS.REALM successfully
> 	getting stateid0

RE: allowed delayed writes via AUTH_GSS

 > From: rick <at> snowhite.cis.uoguelph.ca

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

Yes that is the case.

When all we had was AUTH_SYS, ignioring IP
address spoofing, its security came down to
how trustworthy the client was. When we added RPCSEC_GSS
to NFSv[23], the security still came down to how trustworthy the
client was, but there was a way for clients to destroy their
credentials. And eventually, the Kerberos credentials expired.

Your proposal is somewhere between the two extremes, but I'd
put it closer to AUTH_SYS than pure user-to-server security.
In my opinion of course.

There's no need to complicate

Re: allowed delayed writes via AUTH_GSS

On Wed, Oct 01, 2003 at 04:01:36PM -0700, Nicolas Williams wrote:
> On Wed, Oct 01, 2003 at 06:44:31PM -0400, rick <at> snowhite.cis.uoguelph.ca wrote:
> > [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.)
> 
> 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.

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

Nico
--

-- 

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

Re: allowed delayed writes via AUTH_GSS

Why wouldn't the client be able to use its host authentication (used in 
SETCLIENTID) when doing DELEGRETURN? That seems like exactly what you 
would want to do. Of course one barrier I see is that it takes a 
filehandle via PUTFH, and PUTFH will be checking the authentication 
against the allowed security flavors for the exported data. This is 
unfortunate since a client would like to be able to hang on to and manage 
its granted delegation across many opens for potentially many users. The 
client should not have to carefully watch all the authentication contexts 
for the accessing users in order to know that it must do a DELEGRETURN 
when the last related context is about to expire or be destroyed. And then 
what if an admin actually removes the principal from the KDC or some async 
event happens that makes the last applicable user context at the client 
unusable. Now you have a client holding a delegation that it can 
successfully return.

To me, this looks fundamentally flawed that primarily state oriented 
operations are so closely tied to user authentication when in fact state 
is a client to server. This is especially true for delegations. Client IDs 
own delegations, not users.

Carl

Carl Burnett
AIX Kernel Architecture - Network File System
(512) 838-8498, TL 678-8498
(please reply to cburnett <at> us.ibm.com)

Nicolas Williams <Nicolas.Williams <at> sun.com>
Sent by: nfsv4-admin <at> ietf.org
10/01/2003 11:57 PM

Re: more re: ticket expiration and NFSv4 state

Re: allowed delayed writes via AUTH_GSS

> [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 <at> KERBEROS.REALM and gets clientid0
> 2 - Client Opens file "X" for writing, using clientid0 and AUTH_GSS, where
> 	the principal is <user> <at> KERBEROS.REALM successfully
> 	getting stateid0

> 3 - Client Writes to file "X" using stateid0 and AUTH_GSS, where the
> 	principal is nfs/host1 <at> KERBEROS.REALM

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

> 
> Now, if the principal nfs/host1 <at> 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 <at> KERBEROS.REALM or <user> <at> KERBEROS.REALM, couldn't they?)
> 
> If the sysadmin was lazy and created one keytab file with "nfs <at> host1,
> nfs <at> 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 <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

RE: allowed delayed writes via AUTH_GSS

 > -----Original Message-----
 > From: Carl Burnett [mailto:cburnett <at> us.ibm.com]
 > Sent: Thursday, October 02, 2003 5:18 AM
 > To: nfsv4 <at> ietf.org
 > Subject: Re: [nfsv4] allowed delayed writes via AUTH_GSS
 >
 >
 > Why wouldn't the client be able to use its host
 > authentication (used in
 > SETCLIENTID) when doing DELEGRETURN? That seems like exactly what you
 > would want to do.
[...]

 > To me, this looks fundamentally flawed that primarily state oriented
 > operations are so closely tied to user authentication when in
 > fact state
 > is a client to server. This is especially true for
 > delegations. Client IDs
 > own delegations, not users.

What you see as flawed, others might see as good security.

If one wants to compromise security for convenience, one has the
freedom to add an ACE to his files giving the SETCLIENTID
principal authority to write and read data. With that
authority, the client can then acquire, flush, and
return delegations via the machine cred. ACE inheritence from directories
deals with any of the ease of use issues this entails. The prescence
of the machine cred in the ACL informs the client to use this
capability.

Or simply concede that the pure
machine cred model is adequate for one's purposes and
implement/deploy my suggested GSS pseudo-mechanism.

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

Re: allowed delayed writes via AUTH_GSS

On Thu, Oct 02, 2003 at 07:17:59AM -0500, Carl Burnett wrote:
> Why wouldn't the client be able to use its host authentication (used in 
> SETCLIENTID) when doing DELEGRETURN? That seems like exactly what you 

Because that would also require that the client host have permission to
WRITE dirty buffers.  That's too much permission to grant implicitly to
client host principals, methinks.

Fortunately, delegation revocation is per-open file, not per-clientid.

So:

 - user goes away

 - clients keeps RENEWing using its hostbased principal creds

 - server recalls delegations

 - client can't flush dirty buffers or return the delegations

 - server revokes those delegations

 - user comes back, refreshes his/her creds, but finds that his/her app
   that had dirty state lost that state and got sent some signal that
   killed it (say, SIGLOST).

I think this is fine.

Though I think we could consider an operation that allows the user to
explicitly delegate to the client host permission to do DELEGRETURN and
WRITE on his behalf for his open files.

> would want to do. Of course one barrier I see is that it takes a 
> filehandle via PUTFH, and PUTFH will be checking the authentication 
> against the allowed security flavors for the exported data. This is 
> unfortunate since a client would like to be able to hang on to and manage 
> its granted delegation across many opens for potentially many users. The 
> client should not have to carefully watch all the authentication contexts 
> for the accessing users in order to know that it must do a DELEGRETURN 
> when the last related context is about to expire or be destroyed. And then 
> what if an admin actually removes the principal from the KDC or some async 
> event happens that makes the last applicable user context at the client 
> unusable. Now you have a client holding a delegation that it can 
> successfully return.

What if the network goes away permanently?  That's pretty much the
effect of having the credentials of all involved go away permanently.

There's always going to be failure modes we can't easily recover from.
Even with plain AUTH_NONE and AUTH_SYS!  :)

Oh well.

> To me, this looks fundamentally flawed that primarily state oriented 
> operations are so closely tied to user authentication when in fact state 
> is a client to server. This is especially true for delegations. Client IDs 
> own delegations, not users.

The more I think about it, the happier I am that delegations are
per-principal, rather than per-clientid.  That's because returning a
write delegation means writing dirty buffers and that's too much
permission to be implicitly granting to client host principals.

Cheers,

Nico
--

-- 

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

yet more on delayed writes

[William A.(Andy) Adamson wrote]
> wait a minute: for #3 to happen, the file permissions have to allow the user 
> nfs/host1 <at> KERBEROS.REALM to write. are you proposing that machine creds have 
> acl's in exported filesystems?

I'm wasn't proposing machine creds in acl's (although that's an interesting
idea). I took a quick look at the section on the WriteOp (14.2.36)
and didn't spot any statement that the server was required to check for
file permissions when a WriteOp is performed. (Most will, because they
don't trust the cred. enough to accept the related Open or Write Delegation
as sufficient. Local POSIX file access doesn't check file protection
on every write, so it seems to me a V4 server doesn't have to, if it can
trust the cred enough to believe the Write is associated with the
Open or Write Delegation related to it by the stateid.)

However, it sounds like the consensus is that that is too much trust,
at least for most cases.

Anyhow, just a thought, rick

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4