Many default permissions are too wide in NACM

[mattiaswal]

Current Behavior

NACM: move from opt-out to opt-in (secure-by-default)

Current state
factory-config ships with:

"enable-nacm": true,
"read-default": "permit",
"write-default": "permit",
"exec-default": "permit"

A newly created user without any NACM group therefore has near-full read/write/exec access. The only exceptions are nodes carrying nacm:default-deny-write / nacm:default-deny-all in their YANG models.

Note

write-default: permit deviates from the RFC 8341 default (deny).

Problems

• Every new feature/model is writable by all users until someone explicitly locks it down; users must continuously adapt their NACM rules.
• NACM extensions cannot be added to third-party (IETF) models via deviations, so annotation alone can never cover the full tree.
• exec-default: permit exposes all non-annotated RPCs/actions to any user.
• Conflicts with CRA Annex I "secure by default configuration".

Proposal

1. factory-config: write-default: deny, exec-default: deny (read-default: permit retained).
2. Ship predefined groups: admin (permit-all), operator (scoped write + selected RPCs), guest (read-only). Factory admin user in admin.
3. Defense in depth: annotate sensitive infix models regardless of defaults:
   • infix-containers: nacm:default-deny-all (privileged containers, mounts, host networking = host root; env may contain secrets)
   • firmware upgrade / factory-reset / boot-order RPCs
   • any secrets not already covered by ietf-crypto-types
   • (discuss) syslog remote, NTP, DNS
4. Audit all infix RPCs/actions for missing default-deny-all.
5. Migration: keep old defaults for upgraded configs (or move existing users into admin); new defaults for fresh factory-config.

Expected Behavior

Lets discuss!

Steps To Reproduce

No response

Additional information

No response

[jovatn]

CCB: Agree to proposal, but probably need to relax exec for calls like get config
Target 26.10