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

[Andy Bierman <[e-mail]>]

On Mon, Nov 27, 2017 at 2:39 AM, Robert Wilton <[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.

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.

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?
(Or rather, why has this problem been ignored for so long? Maybe it not
that real?)

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]> wrote:
>
>> ----- Original Message -----
>> From: "Andy Bierman" <[e-mail]>
>> To: "t.petch" <[e-mail]>
>>
>>
>> > On Fri, Nov 24, 2017 at 3:02 AM, t.petch <[e-mail]> wrote:
>> >
>> > > <inline>
>> > >
>> > > Tom Petch
>> > >
>> > > ----- Original Message -----
>> > > From: "Robert Wilton" <[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]>> 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]>>
>> wrote:
>> > > > >>>>>
>> > > > >>>>>
>> > > > >>>>>
>> > > > >>>>>             On 10/11/2017 15:49, Andy Bierman wrote:
>> > > > >>>>>>
>> > > > >>>>>>
>> > > <snip>
>> > >
>> > >
>> >
>>
>>
>
>