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.
linux-modules-cleanup.service runs with no systemd sandboxing (9.6 UNSAFE)
Reported by drneb99 · filed Aug 31, 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
Title: linux-modules-cleanup.service runs with no systemd sandboxing (9.6 UNSAFE)
Body:
systemd-analyze security linux-modules-cleanup.service scores 9.6 UNSAFE on a stock Omarchy 4.0.1 install — this is one of the worst-scoring services Omarchy enables by default. It's a oneshot (WantedBy=basic.target) that only ever needs to touch /usr/lib/modules (via rsync -AHXal + rm -rf on stale, pacman-unowned kernel module trees), so it's a good candidate for a drop-in override rather than needing any change to the service's actual logic.
Similar in spirit to #8627 (the CUPS hardening PR) — same pattern, different service.
Verified locally, not just proposed blind: applied the override below as a real drop-in, created a fake stale module tree (a directory under /usr/lib/modules/ not owned by any package) to simulate the real cleanup scenario, and ran systemctl start linux-modules-cleanup.service under the sandbox. It correctly moved the stale tree into /usr/lib/modules/.old/ and exited 0 with no journal errors. Confirmed the resulting score drops to 6.0 MEDIUM.
One deliberate omission: ProtectKernelModules=yes is not included, even though it's a common hardening directive, because man systemd.exec is explicit that it makes /usr/lib/modules inaccessible — which would break this exact service. Worth calling out in case anyone's tempted to add it as an "obvious" extra.
Proposed fix — etc/systemd/system/linux-modules-cleanup.service.d/10-omarchy.conf:
[Service]
# Cleanup only ever touches /usr/lib/modules; strict + one write path is enough
ProtectSystem=strict
ReadWritePaths=/usr/lib/modules
ProtectHome=yes
PrivateNetwork=yes
PrivateTmp=yes
ProtectClock=yes
ProtectKernelLogs=yes
ProtectKernelTunables=yes
ProtectControlGroups=yes
ProtectHostname=yes
NoNewPrivileges=yes
RestrictNamespaces=yes
RestrictSUIDSGID=yes
RestrictRealtime=yes
LockPersonality=yes
MemoryDenyWriteExecute=yes
SystemCallArchitectures=nativeNo migration needed (unlike the recent sysctl fixes) — this is a oneshot that re-reads its unit file on every invocation, so the drop-in takes effect on the next run/boot with no runtime state to reapply.
Happy to open a PR for this if useful.
System info: Omarchy 4.0.1 (BUILD_ID 4.0.1), kernel 7.1.9-arch1-2
View raw text
Title: linux-modules-cleanup.service runs with no systemd sandboxing (9.6 UNSAFE) Body: `systemd-analyze security linux-modules-cleanup.service` scores **9.6 UNSAFE** on a stock Omarchy 4.0.1 install — this is one of the worst-scoring services Omarchy enables by default. It's a oneshot (`WantedBy=basic.target`) that only ever needs to touch `/usr/lib/modules` (via `rsync -AHXal` + `rm -rf` on stale, pacman-unowned kernel module trees), so it's a good candidate for a drop-in override rather than needing any change to the service's actual logic. Similar in spirit to #8627 (the CUPS hardening PR) — same pattern, different service. **Verified locally**, not just proposed blind: applied the override below as a real drop-in, created a fake stale module tree (a directory under `/usr/lib/modules/` not owned by any package) to simulate the real cleanup scenario, and ran `systemctl start linux-modules-cleanup.service` under the sandbox. It correctly moved the stale tree into `/usr/lib/modules/.old/` and exited 0 with no journal errors. Confirmed the resulting score drops to **6.0 MEDIUM**. One deliberate omission: `ProtectKernelModules=yes` is *not* included, even though it's a common hardening directive, because `man systemd.exec` is explicit that it makes `/usr/lib/modules` inaccessible — which would break this exact service. Worth calling out in case anyone's tempted to add it as an "obvious" extra. **Proposed fix** — `etc/systemd/system/linux-modules-cleanup.service.d/10-omarchy.conf`: ```ini [Service] # Cleanup only ever touches /usr/lib/modules; strict + one write path is enough ProtectSystem=strict ReadWritePaths=/usr/lib/modules ProtectHome=yes PrivateNetwork=yes PrivateTmp=yes ProtectClock=yes ProtectKernelLogs=yes ProtectKernelTunables=yes ProtectControlGroups=yes ProtectHostname=yes NoNewPrivileges=yes RestrictNamespaces=yes RestrictSUIDSGID=yes RestrictRealtime=yes LockPersonality=yes MemoryDenyWriteExecute=yes SystemCallArchitectures=native ``` No migration needed (unlike the recent sysctl fixes) — this is a oneshot that re-reads its unit file on every invocation, so the drop-in takes effect on the next run/boot with no runtime state to reapply. Happy to open a PR for this if useful. System info: Omarchy 4.0.1 (BUILD_ID 4.0.1), kernel 7.1.9-arch1-2
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 10:13 UTC