myxce/.wolf/bugs/bug-1958.md
Rongsong Shen f45b85c9e5
docs(buglog): record Gitea sync for bug-1958..bug-1967
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-10-10 10:51:33 +00:00

3.3 KiB

id status status_updated status_note component severity timestamp last_seen occurrences files tags related fix_commits gitea_issue gitea_synced_status gitea_synced_hash
bug-1958 fixed 2026-10-10 apiserver security 2026-10-10T10:15:56Z 2026-10-10T10:15:56Z 1
src/frontend/apiserver/controllers/roles.go
apiserver
security
rbac
bug-1952
736ed81d
389 fixed a30ea70d85d6

bug-1958: apiserver lets any rbac:control grant create roles and extend its own role (privilege escalation)

Description

Observed: (source reading; follow-up of the 2026-10-10 P0 fixes (bug-1936..1957)) Reported by the bug-1952 fix: role create/update in controllers/roles.go accepts any rbac:control scope, so a user holding rbac:control with scope self can add cluster:control (or any permission) to a role it already holds: the same escalation bug-1952 closed for user-role assignment, by another route.

Expected: Creating roles or changing a role's permissions requires rbac:control with scope all (as user-role changes do since bug-1952). Impact: Security: privilege escalation through role editing. Found by: follow-up of the 2026-10-10 P0 fixes (bug-1936..1957)

Environment

  • OS: no /etc/os-release; Docker container; NixOS kernel; kernel Linux 6.18.33 x86_64
  • libc: glibc 2.42-47 (interpreter /nix/store/wb6rhpznjfczwlwx23zmdrrw74bayxw4-glibc-2.42-47/lib/ld-linux-x86-64.so.2)
  • Toolchain: gcc (GCC) 15.2.0, meson 1.9.1
  • Build: asan (xce.build)
  • Code: scheduler-framework @ 19be145d-dirty
  • Deployment: any (found by source reading; confirmed by the RED test of the fix)

Reproduction

  1. Give user mallory a role with rbac:control scoped self.
  2. As mallory, add cluster:control (domain all) to that role through the roles API; it is accepted.
  • Frequency: deterministic (by code reading; confirmed by the RED test of the fix)
  • Evidence: the code sites quoted in Description; no logs kept.

Root cause

CreateRole, AddPermissionsForRole and DeleteRoleAndPermissions (controllers/roles.go) were guarded only by the route's RequirePermission("rbac:control"), which accepts any scope, so a self-scoped grant could add cluster:control to a role its holder has. Pre-existing.

Fix

New checkRoleChangePermission() in roles.go, called first in the three handlers, reuses canChangeUserRoles (bug-1952; all grants before deduplication) and answers 403 unless the caller holds rbac:control with scope all.

Verification

  • Test: TestAddPermissionsForRole_SelfScopeCannotExtendOwnRole (controllers/roles_rbac_test.go): RED roles_rbac_test.go:65: privilege escalation: mallory (rbac:control scope self) added cluster:control to its own role (status 200); TestCreateRole_SelfScopeRejected, TestDeleteRole_SelfScopeRejected RED (status 200, want 403); GREEN after, plus TestRoleChanges_AllScopeAllowed.
  • Suites: xce-build.sh all asan xce.build --incremental on the merged branch, 2026-10-10: C suites Ok 157 / Fail 0; frontend Go tests ok (the build now also runs apiserver cmd, middleware, models and router)
  • Live: n/a: unit/fixture-level verification; no live deployment was run

References

  • Fix commits: 736ed81d (on scheduler-framework)
  • Found as a follow-up of the 2026-10-10 P0 fixes (bug-1936..1957)