Subject: Security negotiation issue in NFS V4

From: "Corbett, Peter" <[email-masked]>
Date: Mon, 25 Sep 2000 08:15:02 -0700

I have run into an issue that I've discussed with Dave, and that you might have
some insight into.

Basically, in V4, when a client crosses a security boundary on a server, it will
get a WRONGSEC error from the server.  This will possibly be in the middle of a
compound operation, so the client will have to determine from the response which
op caused the security error.  It could be the result of a lookup or an open.
So, now the client is in a bad situation.  It has tried one security mechanism
to access the file, but now must perform a secinfo op to determine a valid
security mechanism for the file.  However, secinfo itself can return WRONGSEC,
implying that the same security controls are applied for the SECINFO op as are
applied for any other op on the file.  The mere fact that the server must
implement some required mechanisms does not guarantee that a particular file
will allow any or all of those mechanisms.  So the client has a bootstrapping
issue in trying to access the file.  It must establish secure sessions with the
server, using RPCSEC_GSS, then try to make a SECINFO call for the particular
file on that session.  However, it has no way to query the file as to its
allowed security mechanisms without first guessing as to what mechanism might be
allowed.

There might be cases where certain files are accessible only through kerberos 5,
for example, and then of course only from clients that have the kerberos
infrastructure.  A non-kerberos client could then be precluded from ever
discovering what security mechanisms are allowed for the file.  This seems
contrary to the intent of the SECINFO op.

So, there are two possibilities that I can see to fix this.  One is to allow any
supported security mechanism, including all the required mechanisms, to be used
on any SECINFO call to any file.  In other words, remove the WRONGSEC error from
the list of errors returnable from SECINFO.  The second is to require that one
strong security mechanism (SPKM3 ?) be required for all files for SECINFO calls.

The other issue is that SECINFO works off the current file handle, and that to
set the current file handle requires doing a lookup, open or setfh successfully.
But to do that, the client must be using a security mechanism allowed by the
file, as all of those ops can return WRONGSEC errors.  So, either SECINFO needs
to take an explicit filehandle argument, or it needs to take a pathname
argument, or one of the other ops that can set filehandle needs to be opened up
to override the allowed security mechanisms on the file.

There is actually an interesting case for lookup or open, which would be a good
test case.  In a single lookup, multiple security boundaries could be passed,
and it may not be possible for the server to navigate through all the
directories spanned by the lookup in any one single security context.  So, there
is no way for the client to complete the entire lookup atomically; it must
decompose it, establish secure sessions as needed for each path component, and
then do the lookup incrementally.  The same holds for open.

---

From: Mike Eisler <[email-masked]>
Date: Mon, 25 Sep 2000 09:17:38 -0700 (PDT)

> I have run into an issue that I've discussed with Dave, and that you might
> have some insight into.
> 
> Basically, in V4, when a client crosses a security boundary on a server, it
> will get a WRONGSEC error from the server.  This will possibly be in the
> middle of a compound operation, so the client will have to determine from
> the response which op caused the security error.  It could be the result of
> a lookup or an open. So, now the client is in a bad situation.  It has tried
> one security mechanism to access the file, but now must perform a secinfo op
> to determine a valid security mechanism for the file.  However, secinfo
> itself can return WRONGSEC, implying that the same security controls are
> applied for the SECINFO op as are applied for any other op on the file.  The
> mere fact that the server must implement some required mechanisms does not
> guarantee that a particular file will allow any or all of those mechanisms.

You are confusing the security that the server will allow for a SECINFO
query with the security a server will allow for a file access.

> So, there are two possibilities that I can see to fix this.  One is to allow
> any supported security mechanism, including all the required mechanisms, to
> be used on any SECINFO call to any file.  In other words, remove the

WRONGSEC is a reasonable error, since it handles the case where a client
attempts to use a security flavor that the server doesn't support.

> WRONGSEC error from the list of errors returnable from SECINFO.  The second
> is to require that one strong security mechanism (SPKM3 ?) be required for
> all files for SECINFO calls.

Requiring SPKM-3 or krb5 on a SECINFO is heavy handed. The security in
SECINFO isn't for the server's benefit, it is for the client's benefit
to ensure a secure channel. If the client wants to issue a SECINFO
using AUTH_NONE or AUTH_SYS, and if the server supports AUTH_NONE or
AUTH_SYS, then why should the server reject the SECINFO?

I agree though, that if one gets a WRONGSEC error, then the best, and
in the worst case, only, course of action is to issue a SECINFO with an
SPKM-3 security flavor, that uses anonymous client authentication.

> The other issue is that SECINFO works off the current file handle, and that
> to set the current file handle requires doing a lookup, open or setfh

I don't see why a server should care what security is used when
PUT*FH is called. PUT*FH isn't a file access.

> successfully. But to do that, the client must be using a security mechanism
> allowed by the file, as all of those ops can return WRONGSEC errors.  So,
 
Again, the security that the server will allow for a SECINFO
query with the security a server is different than it will allow for
a file access. The sequence of operations:

	PUTFH, SECINFO "a

isn't a file access.

> either SECINFO needs to take an explicit filehandle argument, or it needs to
> take a pathname argument, or one of the other ops that can set filehandle
> needs to be opened up to override the allowed security mechanisms on the
> file.
> 
> There is actually an interesting case for lookup or open, which would be a
> good test case.  In a single lookup, multiple security boundaries could be
> passed, and it may not be possible for the server to navigate through all the
> directories spanned by the lookup in any one single security context.  So,
> there is no way for the client to complete the entire lookup atomically; it
> must decompose it, establish secure sessions as needed for each path
> component, and then do the lookup incrementally.  The same holds for open.

I wouldn't implement the server to examine the required security on each
intermediate boundary. Only the security used on the last boundary
is interesting. This was what I did for the Solaris webnfs lookup, and
it worked well.

	-mre