3.4 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-1952 | fixed | 2026-10-10 | apiserver | security | 2026-10-10T08:15:16Z | 2026-10-10T08:15:16Z | 1 |
|
|
|
383 | fixed | d6676e7948f8 |
bug-1952: apiserver user role changes check a narrower rbac:control grant only against the target user
Description
Observed: (source reading, .kiro/reviews/project-gap-review-2026-10-10.md (P0); to be confirmed by a failing test before the fix)
Suspected (needs verification): in add/delete roles for a user, a non-all rbac:control grant is only checked against "is the target me?" (controllers/users.go:404-412,455-462), so such a grant could let a user give itself cluster_admin. Built-in roles grant rbac:control only with domain all (config/rbac.yaml:100-102), so this is latent.
Expected: A user can never grant itself a role with more rights than it already holds.
Impact: Security (latent): privilege escalation through a custom role.
Found by: review: .kiro/reviews/project-gap-review-2026-10-10.md (P0)
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 @ 94472ee3-dirty
- Deployment: any (found by source reading; the failing test that confirms it is named in Verification)
Reproduction
- Define a role with
rbac:controlscoped toself, assign it to a user, then addcluster_adminto that same user via the users API.
- 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
UserController.AddRolesForUser/DeleteRolesForUser (controllers/users.go) only checked whether the target was the caller for a non-all rbac:control grant; self is an accepted rbac scope (models/roles.go:78), so a user holding only rbac:control scope self could grant itself cluster_admin.
Fix
canChangeUserRoles: changing anyone's roles (the caller's included) requires an rbac:control grant with scope all, checked over all grants before deduplication; anything else gets 403. Follow-up: any rbac:control scope can still create roles and add permissions to a role the caller holds (roles.go), the same escalation by another route.
Verification
- Test:
TestAddRolesForUser_SelfScopeCannotGrantItselfRoles(controllers/users_rbac_test.go): REDprivilege escalation: mallory (rbac:control scope self) granted itself cluster_admin (status 200), GREEN after; plusTestDeleteRolesForUser_SelfScopeRejected,TestUserRoleChanges_AllScopeAllowed. - Suites:
xce-build.sh all asan xce.build --incrementalon the merged branch, 2026-10-10: all C suites Ok 155 / Fail 0, frontend Go unit tests ok, xceadmin tests ok; apiserverCGO_ENABLED=0 go test ./...(incl. middleware, router, cmd) ok - Live: n/a: unit/fixture-level verification only; no live deployment was run (follow-up)
References
- Fix commit:
a80768f3(onscheduler-framework; worker-branch original in the merge) - Review:
.kiro/reviews/project-gap-review-2026-10-10.md