Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
`gsr-kms-server` ships with `cap_sys_admin` (root-equivalent capability)
Reported by helioryn · filed Aug 25, 2026 · open at source
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- AreaOutside the audited area· Decided by agents · verified
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
System details
Intel(R) Core(TM) i3-10110U CPU @ 2.10GHz
What's wrong?
/usr/bin/gsr-kms-server, provided by the gpu-screen-recorder package, is installed with the
Linux capability cap_sys_admin=ep.
CAP_SYS_ADMIN is the most powerful capability and is
effectively root — it permits mounts, namespace manipulation, module loading, and other
security-sensitive operations. Granting it to an unprivileged helper binary creates a large
attack surface: any bug or misuse in that binary becomes a local privilege-escalation to root.
Impact / Severity
High — a root-equivalent capability on a non-root process.
getcap output:
$ getcap /usr/bin/gsr-kms-server
/usr/bin/gsr-kms-server cap_sys_admin=ep
$ ls -l /usr/bin/gsr-kms-server
-rwxr-xr-x 1 root root 22624 <date> /usr/bin/gsr-kms-server
$ pacman -Qo /usr/bin/gsr-kms-server
/usr/bin/gsr-kms-server is owned by gpu-screen-recorder 6.0.1-1
Expected behaviour
A screen-recording helper should use the narrowest capability required for its task
(e.g. access to the DRM/KMS device). CAP_SYS_ADMIN is far broader than needed and should
not be granted to a user-space helper by default.
Steps to reproduce
1. Install gpu-screen-recorder.
2. Inspect capabilities:
getcap /usr/bin/gsr-kms-server- Observe
cap_sys_admin=ep.
Observed while auditing local privilege-escalation paths
This binary was surfaced by a capability sweep and, combined with the running element,
represents a candidate attack surface for unprivileged users on a system where privileges
are otherwise correctly constrained.
Environment
| Field | Value |
|---|---|
| OS | Omarchy 4.0.1 (ID=omarchy, ID_LIKE=arch) |
| Kernel | linux 7.1.9.arch1-2 |
| Architecture | x86_64 |
| Host | HP ProBook 450 G7 |
| Session | Wayland (DESKTOP_SESSION=omarchy) |
| Package | gpu-screen-recorder 6.0.1-1 |
Suggested fix
- Drop the capability from the binary where possible: sudo setcap -r /usr/bin/gsr-kms-server.
- If CAP_SYS_ADMIN is genuinely required, scope it via a dedicated unprivileged service or
systemd CapabilityBoundingSet instead of the file capability, and restrict access to the
device.
- Alternatively, run the recorder's helper as the same user (not root) using getprivs /
setpriv with only the required permissions.
Additional context
A related lower-severity observation: /usr/bin/btop is installed withcap_dac_read_search,cap_perfmon=ep, which bypasses file read permission checks and could
allow reading /etc/shadow. Recommend stripping that too (sudo setcap -r /usr/bin/btop).
View raw text
### System details Intel(R) Core(TM) i3-10110U CPU @ 2.10GHz ### What's wrong? `/usr/bin/gsr-kms-server`, provided by the `gpu-screen-recorder` package, is installed with the Linux capability `cap_sys_admin=ep`. `CAP_SYS_ADMIN` is the most powerful capability and is effectively root — it permits mounts, namespace manipulation, module loading, and other security-sensitive operations. Granting it to an unprivileged helper binary creates a large attack surface: any bug or misuse in that binary becomes a local privilege-escalation to root. Impact / Severity **High** — a root-equivalent capability on a non-root process. `getcap` output: $ getcap /usr/bin/gsr-kms-server /usr/bin/gsr-kms-server cap_sys_admin=ep $ ls -l /usr/bin/gsr-kms-server -rwxr-xr-x 1 root root 22624 <date> /usr/bin/gsr-kms-server $ pacman -Qo /usr/bin/gsr-kms-server /usr/bin/gsr-kms-server is owned by gpu-screen-recorder 6.0.1-1 Expected behaviour A screen-recording helper should use the narrowest capability required for its task (e.g. access to the DRM/KMS device). `CAP_SYS_ADMIN` is far broader than needed and should not be granted to a user-space helper by default. Steps to reproduce 1. Install `gpu-screen-recorder`. 2. Inspect capabilities: ```sh getcap /usr/bin/gsr-kms-server ``` 3. Observe `cap_sys_admin=ep`. Observed while auditing local privilege-escalation paths This binary was surfaced by a capability sweep and, combined with the running element, represents a candidate attack surface for unprivileged users on a system where privileges are otherwise correctly constrained. Environment | Field | Value | |---|---| | OS | Omarchy 4.0.1 (`ID=omarchy`, `ID_LIKE=arch`) | | Kernel | `linux 7.1.9.arch1-2` | | Architecture | x86_64 | | Host | HP ProBook 450 G7 | | Session | Wayland (`DESKTOP_SESSION=omarchy`) | | Package | `gpu-screen-recorder 6.0.1-1` | Suggested fix - Drop the capability from the binary where possible: `sudo setcap -r /usr/bin/gsr-kms-server`. - If `CAP_SYS_ADMIN` is genuinely required, scope it via a dedicated unprivileged service or systemd `CapabilityBoundingSet` instead of the file capability, and restrict access to the device. - Alternatively, run the recorder's helper as the same user (not root) using `getprivs` / `setpriv` with only the required permissions. Additional context A related lower-severity observation: `/usr/bin/btop` is installed with `cap_dac_read_search,cap_perfmon=ep`, which bypasses file read permission checks and could allow reading `/etc/shadow`. Recommend stripping that too (`sudo setcap -r /usr/bin/btop`).
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
- Out of scopeDecided by agents · verified · 2026-10-09 09:07 UTC