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

["t.petch" <[e-mail]>]

----- Original Message -----
From: "Robert Wilton" <[e-mail]>
Sent: Monday, November 27, 2017 10:39 AM


> 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.

Robert

This is what I was obliquely referring to when I said

" And I
don't know how much 'when' is used in that way in existing YANG
modules - uh huh, more reading required.
"

I did start looking and found that many, if not most, 'when' statements
relate to 'augment', e.g. for a specific interface type, and so are
simpler than the case postulated which can cause an implicit delete (I
have yet to see one such in an actual YANG module).

Then I started wondering what the NACM rules would be like if I wanted
to permit changes to LAN interfaces but not to WAN interfaces, both
specified by 'augment' to the base model.

Then I started wondering if a NACM rule that permitted changes to a LAN
interface would be valid on a server with no LAN interfaces specified.;
and would that change if a LAN card is hot plugged and auto-configured.

Um, more reading required.

As Andy says, NACM needs to be simple else it will not be used.  The
concept is simple - permit LAN, deny WAN - but the NACM rules I am less
clear about.

Tom Petch

>
> Thanks,
> Rob
>
>
> 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>
> >     > >
> >     > >
> >     >
> >
> >
>
>