Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change

[Robert Wilton <[e-mail]>]

On 27/11/2017 15:12, Andy Bierman wrote:
>
>
> On Mon, Nov 27, 2017 at 2:39 AM, Robert Wilton <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     I do get the point that Tom is making here, and have quite a lot
>     of sympathy for it.  E.g. by automatically allowing the side
>     effects of when/choice statements then we are introducing a
>     potential security hole here that operators may find hard to be
>     aware of and mitigate.
>
>     It also seems odd to me that a client is allowed to implicitly
>     remove some configuration through the side effect of a when/choice
>     statement that they are not allowed to delete explicitly.
>
>     The alternative of requiring appropriate access for the
>     side-effects, seems like an intuitively safer design, but I also
>     get Andy's concern that security isn't useful if it become so
>     unwieldy that nobody uses it.
>
>     So, I guess the question here is, do we have some concrete
>     examples using real data models where the extra NACM delete rules
>     would be required?  If not then perhaps requiring the explicit
>     access for side effects would be better.
>
>
>
> Yes -- please provide some examples where it is better to force the 
> operator
> to provide extra "delete" rules to allow false-when data nodes to be 
> deleted.
> It seems to me that these rules would allow individual data structures 
> to be
> removed by the client, that would not otherwise be possible.
Yes, this is true.

But it is still odd that they a client is allowed to delete the 
configuration, just not explicitly.  I.e. it is strange that they are 
not allowed to put in a semantically equivalent request that explicitly 
deletes the configuration, they are only allowed to do it if the delete 
is implicit.  This seems inconsistent.

>
> If 3 data structures need to be in place "when /foo exists" then
> deleting 1 or 2 of them directly may not be desirable. Deleting
> them all together (i.e., via when-false deletion) may be the intended 
> usage.
If there is a dependency that all three exist then that may be better 
expressed with a must statement instead.

>
> The vendor and operator need to be aware of the data model dependencies.
> That said, how come CLI-based configuration does not have this problem?
My experience of CLI based configurations do have these sorts of 
problems, and many more :-)


> (Or rather, why has this problem been ignored for so long? Maybe it 
> not that real?)
This may be the real crux of the argument:

It probably doesn't make sense to use when statements on disjoint parts 
of the YANG schema (e.g. it does not make sense for the OSPF YANG model 
to depend on whether an interface it runs over has an IP address 
configured).  Instead, a more normal usage would be a flag (e.g. like 
interface type) to allow/prevent certain child nodes from being 
available.  In these scenarios, if a user is allowed to change the type 
of an interface then they are most likely allowed to change the other 
settings on the interface as well.

So for 'normal' when statements, it probably doesn't make much 
difference whether or not explicit NACM access is required to the nodes 
being implicitly deleted because the client probably already has the 
necessary access rights.

But for the 'corner case' when statement scenario, that are unlikely to 
be used, it still seems safer to require explicit access permissions 
than implicitly accepting the side effect with no NACM validation.

Thanks,
Rob


>
>     Thanks,
>     Rob
>
>
> Andy
>
>
>     On 25/11/2017 15:53, Andy Bierman wrote:
>>
>>
>>     On Sat, Nov 25, 2017 at 4:42 AM, t.petch <[e-mail]
>>     <mailto:[e-mail]>> wrote:
>>
>>         ----- Original Message -----
>>         From: "Andy Bierman" <[e-mail]
>>         <mailto:[e-mail]>>
>>         To: "t.petch" <[e-mail] <mailto:[e-mail]>>
>>
>>
>>         > On Fri, Nov 24, 2017 at 3:02 AM, t.petch
>>         <[e-mail] <mailto:[e-mail]>> wrote:
>>         >
>>         > > <inline>
>>         > >
>>         > > Tom Petch
>>         > >
>>         > > ----- Original Message -----
>>         > > From: "Robert Wilton" <[e-mail]
>>         <mailto:[e-mail]>>
>>         > > Sent: Thursday, November 23, 2017 10:44 AM
>>         > >
>>         > > > Hi Andy,
>>         > > >
>>         > > > On 22/11/2017 18:09, Andy Bierman wrote:
>>         > > > > On Wed, Nov 22, 2017 at 5:41 AM, Benoit Claise wrote:
>>         > > > >
>>         > > > >     Hi Rob,
>>         > > > >
>>         > > > >     At that points in time, if it clarifies the spec.
>>         and the
>>         > > authors
>>         > > > >     agree with this, let's do the right thing.
>>         > > > >
>>         > > > > I will add the new text if that is what the WG wants.
>>         > >
>>         > > > Having read this draft, I was undecided what the
>>         intended behavior
>>         > > > actually should be.
>>         > > >
>>         > > > The way that Yumapro and Tail-f have implemented this is
>>         reasonable,
>>         > > and
>>         > > > is probably also the way that I would implemented it.
>>         > > >
>>         > > > But I also think that it would be a reasonable
>>         implementation for
>>         a
>>         > > > server to calculate the full change set (taking account
>>         of side
>>         > > effects
>>         > > > from when and choice statements) to the datastore
>>         before checking
>>         the
>>         > > > "write data node access control" against the resultant
>>         change set.
>>         > > >
>>         > > > My interpretation is that the RFC text is ambiguous on
>>         what the
>>         > > correct
>>         > > > behavior is, and one could make a reasonable argument
>>         that the
>>         current
>>         > > > RFC actually specifies that the alternative behavior is
>>         correct,
>>         i.e.
>>         > > > requiring delete access even if a node is implicitly
>>         changes as a
>>         side
>>         > > > effect. E.g. section 3.2.3 of RFC 6536 states:
>>         > > >
>>         > > >     If the protocol operation would result in the
>>         deletion of a
>>         > > datastore
>>         > > >     node and the user does not have "delete" access
>>         permission for
>>         > > that
>>         > > >     node, the protocol operation is rejected with an
>>         "access-denied"
>>         > > >     error.
>>         > >
>>         > > Rob
>>         > >
>>         > > I have been reading that paragraph since this thread
>>         started and
>>         > > wondering how it could be thought unclear, what am I
>>         missing:-)
>>         > >
>>         > > To me it clearly states that the user must have the
>>         appropriate
>>         access
>>         > > for the consequences of whatever they do, be that 'when',
>>         'choice'
>>         or
>>         > > anything else! Indeed, I see exactly that behaviour in
>>         operational
>>         > > (non-network) databases of which I am a user with limited
>>         privileges.
>>         > >
>>         > >
>>         >
>>         > This is not correct.
>>         > The server is the entity that is cleaning up false when-stmt or
>>         unselected
>>         > cases
>>         > for a choice-stmt.
>>         >
>>         > NACM does not prevent the sever from making any changes to
>>         the system.
>>         > It only affects the operations requested by a client.
>>
>>         Andy
>>
>>         My model is slightly different, that the server is a black
>>         box, with an
>>         interface through which I can make authorised changes.  If
>>         something I
>>         do causes the deletion of something I am not allowed to
>>         delete, may be
>>         not even to read, well, we part company on the acceptability
>>         of that!
>>
>>         I do accept, as Randy points out, that the situation is
>>         complicated.  I
>>         am reminded of the issues that came up relating to the 'when'
>>         statement
>>         when preparing YANG 1.1.  Yes, 'when' makes things possible
>>         and is very
>>         useful but at the same time, its side effects can be
>>         troublesome.  I
>>         would like to wrap it up in a conceptual bubble so you could
>>         not have
>>         the sort of fine-grained access control that allows the case
>>         that Rob
>>         postulates to occur but have no idea what that might look
>>         like.  And I
>>         don't know how much 'when' is used in that way in existing YANG
>>         modules - uh huh, more reading required.
>>
>>
>>
>>     When the access control is too complicated, it does not get used.
>>     Instead, the most likely access control is "everybody is the root
>>     user".
>>     The server pruning of false when/choice data nodes is considered
>>     cleanup.
>>     The pruned data is no longer relevant to the data model. This is
>>     the indended
>>     use, but when-stmt can easily be abused.
>>
>>     The complex tangled web of dependencies is no worse
>>     than it has been with CLI for 30 years, where every dependency is
>>     ad-hoc
>>     and probably undocumented. The granularity of CLI-based access
>>     control
>>     is less granular than NACM.
>>
>>     It is possible that vendors and operators are willing to spend
>>     hours and days
>>     figuring out how to tune the NACM rules to allow a specific edit
>>     to work.
>>     Of course the operator will not even be told by the server which
>>     nodes
>>     are blocking the edit. That would be a security risk.
>>
>>     IMO NACM will be completely unusable if rules are needed to allow
>>     server cleanup of dead nodes.  The additional NACM rules required
>>     might provide more access than intended (unless lots of delete-only
>>     rules are added). The huge jump in NACM rule management complexity is
>>     a new security vulnerability, which might even be worse than the
>>     vulnerability it is intended to fix.
>>
>>
>>
>>         Tom Petch
>>
>>         >
>>         > Andy
>>         >
>>
>>
>>
>>
>>     Andy
>>
>>
>>
>>
>>
>>
>>
>>         > > My other thought was that given all the complexities of
>>         'when' that
>>         > > emerged during the specification of YANG 1.1, perhaps,
>>         were I an
>>         > > implementor of this, I would take the easy option and
>>         ignore the
>>         side
>>         > > effects of 'when'; but I might feel guilty about doing so.
>>         > >
>>         > > If the new paragraphs go in as proposed, then I think
>>         that the two
>>         > > paragraphs you quote need changing else that section
>>         looks to me
>>         like an
>>         > > oxymoron.
>>         > >
>>         > > Tom Petch
>>         > >
>>         > > > An <edit-data> request that causes a when constraint to
>>         evaluate
>>         > > > differently does result in a deletion of those data
>>         nodes from the
>>         > > > datastore, and hence according to the text above, requires
>>         explicit
>>         > > > "delete" access permission to accomplish that.
>>         > > >
>>         > > > Clearly it would be an interop issue if different servers
>>         implemented
>>         > > > the NACM path based filtering differently.
>>         > > >
>>         > > > Hence why I think that it would be prudent for the
>>         draft to be
>>         more
>>         > > > explicit on when and choice statement handling.
>>         > > >
>>         > > > Rob
>>         > > >
>>         > > > > There have not been any comments on this issue.
>>         > > > >
>>         > > > > Andy
>>         > > > >
>>         > > > >     Regards, Benoit.
>>         > > > >>
>>         > > > >>     Hi Benoit,
>>         > > > >>
>>         > > > >>     There is also one further, unrelated change that
>>         I am
>>         proposing
>>         > > > >>     is made the draft before it is published, to
>>         help better
>>         > > clarify
>>         > > > >>     the expected behavior. It isn't the end of the
>>         world if
>>         this
>>         > > > >>     doesn't go in, but I think that it prevents
>>         sometime taking
>>         a
>>         > > > >>     different, but IMO reasonable, interpretation of
>>         how "when"
>>         > > > >>     statements are considered, and then having a future
>>         argument
>>         > > > >>     about what behavior it specified in the standard.
>>         > > > >>
>>         > > > >>     If we clarify it now, then it closes that door :-)
>>         > > > >>
>>         > > > >>     I've proposed text to Andy and Martin on Monday,
>>         but I've
>>         not
>>         > > > >>     heard back yet.
>>         > > > >>
>>         > > > >>     Netconf email with proposed text attached. The
>>         text doesn't
>>         > > > >>     necessarily have to match this, but personally I
>>         think that
>>         it
>>         > > is
>>         > > > >>     useful if the draft says something on this.
>>         > > > >>
>>         > > > >>     Thanks,
>>         > > > >>     Rob
>>         > > > >>
>>         > > > >>
>>         > > > >>     On 22/11/2017 13:25, Benoit Claise wrote:
>>         > > > >>>     On 11/10/2017 7:23 PM, Andy Bierman wrote:
>>         > > > >>>>     Hi,
>>         > > > >>>>
>>         > > > >>>>     Here are some proposed edits to make the data rule
>>         consistent
>>         > > > >>>>     with the examples.
>>         > > > >>>>     Note that this issue is not related to the
>>         edit in the
>>         > > original
>>         > > > >>>>     1-week change.
>>         > > > >>>     That's right, but we found a source of
>>         misinterpretation
>>         in
>>         > > the
>>         > > > >>>     draft and you have rightly corrected it in the
>>         github v9.
>>         > > > >>>
>>         > > > >>>     Regards, Benoit
>>         > > > >>>>
>>         > > > >>>>
>>         > > > >>>>     sec. 3.3.5:
>>         > > > >>>>
>>         > > > >>>>     OLD:
>>         > > > >>>>
>>         > > > >>>>
>>         > > > >>>>     data node rule: controls access for a specific
>>         data
>>         > > > >>>>     node, identified
>>         > > > >>>>     by its path location within the conceptual XML
>>         document
>>         > > > >>>>     for the
>>         > > > >>>>     data node.
>>         > > > >>>>
>>         > > > >>>>
>>         > > > >>>>     NEW:
>>         > > > >>>>
>>         > > > >>>>     data node rule: controls access for a specific
>>         data node
>>         > > > >>>>     and its descendants,
>>         > > > >>>>     identified by its path location within the
>>         conceptual XML
>>         > > > >>>>     document for the
>>         > > > >>>>     data node.
>>         > > > >>>>
>>         > > > >>>>
>>         > > > >>>>     sec 3.4.5, step 6, bullet 2:
>>         > > > >>>>
>>         > > > >>>>
>>         > > > >>>>     OLD:
>>         > > > >>>>
>>         > > > >>>>     * The rule does not have a "rule-type" defined
>>         or the
>>         > > > >>>>     "rule-
>>         > > > >>>>     type" is "data-node" and the "path" matches the
>>         > > > >>>>     requested
>>         > > > >>>>     data node, action node, or notification node.
>>         > > > >>>>
>>         > > > >>>>     NEW:
>>         > > > >>>>     * The rule does not have a "rule-type" defined
>>         or the
>>         > > > >>>>     "rule-
>>         > > > >>>>     type" is "data-node" and the "path" matches the
>>         > > > >>>>     requested
>>         > > > >>>>     data node, action node, or notification node.
>>         A path is
>>         > > > >>>>     considered to match if the current data node
>>         is the
>>         > > > >>>>     data node
>>         > > > >>>>     specified by the path, or is a descendant data
>>         node
>>         > > > >>>>     of this data node.
>>         > > > >>>>     appendix B.4: (2 bugs in explanation)
>>         > > > >>>>     OLD:
>>         > > > >>>>     deny-nacm: This rule denies the "guest" group
>>         any access
>>         to
>>         > > the
>>         > > > >>>>  <nacm> subtree. Note that the default namespace
>>         is only
>>         > > > >>>>     applicable because this subtree is defined in
>>         the same
>>         > > > >>>>     namespace as the <data-rule> element.
>>         > > > >>>>     NEW:
>>         > > > >>>>     deny-nacm: This rule denies the "guest" group
>>         any access
>>         to
>>         > > the
>>         > > > >>>>  <nacm> subtree.
>>         > > > >>>>     Andy
>>         > > > >>>>
>>         > > > >>>>     On Fri, Nov 10, 2017 at 9:24 AM, Robert Wilton
>>         > > > >>>>     <[e-mail] <mailto:[e-mail]>
>>         <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>>         > > > >>>>
>>         > > > >>>>
>>         > > > >>>>
>>         > > > >>>>         On 10/11/2017 16:33, Andy Bierman wrote:
>>         > > > >>>>>
>>         > > > >>>>>
>>         > > > >>>>>         On Fri, Nov 10, 2017 at 8:16 AM, Robert
>>         Wilton
>>         > > > >>>>>  <[e-mail] <mailto:[e-mail]>
>>         <mailto:[e-mail] <mailto:[e-mail]>>>
>>         wrote:
>>         > > > >>>>>
>>         > > > >>>>>
>>         > > > >>>>>
>>         > > > >>>>>  On 10/11/2017 15:49, Andy Bierman wrote:
>>         > > > >>>>>>
>>         > > > >>>>>>
>>         > > <snip>
>>         > >
>>         > >
>>         >
>>
>>
>
>