spp_grm_cel ships no rules.xml; the officer ACL is 1,1,1,0 on both rule models, so any GRM officer can write any rule row. PR #415 deliberately excludes active/sequence from ownership re-binding (so a manager tidying an officer's rule doesn't inherit it) — but the exclusion is one-sided. An officer can:
- disable the manager's SLA-breach escalation rule (
active=False) — org-wide escalations silently off, no ownership change, no chatter trace;
- un-archive a dormant manager rule, which then runs with the manager's
[(1,'=',1)] scope;
- reorder manager routing rules (
sequence) so a different payload wins first-match.
Targeting edits re-bind (and down-scope) to the officer, so the attack fires existing manager payloads rather than crafting new ones. The rule-config menus are already manager-only (spp_grm_ticket_config_main_menu), so officer write is RPC-only reach today — a latent over-grant.
Proposed fix (mind the trap): group_grm_manager implies group_grm_officer, so an officer-scoped rule alone would also cage managers. Ship BOTH:
- manager rule:
[(1,'=',1)], all perms;
- officer rule:
[('eval_as_user_id', '=', user.id)], perm_write + perm_unlink only.
Alternative considered: reduce officers to read-only on the rule models — simpler, but contradicts the officer-authors-rules model the #379 threat narrative assumes. Decide which collaboration model is intended first.
From the PR #415 review thread on spp_grm_cel/security/ir.model.access.csv:3.
spp_grm_celships norules.xml; the officer ACL is1,1,1,0on both rule models, so any GRM officer can write any rule row. PR #415 deliberately excludesactive/sequencefrom ownership re-binding (so a manager tidying an officer's rule doesn't inherit it) — but the exclusion is one-sided. An officer can:active=False) — org-wide escalations silently off, no ownership change, no chatter trace;[(1,'=',1)]scope;sequence) so a different payload wins first-match.Targeting edits re-bind (and down-scope) to the officer, so the attack fires existing manager payloads rather than crafting new ones. The rule-config menus are already manager-only (
spp_grm_ticket_config_main_menu), so officer write is RPC-only reach today — a latent over-grant.Proposed fix (mind the trap):
group_grm_managerimpliesgroup_grm_officer, so an officer-scoped rule alone would also cage managers. Ship BOTH:[(1,'=',1)], all perms;[('eval_as_user_id', '=', user.id)], perm_write + perm_unlink only.Alternative considered: reduce officers to read-only on the rule models — simpler, but contradicts the officer-authors-rules model the #379 threat narrative assumes. Decide which collaboration model is intended first.
From the PR #415 review thread on
spp_grm_cel/security/ir.model.access.csv:3.