55 lines
3.3 KiB
Markdown
55 lines
3.3 KiB
Markdown
---
|
|
id: "bug-1958"
|
|
status: "fixed"
|
|
status_updated: "2026-10-10"
|
|
status_note: ""
|
|
component: "apiserver"
|
|
severity: "security"
|
|
timestamp: "2026-10-10T10:15:56Z"
|
|
last_seen: "2026-10-10T10:15:56Z"
|
|
occurrences: 1
|
|
files: ["src/frontend/apiserver/controllers/roles.go"]
|
|
tags: ["apiserver", "security", "rbac"]
|
|
related: ["bug-1952"]
|
|
fix_commits: ["736ed81d"]
|
|
gitea_issue: 389
|
|
gitea_synced_status: "fixed"
|
|
gitea_synced_hash: "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)
|