Subject: Re: [Netconf] Partial-lock issues

From: Randy Presuhn <[email-masked]>
Date: Tue, 19 May 2009 13:40:11 -0700 (GMT-07:00)

Hi -

>From: Martin Bjorklund <[email-masked]>
>Sent: May 19, 2009 11:47 AM
>To: [email-masked]
>Cc: [email-masked]
>Subject: Re: [Netconf] Partial-lock issues
>
>"Randy Presuhn" <[email-masked]> wrote:
>> Hi -
>> 
>> > From: "Balazs Lengyel" <[email-masked]>
>> > To: "netconf mailing list" <[email-masked]>
>> > Sent: Tuesday, May 19, 2009 3:01 AM
>> > Subject: [Netconf] Partial-lock issues
>> ...
>> > Please state if you can accept the reasoning below or whether you think we
>> > should allow
>> > partial-locking ONLY for the running configuration?
>> > 
>> > 1) As Washam pointed out just by having access control and without using any
>> > locks we face a
>> > dead-lock problems:
>> > - A only has access to /foo, and edits it in candidate
>> > - B only has access to /bar, and edits it in candidate
>> > - A terminates it's session
>> > - Now B can not issue <discard-changes> because it can not modify /foo in the
>> > - candidate
>> > - B can not issue <commit> because it can not modify /foo in the running
>> > If A and/or B uses partial-locking that will NOT make this situation WORSE,
>> > as the lock is
>> > automatically released at the end of the session. The real problem is caused
>> > by access control.
>> ...
>> 
>> This reasoning makes an unwarranted assumption about how access control works.
>> Specifically, it assumes that the access control policy is evaluated at the
>> time of
>> the <commit>, rather than simply being applied to each individual
>> edit.
>
>No, I don't think the example makes that assumption.  The only
>assumption it makes is that the access control policy is *at least*
>evaluated as part of commit.  This is a use case that is explicitly
>mentioned in RFC 4741, section 9:
>
>   For
>   example, if a user A is not allowed to configure an IP address on an
>   interface but user B has configured an IP address on an interface in
>   the <candidate> configuration, user A must not be allowed to commit
>   the <candidate> configuration.

If you read that into the example, then the access control model is
hopelessly broken with respect to locking.  Commit is the wrong time
to evaluate the access decision function, unless each individual delta
(rather than the entire configuration) is marked with the identity
of the party responsible for that part of the total change-set.  As
long as *all* deltas happening in the course of a commit are handled
as though they had been made by the party whose action caused the
commit to happen, the deadlock will occur.

A much simpler approach is to evaluate the access decision function
at the time of each individual edit, rather than the commit.

Randy

Randy

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 20 May 2009 09:39:35 +0200

Hello Randy,
My statement is that based only on statements in rfc4741 partial-locking will not change the 
current problems around potential access-control related dead-locks. At this time I don't want 
to comment on the NETCONF access control model.

Balazs

PS. Putting aside partial-locks you could ask some other interesting questions about access 
control as well:
- when is it enforced: at commit or at editing the candidate or both. Enforcement at commit 
seems mandatory today. You may propose to change that later.
- will you always have the same access rights for different data stores
- can you lock something if you don't have access rights to it?
- what access rights do you need for kill-session? (Which effectively can remove edits from the 
candidate due to locking). So kill-session is strangely an editing operation as well
But if you want to discuss this please change the thread !

Randy Presuhn wrote:
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
> 

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320                  email: [email-masked]

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 20 May 2009 10:22:46 -0700

Hi -

> To: "Randy Presuhn" <[email-masked]>
> Cc: "Martin Bjorklund" <[email-masked]>; <[email-masked]>
> Sent: Wednesday, May 20, 2009 12:39 AM
...
> At this time I don't want 
...
...

Not really.  This should have been done during the architecture
and protocol design phase.  I think it's really too late to properly
fix, and will instead require a succession of partial fixes.  This
discussion is just one example of the kind of thing that will come
up again and again.  Have fun.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 20 May 2009 10:41:33 -0700

> up again and again.  Have fun.

I agree with Randy.

How many proprietary ACMs are actually implemented?
What is being done already?

It never occurred to me to define a ACM that worked differently
for one NETCONF database vs. another one.  It is also the
accepted BCP in NETCONF/YANG to report errors as soon as
possible, rather than as late as possible -- if the
error state cannot possibly change (e.g., invalid-value
or access-denied).

The $64 question is the correct RFC2119 word to use:

The agent (MUST/SHOULD/MAY) apply access control policies
to the candidate database (not just the running database).

IMO, if you do not have permission to commit something
then do not pretend it is going to work by allowing
edits to the restricted data in any 'scratchpad' database.

> Randy

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 20 May 2009 10:54:30 -0700

...
> edits to the restricted data in any 'scratchpad' database.

Isn't it a security hole to allow a user to edit and/or view
restricted data in the candidate (or any scratchpad) database?

I'm not a security guy, but it seems better to return
an access-denied error for the very highest restricted
node that is referenced.

Otherwise, a hacker can get the agent to disclose information
that may be helpful to spread the attack to other
parts of the system (e.g., determine the features and exact objects
implemented on the agent).

If I am not authorized to view the /foo subtree
in the running config, then why would the agent
allow me to view a copy of this exact data in
another database?  That seems like a fairly obvious
security practice to avoid.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 May 2009 09:08:30 +0200

> restricted data in the candidate (or any scratchpad) database?

I think it is, since the edits in "candidate" performed by an
unprivileged user can be later commited inadvertently by a privileged
user.

Lada
 
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 21 May 2009 14:38:50 +0200

Hello,
So we seem to agree on access control principle number one:

1) Access control rights for the running and candidate configurations MUST be the same; because
- more read rights on candidate leads to info leaks
- more write rights on candidate might lead to inadvertent commit by a super-user
- fewer read rights on the candidate are just stupid, as you can commit it and then read the 
same stuff from the running
- fewer write rights on candidate seriously hamper candidate based work practices although they 
are not a security problem. It would also lead to some surprising behavior concerning 
discard-changes or a copy-config

Should the access rights on start-up and running also be the same? Probably yes

- Fewer read right on startup then running seems stupid, as after a restart the user will 
anyway see the stuff from startup
- fewer write rights on startup then running, seems strange but maybe OK
- more read rights on startup then running seems stupid, as startup may become the running 
anytime, in which case we will know whats there. There might be corner cases when you do some 
short term change in running, but that IS a corner case
- more write rights on startup then running (probably using copy-config) seem stupid as you can 
write to startup then after restart you get your data into running

Balazs