Subject: RE: [nfsv4] NFS4ERR_CLID_INUSE when SetClientID changesauthenticationmechanisms

From: Mike Eisler <[email-masked]>
Date: Tue, 14 Dec 2004 14:30:36 -0800

> From: J. Bruce Fields [mailto:[email-masked]]

 > On Tue, Dec 14, 2004 at 02:54:42PM -0500, Jim Rees wrote:
 > >   Well... AUTH_SYS is fine if your security is guaranteed
 > by other means
 > >   (no exterior IP connection, no physical access by unauthorized
 > >   personnel, ...).
 > >
 > >   Things like allowing stateful access to world + dog (even if it is
 > >   "only" a read-only partition), however, is a no-no...
 > >
 > > I think it would be a shame if NFSv4 can't provide
 > read-only access to the
 > > world using auth_sys without exposing itself to attacks.  Anonymous,
 > > unauthenticated read-only access accounts for the most file
 > system traffic
 > > on the Internet, by far.
 >
 > You can provide that sort of access without requiring the need for
 > setclientid--the special stateid's should be sufficient.

The special stateids won't allow readers to coordinate with
authorized writers.

 > How well do current clients deal with servers that won't allow
 > setclientid?  Do any current server allow you to forbid a set
 > of clients
 > from doing setclientid?

No SETCLIENTID, no byte range locking.

Maybe we should all just used special stateids, and if anyone wants
locking, just use NLM. Oh, yeah, that was tried in the 80s before. :-)

 > Also, does authentication actually solve the problem?  Authenticated
 > clients can also grab each other's client identifiers.  I suppose it

How can they? Client A is authenticated as principal X and
grabs client id X. Client B is authenticated as principal Y
and attempts to grab client id X. How will that be possible?

 > does make it easier for you to revoke access from ill-behaved
 > clients if
 > you can identify the problem.

The client that doesn't adapt from _INUSE errors is also
ill-behaved.

 > But the set of authenticated clients could be quite large.  You're
 > probably going to be giving out an awful lot of credentials
 > if you want
 > to provide access to everyone in your organization, and make
 > it possible
 > for all their machines to boot unattended.

You can either have one machine cred per client, or issue the
SETCLIENTID per user.

 > It would be nice if setclientid were a more innocent operation.

What's the alternative? The requirements are to make locking
secure (which is isn't in NFSv3/NLM) and (quickly) recoverable
(which it is in NFSv3/NLM).

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

---

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

> and attempts to grab client id X. How will that be possible?

client A authenticates as principal X and does a setclientid with client
	identifier "foo".
Malicious client B authenticates as principal Y, waits till client A
	doesn't appear to be holding any state, then does a setclientid with
	client identifier "foo", and does an open on some file.

If client A follows the recommendations on client identifier generation
in section 8.1.1, then it probably won't try to find itself a different
client identifier, so it won't recover from this.

> (which it is in NFSv3/NLM).

I'm not sure.

Maybe the client identifier namespace could be per-principal--then two
client identifiers presented on setclientid would only be considered the
same if both the identifier and the principal doing the setclientid were
the same.

Hmm.  As long as we're on the subject of malicious clients: what
prevents client A from using client B's clientids, stateowners, and
stateids on its own requests?  Couldn't it corrupt client B's state
arbitrarily by doing so?

--b.

---

From: Mike Eisler <[email-masked]>
Date: Tue, 14 Dec 2004 15:52:18 -0800

> client identifier, so it won't recover from this.

Those are "considerations", not "recommendations". Client A
is broken if can't recover from it. Client A knows he has no
state, so why does he need his previous client id? The
only time he needs previous client id is to handle the case
of A holding state, crashing, rebooting, and the app wanting
to re-lock the same files it had before -- without
hanging, waiting for the lease to expire. Even then, if client
A gets bad _INUSE, there's then no need for the previous client id:
he knows, that because a SETCLIENTID has been done, that the locks
client A had before are gone, so the app will be able to lock
without waiting for client A's lease from a previous incarnation to
expire.

> same if both the identifier and the principal doing the setclientid were

With AUTH_SYS there are no per-client principals.

And among different security flavors, e.g. AUTH_SYS, Kerberos,
SPKM, the principal name forms are different.

> stateids on its own requests?  Couldn't it corrupt client B's state

If AUTH_SYS is being used, nothing. Just as with AUTH_SYS nothing prevents
client A from assuming any identiy and destroying or corrupting data.

If Kerberos, LIPKEY, or SPKM are being used to authenticate access
to the files with state, then client A can't corrupt B's state unless
it can authenticate as the user on B creating the state.

If the concern is that a user on client A acquires creds, and
a rogue NFS client implementation uses those creds to mess with
B's state, then that's a valid point, but it applies to file
operations as well, not to mention the e-commerce transactions
we all do with are web browsers. I'm far more certain of my
in-kernel NFS client's authenticity then I am of my Firefox
browser's (attackers can switch browsers easier than they
can switch kernels) authenticity, and even so I trust
my Firefox enough to to send my credit card and identification
numbers over it.

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 14 Dec 2004 19:58:48 -0500

> my Firefox enough to to send my credit card and identification

They don't have to switch kernels in order to issue NFSv4 requests. All
they need is an RPC client library with rpcsec_gss capabilities.

Say, didn't someone at Sun once develop one of those ;-)

Cheers,
  Trond

-- 
Trond Myklebust <[email-masked]>

---

From: Mike Eisler <[email-masked]>
Date: Tue, 14 Dec 2004 17:19:33 -0800

> they need is an RPC client library with rpcsec_gss capabilities.

Unless you can interpose that libary between me and the kernel,
you can't take my Kerberos, SPKM, LIPKEY, etc. creds from me
and impersonate me. Just like, you can write a user level http
client using a client library with SSL to try to access my amazon
account, but unless you know my password or unless you
can replace my firefox, it doesn't do you any good. I'm
far more confident in your ability to switch -- without me
noticing -- my firefox than to switch my kernel.

> Say, didn't someone at Sun once develop one of those ;-)

Yes, and he's wondering why no else did.

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 14 Dec 2004 21:04:45 -0500

> noticing -- my firefox than to switch my kernel.

No, but all I need is a valid credential (any valid credential) in order
to be able to mess with your stateids and open_owners assuming that I
can guess them or sniff them off the wire. I believe that was the gist
of Bruce's complaint.

The reason is that stateids and open_owners are not tied to any
particular rpcsec_gss context or even to a particular principal as far
as the server is concerned. I don't even need access rights to the file
in order to mess with a client's open owner sequence id accounting. 

Are servers for instance checking that CLOSE, DELEGRETURN are
originating from the same client IP address as the initial OPEN, or the
SETCLIENTID? I don't believe Linux is...

Cheers,
  Trond

---

From: Mike Eisler <[email-masked]>
Date: Wed, 15 Dec 2004 03:06:47 -0800

> can guess them or sniff them off the wire. I believe that was the gist

No, any valid credential is  not sufficient. You need the credential of
the enity that OPENed the file (and only if that enity has
the read or write access rights corresponding to the operation that
changes the stateid), or if the server is so inclined, the entity
that has rights to modify or read the file that was OPENed.

If it were otherwise, then there'd be little point to doing NFSv4.

> as the server is concerned. I don't even need access rights to the file
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Why you believe that?

> SETCLIENTID? I don't believe Linux is...

If servers did, that would be a bug. Multi-interfaced clients are
a reality.

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 15 Dec 2004 09:16:10 -0500

> that has rights to modify or read the file that was OPENed.

Did I miss something? Where does the protocol say that?

> > as the server is concerned. I don't even need access rights to the file

Recall that at one point the Linux client was sharing open_owners
between different credentials. Turns out that was impractical for
various reasons, but I still find nothing in the RFC that forbids it. 

So which specific passage says that a client is not allowed to share the
same open_owner or stateid between 2 different principals or says that
the server is allowed to enforce such a rule?

> If servers did, that would be a bug. Multi-interfaced clients are

Right. That is what I thought too...

Cheers,
  Trond

---

From: "Mike Eisler" <[email-masked]>
Date: Thu, 16 Dec 2004 08:04:07 -0800

> Did I miss something? Where does the protocol say that?

It doesn't. Just like it doesn't require that a file of mode bits 0700
opened by
the owner be subsequently written by only the owner. It is implied that
the NFS client will use a cred authorized to to do I/O to such a file.
So it follows that the NFS client will, when issuing a stateid changing
operation,
use a cred authorized to read (if a shared lock op) or write (if an
exclusive lock op) the file.

The spec discusses the credential issues around SETCLIENTID and its
potential to destroy state. An interpretation allowing any cred
to destroy state via another set of ops strikes me as odd. Put another way,
if any op can destroy state, then there's no point in implementing the
server
to enforce cred checks in SETCLIENTID, and similarly no point in the
client enforcing cred checks on callbacks.

The spec certainly doesn't say that any cred can be used to corrupt any
state.

> various reasons, but I still find nothing in the RFC that forbids it.

OK. I was objecting more to the assertion that you don't need access rights
to the file. I think you either need access rights, or need the access
rights
that were checked at the time the file was opened.

I look it this way. In an operating environment like POSIX, if we had just
local
file systems, it would not be possible for user A to unlock user B's locks.
File systems going over a network break the tight control of the operating
environment
for sure, but  they should at least offer some security to prevent state
corruption from
unauthorized users.

---

From: "Mike Eisler" <[email-masked]>
Date: Thu, 16 Dec 2004 08:03:50 -0800

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 16 Dec 2004 12:01:51 -0500

On Thu, Dec 16, 2004 at 08:03:50AM -0800, Mike Eisler wrote:
> OK. I was objecting more to the assertion that you don't need access
> rights to the file. I think you either need access rights, or need the
> access rights that were checked at the time the file was opened.
>
> I look it this way. In an operating environment like POSIX, if we had
> just local file systems, it would not be possible for user A to unlock
> user B's locks.  File systems going over a network break the tight
> control of the operating environment for sure, but  they should at
> least offer some security to prevent state corruption from
> unauthorized users.

If I deploy a NFSv4 server at the University of Michigan, I'll want to
use the UMICH.EDU kerberos realm, which has hundreds of thousands of
principals.  The chance that one of them is compromised or otherwise in
malicious hands is pretty much 100%.

Also, I'm likely to want to have files on my server that are readable by
any authenticated user.

If a user establishes some state to read such a file, it's probably not
hard to guess their stateid and use it to send a CLOSE request from
another host.  If the server doesn't associate any principal with the
stateid, then the CLOSE will succeed and the user's client will start
getting BAD or OLD STATEID errors.  Does that mean the application
reading the file on the user's behalf will fail?   And can a
carefully-written client limit client limit the damage just to that?

--b.

---

From: Mike Eisler <[email-masked]>
Date: Mon, 20 Dec 2004 14:00:56 -0800

> another host.  If the server doesn't associate any principal with the

Or from the same host.

> stateid, then the CLOSE will succeed and the user's client will start

I can't tell which side of the issue you are arguing. But your
point does argue for the principal issuing the CLOSE be the same as that
of the principal that created the state sequence via OPEN.

> reading the file on the user's behalf will fail?   And can a

Yes.

> carefully-written client limit client limit the damage just to that?

A client is written to re-established state due to a Denial of Service
attack is at best hard to write, and at worst an exercise in futility.
The only ways to solve this are:

- If you must use APIs that cause stateids to change, then
   set the ACL such that only you and other trusted users can
   issue such NFSv4 operations. Or:

- Use the proper credential on stateid modifying operations,
   and on the server side, enforce the credential.