Subject: Re: [nfsv4] NFS4ERR_WRONGSEC inconsistency - LINK and RENAME

From: "Noveck, Dave" <[email-masked]>
Date: Sun, 13 Apr 2008 11:24:45 -0400

> 1Y, 2Y: CREATE, LINK, RENAME

> 1Y, 2N: CREATE, LINK, RENAME, RESTOREFH

> 1N, 2Y: none of the above

Oops.  This should have included RENAME.

> 1N, 2N: LINK, RENAME, RESTOREFH

-----Original Message-----
From: Noveck, Dave 
Sent: Sunday, April 13, 2008 9:09 AM
To: 'Trond Myklebust'; Mike Eisler
Cc: [email-masked]
Subject: RE: [nfsv4] NFS4ERR_WRONGSEC inconsistency - LINK and RENAME

> > The target name is presumed to not exist (if it did, NFS4ERR_EXIST 
> > would trump other errors, even if the target name had a different 
> > security policy). Therefore the security policy of the directory 
> > filehandle is used, and the put directory filehandle operation is 
> > where we enforce the policy.

> Shouldn't this argument also apply to OPEN? 

No, because of the fact that OPEN can be and often is applied to
existing objects.

One question that governs which errors are valid is how you think that
security poliies are assigned to portions of filesystems.  The way I had
been thnking about it was that policies would be assigned to existing
objects and inherited from parent objects to subordinate objects.

So if I create and object within a directory it would have the same
security as the parent directory until someone changed  that security
policy by some action (command line on the server) outside the scope of
v4.x.  Similarly, there is no way to create a file system object with
v4.x.  You create a directory which is part of the current filesystem
and then somehow later something on the server (e.g. a mount) transforms
that into a junction to a new fs.

On the other hand, you could allow a policy that says directory entries
whose string ends in ".secret" have a different security policy than
those that don't, in which case LINK, CREATE, and RENAME are now very
different from a WRONGSEC perspective.

> Also, just out of curiosity, why do we have RESTOREFH in the above two

> lists? Aren't you pretty much guaranteed to get a WRONGSEC error on 
> the filehandle before you get round to the SAVEFH?

I think this may relate to the issue of LINK and RENAME.  If you create
an object and continue to use it in the COMPOUND, you could conceive,
since it is not atomic, that between two ops the server changes his
security policy for the object in question (if you can ever get WRONGSEC
subsequently, it has to change some time, so it might be before the
COMPOUND is done), but the protocol has decided, in order to simplify
client implementations, to avoid the possiblity of getting WRONGSEC for
the current fh.  At any time that for the current fh, you are guaranteed
not to get the error on a current fh once vetted when established.  You
could apply the same to the saved fh, but you don't have to.  Not
protecting the saved fh in this way would only mean that you had to
check the error at RESTOREFH and anywhere that the saved fh was actually
used (only LINK and RENAME, I think)

So I think you have two questions:

1) Can security policies be on name-pattern-defined classes of objects?

2) Is the saved fh protected in the same way as current fh?

So my take is:

1Y, 2Y: CREATE, LINK, RENAME

1Y, 2N: CREATE, LINK, RENAME, RESTOREFH

1N, 2Y: none of the above

1N, 2N: LINK, RENAME, RESTOREFH

-----Original Message-----
From: Trond Myklebust [mailto:[email-masked]]
Sent: Saturday, April 12, 2008 2:03 PM
To: Mike Eisler
Cc: [email-masked]
Subject: Re: [nfsv4] NFS4ERR_WRONGSEC inconsistency - LINK and RENAME

On Sat, 2008-04-12 at 10:02 -0700, Mike Eisler wrote:
> Chapter 15 says:
> 
> | NFS4ERR_WRONGSEC                  | LOOKUP, LOOKUPP, OPEN, PUTFH, |
> |                                   | PUTPUBFH, PUTROOTFH,          |
> |                                   | RESTOREFH                     |
> 
> But Chapter 18, SECINFO says:
> 
>   client request receives NFS4ERR_WRONGSEC.  The operations which may
>   receive this error are: LINK, LOOKUP, LOOKUPP, OPEN, PUTFH,
PUTPUBFH,
>   PUTROOTFH, RESTOREFH, RENAME, and indirectly READDIR.
<snip>
> So the rationale for CREATE not being on the list? Here is a stab:
> 
> The target name is presumed to not exist (if it did, NFS4ERR_EXIST 
> would trump other errors, even if the target name had a different 
> security policy). Therefore the security policy of the directory 
> filehandle is used, and the put directory filehandle operation is
where we enforce the policy.

Shouldn't this argument also apply to OPEN?

Also, just out of curiosity, why do we have RESTOREFH in the above two
lists? Aren't you pretty much guaranteed to get a WRONGSEC error on the
filehandle before you get round to the SAVEFH?

Cheers
  Trond

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

---

From: Trond Myklebust <[email-masked]>
Date: Sun, 13 Apr 2008 14:46:54 -0400

> > 1N, 2N: LINK, RENAME, RESTOREFH

I agree with your assessment. So for which of the above 4 alternatives
would we have a concensus? Unless someone can come up with a compelling
argument against it, my personal preference would be for the "Occam's
razor" choice number 3: 1N 2Y

  Trond

---

From: "Mike Eisler" <[email-masked]>
Date: Sun, 13 Apr 2008 12:55:10 -0700 (PDT)

> used (only LINK and RENAME, I think)

Makes sense.

> 1Y, 2Y: CREATE, LINK, RENAME

I think it is:

1Y, 2Y: REMOVE

Why isn't REMOVE among the list? The target could have
a policy.

Why is CREATE on the list? If the object doesn't exist,
it has no policy. If it does exist, then NFS4ERR_EXIST is
what must be returned.

Why are LINK and RENAME on the list? The saved fh is protected.

LINK is linking one of the two filehandles; we've already
checked their policies. Note that if the target name
exists, we return NFS4ERR_EXIST. This is the same as CREATE.

RENAME: security policies should not be protecting the
rename of the policied object. SECINFO is not that smart.

> 1Y, 2N: CREATE, LINK, RENAME, RESTOREFH

I think it should be:

1Y, 2N: REMOVE, LINK, RENAME, RESTOREFH

for the same reasons as the previous 1Y, 2Y case.

> 1N, 2Y: none of the above

Dave noted this should have had RENAME. I'm not
seeing it. A RENAME amounts to adding a directory
entry and deleting a directory entry. If REMOVE
and CREATE are not on the list, why should RENAME be
on the list?

So I think it is:

> 1N, 2N: LINK, RENAME, RESTOREFH

I agree.

So while eliminating RESTOREFH from the list of operations that
can return NFS4ERR_WRONGSEC is going to create a lot
editing work for me, I agree that 1N, 2Y is the easiest case
and the sanest way to deal draft-21's current inconsistency.

---

From: "Noveck, Dave" <[email-masked]>
Date: Sun, 13 Apr 2008 16:54:14 -0400

> Why isn't REMOVE among the list? The target could have a policy.

My intention was that REMOVE was implicitly included in all the options,
just as LOOKUP is.

> Why is CREATE on the list? If the object doesn't 
> exist, it has no policy. If it does exist, then 
> NFS4ERR_EXIST is what must be returned.

Under 1Y, objects can implicitly have policies based on their names.
With the example of "*.secret" requiring kerberos, AUTH_SYS creation of
"big.secret" would return WRONGSEC.

> LINK is linking one of the two filehandles; we've 
> already checked their policies. Note that if the 
> target name exists, we return NFS4ERR_EXIST. This 
> is the same as CREATE.

Here I was thinking of a name-based policy where the link matched the
link pattern.

> RENAME: security policies should not be protecting 
> the rename of the policied object. SECINFO is not 
> that smart.

RENAME identifies an existing object by name.  If the caller would get
WRONGSEC doing a LOOKUP of that object, he certainly should get one
renaming it.

> for the same reasons as the previous 1Y, 2Y case.

OK.

> and CREATE are not on the list, why should RENAME 
> be on the list?

REMOVE was intended to be implicitly on the list as discussed above.

The difference between CREATE and RENAME is similar to that between
CREATE and OPEN.  RENAME works on an existing object which may have
previously acquired a policy.

> > 1N, 2Y: none of the above

I think it would be RENAME and REMOVE.

> So while eliminating RESTOREFH from the list of 
> operations that can return NFS4ERR_WRONGSEC is 
> going to create a lot editing work for me, I agree 
> that 1N, 2Y is the easiest case and the sanest way 
> to deal draft-21's current inconsistency.

I agree.

-----Original Message-----
From: Mike Eisler [mailto:[email-masked]] 
Sent: Sunday, April 13, 2008 3:55 PM
To: [email-masked]
Subject: Re: [nfsv4] NFS4ERR_WRONGSEC inconsistency - LINK and RENAME

> I think this may relate to the issue of LINK and RENAME.  If you 
> create an object and continue to use it in the COMPOUND, you could 
> conceive, since it is not atomic, that between two ops the server 
> changes his security policy for the object in question (if you can 
> ever get WRONGSEC subsequently, it has to change some time, so it 
> might be before the COMPOUND is done), but the protocol has decided, 
> in order to simplify client implementations, to avoid the possiblity 
> of getting WRONGSEC for the current fh.  At any time that for the 
> current fh, you are guaranteed not to get the error on a current fh 
> once vetted when established.  You could apply the same to the saved 
> fh, but you don't have to.  Not protecting the saved fh in this way 
> would only mean that you had to check the error at RESTOREFH and 
> anywhere that the saved fh was actually used (only LINK and RENAME, I 
> think)

Makes sense.

I think it is:

1Y, 2Y: REMOVE

Why isn't REMOVE among the list? The target could have a policy.

Why is CREATE on the list? If the object doesn't exist, it has no
policy. If it does exist, then NFS4ERR_EXIST is what must be returned.

LINK is linking one of the two filehandles; we've already checked their
policies. Note that if the target name exists, we return NFS4ERR_EXIST.
This is the same as CREATE.

RENAME: security policies should not be protecting the rename of the
policied object. SECINFO is not that smart.

I think it should be:

> 1N, 2Y: none of the above

Dave noted this should have had RENAME. I'm not seeing it. A RENAME
amounts to adding a directory entry and deleting a directory entry. If
REMOVE and CREATE are not on the list, why should RENAME be on the list?

So I think it is:

I agree.

So while eliminating RESTOREFH from the list of operations that can
return NFS4ERR_WRONGSEC is going to create a lot editing work for me, I
agree that 1N, 2Y is the easiest case and the sanest way to deal
draft-21's current inconsistency.

---

From: "Mike Eisler" <[email-masked]>
Date: Thu, 17 Apr 2008 12:31:36 -0700 (PDT)

I was in the process of making the edits to remove RESTOREFH from
the list of operations that can return NFS4ERR_WRONGSEC and came
across this:

  <section anchor="using_secinfo" title="Using NFS4ERR_WRONGSEC, SECINFO,
and SE
CINFO_NO_NAME">
  <t>
   This section explains of the mechanics of NFSv4.1 security negotiation.
   The term "put filehandle operation" refers to
   PUTROOTFH, PUTPUBFH, PUTFH, and RESTOREFH.
  </t>

   <section anchor="PUTFH + SAVEFH"
    title="Put Filehandle Operation + SAVEFH">
   <t>
    The client is saving a filehandle for a future RESTOREFH. The
    server MUST NOT return NFS4ERR_WRONGSEC to either the put filehandle
    operation or SAVEFH.
   </t>
   </section> <!-- Put Filehandle Operation + SAVEFH -->

----------

There's a reason, which I do not recall, why a put filehandle op
followed by SAVEFH is not allowed to return NFS4ERR_WRONGSEC.

But because, e.g. PUTFH, SAVEFH cannot return _WRONGSEC, this
means RESTOREFH has to return WRONGSEC.

Now we could state that PUTFH, SAVEFH can return NFS4ERR_WRONGSEC,
and that seems like it is OK. But then so did eliminating WRONGSEC
from the list of errors RESTOREFH can return.
But I have no time to figure why the spec disallows WRONGSEC on the
PUTFH, SAVEFH case.

So I intend to make SECINFO synchronized with the errors chapter:
remove LINK and RENAME as valid operations that can return NFS4ERR_WRONGSEC.

to the spec (i.e. producing an RFC that is broken).

-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/

---

From: "Mike Eisler" <[email-masked]>
Date: Thu, 17 Apr 2008 13:01:25 -0700 (PDT)

Ah, now I see why LINK and RENAME have to return NFS4ERR_WRONGSEC.

PUTFH followed by SAVEFH cannot return NFS4ERR_WRONGSEC.
LINK and RENAME don't require a RESTOREFH. If there is a strict
security policy on the saved fh used for LINK and RENAME, then without
NFS4ERR_WRONGSEC, that policy could be circumvented.

So, knowing what I know now (and I may know more later, so this is subject
to change), my new plan is:

 Make the errors chapter synchronized with the SECINFO section:
 add LINK and RENAME as valid operations that can return
 NFS4ERR_WRONGSEC.

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 17 Apr 2008 17:18:20 -0400

> PUTFH followed by SAVEFH cannot return NFS4ERR_WRONGSEC.

I agree that this makes it consistent. You've just restated Dave's "1N
2N" case.

I just don't see a justification for why we need to defer the WRONGSEC
from PUTFH+SAVEFH to the RESTOREFH case.

Trond

---

From: "Mike Eisler" <[email-masked]>
Date: Thu, 17 Apr 2008 15:39:27 -0700 (PDT)

> from PUTFH+SAVEFH to the RESTOREFH case.

I think though after reading the section entitled:
"Put Filehandle Operation + LOOKUP (or OPEN by Name)"
I understand the reason why PUTFH+SAVEFH cannot return
NFS4ERR_WRONGSEC. In fact the whole section entitled
"SECINFO and SECINFO_NO_NAME" makes it clear that there
are times PUTFH can return NFS4ERR_WRONGSEC. By disallowing
a PUTFH followed by SAVEFH from returning NFS4ERR_WRONGSEC, and
allowing RESTOREFH (under some conditions, same as
PUTFH) to return NFS4ERR_WRONGSEC we potentially avoid an
unnecessary NFS4ERR_WRONGSEC.

Going back to "Put Filehandle Operation + LOOKUP (or OPEN by Name)"

     b)  sec_policy_child ^ sec_policy_parent != {} (^ for intersection,
      {} for the empty set).  This means that the security tuples
      specified on the security policy of a child directory always has a
      non empty intersection with that of the parent.

  [...]

   For a server to support approach (b) (when client chooses a flavor
   that is not a member of sec_policy_parent) and (c), the put
   filehandle operation must NOT return NFS4ERR_WRONGSEC when there is a
   security tuple mismatch.  Instead, it should be returned from the
   LOOKUP (or OPEN by component name) that follows.

Suppose:

- we have these security policies on the server

       /xyz sec=sys
       /xyz/abc sec=krb5

- the fh of "xyz" is 0x123.

- the client sends this COMPOUND using krb5 creds:

   SEQUENCE, PUTFH 0x123, SAVEFH, RESTOREFH, LOOKUP "abc", GETFH

Let's say the model is (not what the spec says)
 PUTFH can return NFS4ERR_WRONGSEC if followed immediately by
 SAVEFH, and RESTOREFH can never return NFS4ERR_WRONGSEC.

PUTFH returns NFS4ERR_WRONGSEC, so the
client would issue SECINFO_NO_NAME with AUTH_SYS creds, and then
sends:

   SEQUENCE, PUTFH 0x123, SAVEFH, RESTOREFH, LOOKUP "abc", GETFH

We then get NFS4ERR_WRONGSEC on the LOOKUP, send SECINFO to find
"abc"'s policy, and then send another COMPOUND to get "abc"'s fh.

Let's say we follow the model in the spec. Again this COMPOUND
is issued with krb5 creds:

   SEQUENCE, PUTFH 0x123, SAVEFH, RESTOREFH, LOOKUP "abc", GETFH

just returns the file handle.

---

From: "Mike Eisler" <[email-masked]>
Date: Thu, 17 Apr 2008 16:08:46 -0700 (PDT)

> (and I may know more later, so this is subject
> to change)

  2.6.3.1.1.  Put Filehandle Operation + SAVEFH

   The client is saving a filehandle for a future RESTOREFH.  The server
   MUST NOT return NFS4ERR_WRONGSEC to either the put filehandle
   operation or SAVEFH.

There's a problem. E.g.

      PUTFH, SAVEFH, READ

As stated above, PUTFH could not return NFS4ERR_WRONGSEC.

So I am proposing that it say:

2.6.3.1.1.  Put Filehandle Operation + SAVEFH

   The client is saving a filehandle for a future RESTOREFH.
   SAVEFH MUST NOT return NFS4ERR_WRONGSEC. To determine
   whether put filehandle
   operation returns NFS4ERR_WRONGSEC or not, the server
   implementation pretends SAVEFH is not in the series of operations
   and determines which of the situations described in the
   other subsections of 2.6.3.1 apply.

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 17 Apr 2008 22:59:10 -0400

>    other subsections of 2.6.3.1 apply.

This just proves to show how screwed up the rules are: basically the
server is required to look ahead to see

  - Am I doing PUTFH+<not SAVEFH>
        - Yes: return NFS4ERR_WRONGSEC
        - No: Am I doing PUTFH+SAVEFH+<some operation that depends on
        current fh>
                - Yes: return NFS4ERR_WRONGSEC
                - No: wait for the RESTOREFH in order to return
                NFS4ERR_WRONGSEC

Why?....

   Trond

---

From: "Mike Eisler" <[email-masked]>
Date: Thu, 17 Apr 2008 20:13:06 -0700 (PDT)

> This just proves to show how screwed up the rules are: basically the

I think the rules are an improvement in NFSv4.0.

Client implementers have expressed in the past that they
don't want to deal with NFS4ERR_WRONGSEC on every operation.

>                 - No: wait for the RESTOREFH in order to return

I gave an example ... one COMPOUND vs three.
Security policy flexibility in another.

If people would rather return NFS4ERR_WRONGSEC on every operation,
have restrictions on security policies, etc. then they should
have expressed that years ago, or even a few months ago.

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 17 Apr 2008 23:21:11 -0400

> just returns the file handle.

I can see that you might want to worry about PUTFH+LOOKUP or PUTFH
+LOOKUPP and similar, but in reality the only operations that actually
use the saved filehandle are LINK, and RENAME.

Aside from artificial constructs like the above RESTOREFH+LOOKUP, why do
we care about allowing LINK and RENAME to cross security policy
boundaries? Isn't that a potential security hole?

  Trond

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 18 Apr 2008 11:47:31 -0400

> - we have these security policies on the server

Somewhat of a digression, I know, but would it be worth warning against
a configuration like that?

(Assuming an attacker that can insert their own replies onto the network
(the assumption that motivates verifiers on rpcsec_gss replies), the
lookup of /xyz is untrusted, so there's no reason for the client to
trust that it actually gets to /xyz/abc.

That's true even if the user explicitly requests that the client use
krb5 on /xyz/abc; the attacker could be returning a filehandle for
/home/mallory/, a filesystem under his control that is exported from the
same server and allows krb5.

Something like:

	/xyz sec=krbi
	/xyz sec=krb5p

shouldn't have that problem, as turning privacy on or off shouldn't
affect the client's trust in the server's replies to lookups.)

--b.