Subject: [Netconf] NACM and "when" statements

From: Robert Wilton <[email-masked]>
Date: Mon, 20 Nov 2017 10:28:28 +0000

Hi Andy, Martin,

I've got a question about 'when' statement handling related to NACM.

Due to when statements, it is possible that a client could implicitly 
cause a change to a part of the data tree that they have no write access 
to because they cause a when condition to evaluate to a different 
answer.  Am I correct in presuming that this implicit change is allowed?

E.g. in the following example, a user may only have write access to 
"baz" but not "bar". If they create "baz" then that may implicitly cause 
"bar" to be deleted.  Further, even if this implicit delete to "bar" is 
allowed, I presume that the equivalent explicit change or creating "baz" 
and deleting "bar" would still be rejected because there is no explicit 
write access to bar.

container foo {
   leaf bar {
    when "not(../baz)";
   }
   leaf baz {
   }
}

Should this be mentioned in the NACM draft at all?  I'm not convinced 
that the draft makes the correct behaviour for handling 'when' 
statements obvious.

Similar considerations could also apply when writing to choice statements.

Thanks,
Rob

---

From: Andy Bierman <[email-masked]>
Date: Mon, 20 Nov 2017 17:14:24 -0800

Hi,

On Mon, Nov 20, 2017 at 2:28 AM, Robert Wilton <[email-masked]> wrote:

> cause a change to a part of the data tree that they have no write access to
> because they cause a when condition to evaluate to a different answer.  Am
> I correct in presuming that this implicit change is allowed?
>
> E.g. in the following example, a user may only have write access to "baz"
> but not "bar". If they create "baz" then that may implicitly cause "bar" to
> be deleted.  Further, even if this implicit delete to "bar" is allowed, I
> presume that the equivalent explicit change or creating "baz" and deleting
> "bar" would still be rejected because there is no explicit write access to
> bar.
>
> container foo {
>   leaf bar {
>    when "not(../baz)";
>   }
>   leaf baz {
>   }
> }
>
> Should this be mentioned in the NACM draft at all?  I'm not convinced that
> the draft makes the correct behaviour for handling 'when' statements
> obvious.
>
I just confirmed that our server does not enforce nacm:default-deny-all for
the "when-stmt" node.
NACM rules say "user X is allowed to write /foo/baz" and nothing about
/foo/baz side-effects.
YANG says nodes exist only if the when-stmt is true and nothing about how
they change
from true to false. I don't think access control is mentioned in either RFC
for this corner-case.

Perhaps more security consideration text is needed, warning that any nodes
that are deleted
by the server because of false when-stmt evaluation are exempt from access
control.

It would be a significant change to implementations to enforce delete
permissions on
when-stmt and choice-stmt automatic node removal. This can also apply to
automatic
creation of default nodes (when-stmt evaluates true, was false).

> Rob
Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 21 Nov 2017 10:58:55 +0100 (CET)

> NACM rules say "user X is allowed to write /foo/baz" and nothing about

Our implementation works the same way, and I agree this is reasonable
behavior.  NACM controls access to the operations, not the side
effects.

/martin

---

From: Robert Wilton <[email-masked]>
Date: Tue, 21 Nov 2017 13:58:01 +0000

Proposed text below.

> behavior.  NACM controls access to the operations, not the side
OK, so I propose the following NEW additions to rfc6536bis:

Added to the end of section "1.2.  Changes Since RFC 6536":

    The data node access behavior for path matches has been clarified to
    also include matching descendant nodes of the specified path.

    The <edit-config> operation access rights behavior has been clarified
    to indicate that write access is not required for data nodes that are
    implicitly modified through side-effects (such as the evaluation of
    YANG when-stmts, or data nodes implicitly deleted when creating a
    data node under a different branch under a YANG choice-stmt).

Added to the end of section "3.2.5.  <edit-config> Operation":

    An <edit-config> operation may cause data nodes to be implicitly
    created or deleted as an implicit side-effect of a requested
    operation.  For example, a YANG when-stmt expression may evaluate to
    a different result, causing data nodes to be deleted, or created with
    default values; or if a data node is created under one branch of a
    YANG choice-stmt, then all data nodes under the other branches are
    implicitly removed.  No NACM access rights are required on any data
    nodes that are implicitly changed as a side effect of another allowed
    operation.

Added after paragraph 4 of "3.7.2.  General Configuration Issues":

    It is possible that the data model definition itself (e.g., YANG
    when-stmt or choice-stmt) will allow a session to implicitly create
    or delete nodes that the session does not have write access to as an
    implicit side effect from the processing of an allowed <edit-config>
    operation.

In case it is useful, git diff for the above change is also attached.

Thanks,
Rob

> .

diff --git a/netconf-access-control.xml.in b/netconf-access-control.xml.in
index 402bf7c..6c5abdf 100644
--- a/netconf-access-control.xml.in
+++ b/netconf-access-control.xml.in
@@ -286,6 +286,20 @@
         so a simple mapping to the existing NACM procedures
         and data model is possible.
       </t>
+      <t>
+        The data node access behavior for path matches has been
+        clarified to also include matching descendant nodes of the
+        specified path.
+      </t>
+      <t>
+        The &lt;edit-config&gt; operation access rights behavior has
+        been clarified to indicate that write access is not required
+        for data nodes that are implicitly modified through
+        side-effects (such as the evaluation of YANG when-stmts, or
+        data nodes implicitly deleted when creating a data node under
+        a different branch under a YANG choice-stmt).
+
+      </t>
     </section>
   </section>
 
@@ -990,6 +1004,18 @@
           be exposed in any &lt;rpc-error&gt; elements
           within the reply.
         </t>
+        <t>
+          An &lt;edit-config&gt; operation may cause data nodes to be
+          implicitly created or deleted as an implicit side-effect of
+          a requested operation.  For example, a YANG when-stmt
+          expression may evaluate to a different result, causing data
+          nodes to be deleted, or created with default values; or if a
+          data node is created under one branch of a YANG choice-stmt,
+          then all data nodes under the other branches are implicitly
+          removed.  No NACM access rights are required on any data
+          nodes that are implicitly changed as a side effect of
+          another allowed operation.
+        </t>
       </section>
 
       <section title="&lt;copy-config&gt; Operation">
@@ -2047,6 +2073,13 @@ m4_include(ietf-netconf-acm.yang)
          by examining the presence and values of different data nodes.
        </t>
        <t>
+         It is possible that the data model definition itself (e.g.,
+         YANG when-stmt or choice-stmt) will allow a session to
+         implicitly create or delete nodes that the session does not
+         have write access to as an implicit side effect from the
+         processing of an allowed &lt;edit-config&gt; operation.
+       </t>
+       <t>
          There is a risk that non-standard protocol operations, or
          even the standard &lt;get&gt; protocol operation, may
          return data that "aliases" or "copies" sensitive data