How to globally hide sync-to operation with NACM?

[JimBoucher]

Hi, I am trying to hide the use of the sync-to functionality in the webui-one interface (at least) using NSO 5.2.0.3.

Hiding "devices sync-to" is easy.

<cmdrule xmlns="http://tail-f.com/yang/acm">
<name>c_devices_syncto</name>
<command>devices sync-to</command>
<action>deny</action>
</cmdrule>

<cmdrule xmlns="http://tail-f.com/yang/acm">
<name>j_devices_syncto</name>
<command>request devices sync-to</command>
<action>deny</action>
</cmdrule>

The problem is with denying sync-to for a specific device. I have tried a dozen options and the Admin Guide does not give any cmdrule examples beyond the trivial no-list case.  Can you point me in the right direct? None of these work:

<command>devices device '$DEVICE' sync-to</command>

<command>devices device $DEVICE sync-to</command>

<command>devices device sync-to</command>

<command>sync-to</command>

<command>devices device '[a-z]*' sync-to</command>

<command>/devices/device[name='$DEVICE']/sync-to</command>

And so on.  Thanks in advance for your help!

Jim

ADDED:

I have also tried using rule and a path. Here is my test config (that isn't working) using the rule approach:

admin@ncs# show running-config nacm
nacm enable-nacm true
nacm read-default permit
nacm write-default permit
nacm exec-default deny
nacm groups group admin
user-name [ admin private system ]
gid 1000
!
nacm groups group ncsadmin
user-name [ nsoadmin private ]
gid 1500
!
nacm groups group ncsoper
user-name [ oper public ]
gid 2000
!
nacm groups group oper
user-name [ oper public ]
!
nacm rule-list admin
group [ admin ]
rule any-access
action permit
!
cmdrule any-command
action permit
log-if-permit
!
!
nacm rule-list any-group
group [ * ]
rule tailf-aaa-password-change
module-name tailf-aaa
path /aaa/authentication/users/user[name='$USER']/change-password
access-operations read,exec
action permit
!
rule tailf-aaa-user
module-name tailf-aaa
path /user[name='$USER']
access-operations create,read,update,delete
action permit
!
rule tailf-webui-user
module-name tailf-webui
path /webui/data-stores/user-profile[username='$USER']
access-operations create,read,update,delete
action permit
!
cmdrule c-logout
command logout
action deny
!
cmdrule j-logout
command "request system logout"
action deny
!
!
nacm rule-list ncsadmin
group [ ncsadmin ]
rule a_devices_read
module-name tailf-ncs
path /ncs:devices
access-operations read
action permit
!
rule a_devices_device_read
module-name tailf-ncs
path /ncs:devices/device[name='$DEVICE']
access-operations read
action permit
!
rule a_devices_device_syncto
module-name tailf-ncs
path /ncs:devices/device[name='$DEVICE']/sync-to
access-operations read,exec
action deny
!
rule a_devices_syncto
module-name tailf-ncs
path /ncs:devices/sync-to
access-operations read,exec
action deny
!
rule any-access
action permit
!
cmdrule c-logout
command logout
action deny
log-if-permit
!
cmdrule j-logout
command "request system logout"
action deny
log-if-permit
!
cmdrule any-command
action permit
log-if-permit
!
!
nacm rule-list ncsoper
group [ ncsoper oper ]
rule tailf-aaa-user
module-name tailf-aaa
path /user[name='$USER']
access-operations create,read,update,delete
action permit
!
rule tailf-webui-user
module-name tailf-webui
path /webui/data-stores/user-profile[username='$USER']
access-operations create,read,update,delete
action permit
!
rule tailf-aaa-alluser
module-name tailf-aaa
path /user
action deny
!
rule tailf-aaa-aaa
module-name tailf-aaa
path /aaa
action deny
!
rule nacm
module-name ietf-netconf-acm
path /
action deny
!
rule a_devices_read
module-name tailf-ncs
path /ncs:devices
access-operations read
action permit
!
rule a_devices_device_read
module-name tailf-ncs
path /ncs:devices/device[name='$DEVICE']
access-operations read
action permit
!
rule a_devices_device_syncto2
module-name tailf-ncs
path /ncs:devices/device[name='$DEVICE']/sync-to
access-operations exec
action deny
!
rule a_devices_syncto2
module-name tailf-ncs
path /ncs:devices/sync-to
access-operations exec
action deny
!
rule read-only
path /
access-operations read
action permit
!
cmdrule c-logout
command logout
action deny
log-if-permit
!
cmdrule j-logout
command "request system logout"
action deny
log-if-permit
!
cmdrule any-command
action permit
log-if-permit
!
!
nacm cmd-read-default deny
nacm cmd-exec-default deny

[JimBoucher]

Here is an example of the not-working command rules approach I am working with.

nacm enable-nacm true
nacm read-default permit
nacm write-default permit
nacm exec-default deny
nacm groups group admin
user-name [ admin private system ]
gid 1000
!
nacm groups group ncsadmin
user-name [ nsoadmin private ]
gid 1500
!
nacm groups group ncsoper
user-name [ oper public ]
gid 2000
!
nacm groups group oper
user-name [ oper public ]
!
nacm rule-list admin
group [ admin ]
rule any-access
action permit
!
cmdrule any-command
action permit
log-if-permit
!
!
nacm rule-list any-group
group [ * ]
rule tailf-aaa-password-change
module-name tailf-aaa
path /aaa/authentication/users/user[name='$USER']/change-password
access-operations read,exec
action permit
!
rule tailf-aaa-user
module-name tailf-aaa
path /user[name='$USER']
access-operations create,read,update,delete
action permit
!
rule tailf-webui-user
module-name tailf-webui
path /webui/data-stores/user-profile[username='$USER']
access-operations create,read,update,delete
action permit
!
cmdrule c-logout
command logout
action deny
!
cmdrule j-logout
command "request system logout"
action deny
!
!
nacm rule-list ncsadmin
group [ ncsadmin ]
rule any-access
action permit
!
cmdrule c_devices_syncto
command "devices sync-to"
action deny
log-if-permit
!
cmdrule c_device_syncto
command "devices device '$DEVICE' sync-to"
action deny
log-if-permit
!
cmdrule j_devices_syncto
command "request devices sync-to"
action deny
log-if-permit
!
cmdrule j_device_syncto
command "request devices device '$DEVICE' sync-to"
action deny
log-if-permit
!
cmdrule c-logout
command logout
action deny
log-if-permit
!
cmdrule j-logout
command "request system logout"
action deny
log-if-permit
!
cmdrule any-command
action permit
log-if-permit
!
!
nacm rule-list ncsoper
group [ ncsoper oper ]
rule tailf-aaa-user
module-name tailf-aaa
path /user[name='$USER']
access-operations create,read,update,delete
action permit
!
rule tailf-webui-user
module-name tailf-webui
path /webui/data-stores/user-profile[username='$USER']
access-operations create,read,update,delete
action permit
!
rule tailf-aaa-alluser
module-name tailf-aaa
path /user
action deny
!
rule tailf-aaa-aaa
module-name tailf-aaa
path /aaa
action deny
!
rule nacm
module-name ietf-netconf-acm
path /
action deny
!
rule read-only
path /
access-operations read
action permit
!
cmdrule c_devices_syncto
command "devices sync-to"
action deny
log-if-permit
!
cmdrule c_device_syncto
command "devices device '$DEVICE' sync-to"
action deny
log-if-permit
!
cmdrule j_devices_syncto
command "request devices sync-to"
action deny
log-if-permit
!
cmdrule j_device_syncto
command "request devices device '$DEVICE' sync-to"
action deny
log-if-permit
!
cmdrule c-logout
command logout
action deny
log-if-permit
!
cmdrule j-logout
command "request system logout"
action deny
log-if-permit
!
cmdrule any-command
action permit
log-if-permit
!
!
nacm cmd-read-default deny
nacm cmd-exec-default deny

[rogaglia]

This is working for me:

nacm rule-list oper
group [ oper ]
rule oper-sync-to
path /ncs:devices/ncs:sync-to
access-operations exec
action deny
log-if-permit
!
!

Note that "access-operation = exec" should be used for acitons and rpcs.

[JimBoucher]

The example you gave is for "devices sync-to" which is the example I showed working in cmdrule form above.  Can you provide a rule example that works for "devices device * sync-to"?

Thanks,

Jim

[JimBoucher · Accepted solution]

I figured it out. Thanks for clarifying that I had to use rule instead of cmdrule. At this point, I am assuming anything for a YANG Model is done with rule and only Cisco  Tailf CLI extension commands should be done with cmdrule. Please let me know if this is incorrect. 

nacm rule-list ncsadmin
group [ ncsadmin ]
rule a_devices_device_syncto
module-name tailf-ncs
path /ncs:devices/device/sync-to
access-operations exec
action deny
!

Thanks,

Jim

[lmanor]

Jim,

To try to clarify the difference between NACM 'cmdrule' and 'rule'.

The definition of 'cmdrule' (from yang model, tailf-acm.yang):

description
"One command access control rule. Command rules control access
to CLI commands and Web UI functions.

So the cmdrule will permit/deny depending on the explicit matching of the rule's command string and  the command entered into the cli (it does not limit access to a node or sub-nodes of the cdb model) - nothing is implied from the rule, example denying a command for a range of devices would not deny the command for each of the devices:

admin@ncs% show nacm rule-list testrules

group [ testgrp ];

cmdrule no-sync-cmd {

    command "request devices sync-to";

    action  deny;

}

cmdrule no-sync-dev {

    command "request devices device ios-0..1 sync-to";

    action  deny;

}

cmdrule no-sync-dev-1 {

    command "request devices device ios-0 sync-to";

    action

}

A command that explicitly matches the cmdrule command string is denied (actually the sub-command is just not available):

testuser@ncs% request devices device ios-0..1 sync-to

                                              ^

% Invalid input detected at '^' marker.

But a sync-to for individual devices within the specified range is permitted since the cmdrule command string is not explicitly matched:

testuser@ncs% request devices device ios-1 sync-to

result true

Then second type of NACM rule is 'data authorization' which permits/denies access to a 'node' (and perhaps sub-nodes) of the CDB.

As you have seen here, the nacm 'rule' points to a node in the CDB tree - defined by the path, and determines the permit/deny criteria on:

"A rule matches if 'module-name', 'rule-type', and 'access-operations' match the request. 

If a rule matches, the 'action' leaf determines if access is granted or not."

Any cli (or other API) attempting to access the node specified in the rule will be permitted/denied access to the node.

The sync-to node is defined as an action in the model, and therefore the exec access-operation is applicable.

[JimBoucher]

Thanks for the clarification and example. I am still wondering about cmdrule and the general case (as mentioned I have it working now with a rule, but I am curious).  I tried the following but it did not work. I tried a '*' too but it was rejected.

<command>devices device '[a-z]*' sync-to</command>

Thanks,

Jim

[lmanor · Accepted solution]

Hi Jim,

So the command needs to be a valid NSO CLI command - which isn't a linux-like syntax, so wildcarding and regex you are perhaps used to will likely not work here.

In your example:

    devices device '[a-z]*' sync-to

NSO CLI cannot handle the '[a-z]*,

The device name, which this value represents, can be an individual device name (xr-0), a range of 'like' device names (xr-0..10), all devices of a prefix (xr-*), or 'all' devices (*).

Examples (all devices are netsims, therefor the same addr):

testuser@ncs% show devices device ios-0 address | tab
address 127.0.0.1;

testuser@ncs% show devices device xr-0..1 address | tab

NAME ADDRESS
-----------------
xr-0 127.0.0.1
xr-1 127.0.0.1

testuser@ncs% show devices device xr-* address | tab

NAME ADDRESS
-----------------
xr-0 127.0.0.1
xr-1 127.0.0.1

testuser@ncs% show devices device * address | tab

NAME ADDRESS
------------------
ios-0 127.0.0.1
ios-1 127.0.0.1
j-0 127.0.0.1
j-1 127.0.0.1
xr-0 127.0.0.1
xr-1 127.0.0.1

That said, by trial I have found that the cmdrule will not work when the command string contains the '*' wildcard.

I suspect that the '*' on the command line gets expanded prior to comparing it against the cmdrule string and does not match - just speculation.

So, the cmd will work as expected when the command string contains a single device name or a range of like devices.

So, I think you are prudent in pursuing the 'rule' to deny execution of the sync-to.

[JimBoucher]

Thanks for verifying that there really is a limitation with cmdrule that can be overcome using rule instead.  Are you considering raising a bug against cmdrule (low priority of course)?

[lmanor]

Actually, from this discussion and revisiting the NSO Admin guide, I believe what we are seeing is the intended behavior.

From doc:

"If the group leaf-list in a rule-list entry matches any of the user's groups, the cmdrule list entries are examined for command authorization, while the rule entries are examined for rpc, notification, and data authorization."

Given this statement, permitting/denying access to elements defined in the CDB - including exec or actions such as per-device sync-form/to which can be accessed through many commands (e.g. many devices in command) should be handled through the use of 'rule' entries.

'cmdrules' being use for to permit/deny execution of system or global commands such as 'configuration' to disallow/permit ability to access config, or 'request system logout' or 'request packages reload' or 'request devices sync-to', etc.

Please make an enhancement request if you think this feature could better work differently or if you feel the documentation could better explain.

[jandy33]

I've tried this solution with request devices device <devicename> sync-to and the process continued. I've also updated the rule-list with path /ncs:devices/device[name='$DEVICE']/sync-to and it also continued processing.

Thanks

Jim A.