2026-09-11 — privilege elevation (sudo / su / Fileman prompt)

Follow-up security repair

The original safety claims below were invalidated by a follow-up review: the production password checker returned boolean success while its sudo adapter expected zero, accepting wrong passwords; ordinary-account password verification also polluted the administrator cache. Both now have production regressions and fixes. Additional repairs isolate service descriptors, private connections, command slots, stdio/cwd and privileged file-operation results. See docs/SUDO_AND_ELEVATION.md's repair section for the current trust boundary, protocol migration, evidence and remaining limitations. Earlier "no guest run" text describes the original submission, not subsequent validation.

Scope of the change

Added a privileged broker in authd plus sudo, su, a fixed-path worker (sudod) and a Fileman elevation prompt. The kernel, the public ABI headers and the SDK are unchanged: the mechanism relies entirely on the fact that authd already runs as uid 0 and that only uid 0 may assume another identity.

Trust boundary

Unchanged in kind, extended in surface: every privileged request is served by an authd_sudo_*_from_peer handler, and the caller's identity is the SO_PEERCRED uid recorded when the connection was accepted. Request payloads carry what to do, never who is asking. tools/test_security_regressions.py --strict asserts this dispatch shape in addition to the existing kernel uid==0 gates.

What is defended

Identity spoofing: a client cannot claim a uid, a role or a cached window.
Impersonation between ordinary accounts: the target account's own password is required, and a cached administrator window does not substitute for it.
Arbitrary program execution through the file-operation path: the worker path is fixed by the daemon and is not client-controlled.
Path escape through the broker: /proc, /sys, /dev, .. components and relative paths are refused by both the daemon and the worker.
Secret handling: passwords are never persisted or logged and are erased from the client stack after use.

What is NOT defended

Malicious GUI code. FILEOP path arguments originate in Fileman and are in the same trust chain as the daemon. An attacker able to run GUI code and persuade the user to enter an administrator password holds the equivalent of a legitimate authorization. Per-program authorization (a sudoers-style policy) is the prerequisite for defending this, and is out of scope.
Denial of service. No rate limit on privileged requests within a window.
Auditability. No audit log of privileged operations.
Runtime verification. Image packaging could not complete on the build host (fakeroot cannot chown, EINVAL), so no guest run was performed and the end-to-end behaviour is unproven. See docs/SUDO_AND_ELEVATION.md.

Unchanged non-goals

File setuid/setgid execution remains unimplemented, and this change does not alter that: docs/POSIX_PERMISSIONS_2026-09-08.md stays accurate as written.