Subject: [nfsv4] more re: NFS4ERR_CLID_INUSE

From: [email-masked]
Date: Mon, 13 Dec 2004 17:44:58 -0500 (EST)

Suppose a different client (spoofing the same client id name) is allowed
to do a SetClientID with AUTH_SYS and uid==0 before the lease expires.

Couldn't that result in a "denial of service" as well? For example:
- Client A has a current ClientID that it is Renew'ing, but no files
  currently Open
- nasty Client B does a SetClientID using Client A's client id name,
  AUTH_SYS and uid==0
  - if this is allowed, the server would issue a new ClientID to nasty
    Client B
now, Client A is going to get NFS4ERR_EXPIRED (at least that seems to
be the most appropriate error)

Mike mentioned something like "nasty Client B will spoof Client A's IP
address", but I see nothing in the RFC that says a Client must always
use the same IP address. Further, I believe a Client should be able to
change IP address (I'm not referring to Callback address here, nasty
Client B could spoof that, since it doesn't care if callbacks work).

To me, it seems that the ClientID itself is state that can't be tossed
until it expires.

Make any sense?

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 13 Dec 2004 18:04:00 -0500

> To me, it seems that the ClientID itself is state that can't be tossed

Makes sense to me.  To make the DOS most effective, client B can open a
file immediately, so client A can't just grab the client id name back.

If client B had quick reflexes, it could do this immediately after it
saw any other client do its setclientid.

--b.

---

From: Trond Myklebust <[email-masked]>
Date: Mon, 13 Dec 2004 18:18:02 -0500

> be the most appropriate error)

Why wouldn't the server just return NFS4ERR_STALE_CLIENTID when client A
presents its clientid? The correct response from client A is then simply
to issue a new SETCLIENTID.

Cheers,
  Trond

-- 
Trond Myklebust <[email-masked]>

---

From: Trond Myklebust <[email-masked]>
Date: Mon, 13 Dec 2004 19:00:58 -0500

> saw any other client do its setclientid.

Then don't export anything as AUTH_SYS to client B 'cos AUTH_SYS is only
meant to be used for clients that you can trust 100% not to do nasty
things (like set mandatory locks on all the files, spoof other people's
identities, close all their files,...).

This is like saying that you can DOS Apache provided you have root
access to the server that is running it...

Cheers,
 Trond

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 14 Dec 2004 12:41:54 -0500

> access to the server that is running it...

No, in many cases the DOS here is possible if servers allow clients to
grab setclientid's immediately, but isn't possible if servers wait out
the lease period before doing so.

For example, in the case where a server exports filesystems both to
auth_sys and auth_gss clients, the auth_gss clients would be immune to
this attack if servers waited the grace period.  They would also be
immune to the other attacks you describe, except for the "set mandatory
locks on all the files" attack, which seems less practical, and requires
file permissions to the right files.

Servers may want to allow auth_sys setclientid's to quite a large group
of clients--your server might export some filesystems to krb5 only but
might want one filesystem acessible to auth_sys clients too.

--b.

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 14 Dec 2004 13:23:57 -0500

> the lease period before doing so.

So you end up restricting the window for the DOS to the case of network
partitions and/or slow client reboots. Why is that better as far as
client implementations are concerned?

> file permissions to the right files.

Unless you use identity squashing (in which case the clientid spoofing
problem is moot too), spoofing the right permissions is the most trivial
of all attacks with AUTH_SYS.

> might want one filesystem acessible to auth_sys clients too.

Then don't let the untrusted ones use NFSv4.

Cheers,
  Trond