Subject: [nfsv4] Re: [PATCH 9 of 16] nfsd4: relax new lock seqid check

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 29 Nov 2005 18:10:48 -0500

On Tue, Nov 29, 2005 at 04:49:56PM -0600, Spencer Shepler wrote:
> I would suggest carrying the discussion over to the nfsv4@ietf alias
> and asking if server vendors can confirm their current behavior.
> I know that the Solaris server does not reject a first sequence id
> of non-zero.

OK.  To catch up people on [email-masked]:

RFC 3530 has a sentence in 8.1.5: "the first request issued for any
given lock_owner is issued with a sequence number of zero."

A server could use this as justification to reject a open_to_lock_owner4
argument with lock_seqid field nonzero.  Does anyone know of server
implementations (other than less recent Linux servers) that actually
do this?

I'm inclined to believe this is just a bug in the spec, maybe left over
from a previous version, since there's no reason to actually require a
zero there.

There also might be some mild security advantage to randomizing the
initial sequence id.

(I'm bringing this up because the Linux server used to actually check
the initial lock_seqid field until we realized there wasn't any reason
to, and someone recently asked why we removed the check.  The
discussion, for anyone interested:
http://linux-nfs.org/pipermail/nfsv4/2005-November/002978.html)

--b.

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

---

From: David Robinson <[email-masked]>
Date: Wed, 30 Nov 2005 00:13:06 -0600

I believe that this is a leftover from before we had an explicit
OPEN and confirmation. initially the client had no way
to communicate which is the first seqid in a series, so the
easy out was to just say start with zero.

But now that we have a much more robust mechanism to
establish the lock_owner, you are correct that starting at
zero is unnecessary.

I wouldn't put to much faith in security thru randomization,
if you really care about security you will use strong authentication
and integrity checks, so rogue interjection of seqids
would not be possible even if the values are well known.
Of course you can throw privacy as well to keep it secret.

	-David

---

From: Paul Mazzurana <[email-masked]>
Date: Wed, 30 Nov 2005 08:35:06 -0600

As per the RFC text, the IBM AIX server will check and fail the request if 
the first sequence id is nonzero with the error NFS4ERR_BAD_SEQID.

--
Paul D. Mazzurana
[email-masked]

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 30 Nov 2005 10:43:15 -0500

> the first sequence id is nonzero with the error NFS4ERR_BAD_SEQID.

I assume you're only doing this for lock owners, not for open owners?

--b.

---

From: Paul Mazzurana <[email-masked]>
Date: Wed, 30 Nov 2005 13:14:49 -0600

that is correct, only for lock owners.

--
Paul D. Mazzurana
[email-masked]
512-838-3529      Tie: 678

---

From: David Robinson <[email-masked]>
Date: Wed, 30 Nov 2005 13:45:26 -0600

Chuck Lever wrote:
> David Robinson wrote:

> this is not to prevent interjection of sequence IDs.

Maybe I am missing something, but with RPCSEC_GSS authentication
and integrity protection, you cannot interject a seq_id unless
you have first broken the caller's security credentials. If
you have done that interjection of seq_id's is the least of
your problems.

> the idea of field randomization is to prevent a client from giving away 
> information to anyone watching on the wire.  in fact it is the default 
> policy of OpenBSD that, whether or not any known exploit exists, you 
> should always use randomized data in protocol fields that contain 
> arbitrary data.

In general I don't question the value of randomization, especially
for protocols that don't have strong security built in (or don't
use them). My point was simply that security is a weak argument
for relaxing the requirement that seq_id's start at zero as the
benefit is small and NFSv4 has other prefered mechanisms to
eliminate the problem entirely.

	-David

---

From: Mike Eisler <[email-masked]>
Date: Wed, 30 Nov 2005 11:51:16 -0800 (PST)

> you have done that interjection of seq_id's is the least of

Interjection of NFSv4 state seqids is possible if the attacker
is running from a different NFS client, and a different user id
than the legitimate user of the state sequence, and the
NFSv4 server is not binding the state sequence to a user.