lainOS/protocol-7-core
lainOS/protocol-7-core
3
0
Fork 0
Code Issues Pull requests Projects Releases 11 Packages Wiki Activity Actions
11 releases 11 tags
  • 5.5.3-25 ac1d375f8b

    protocol7-core-5.5.3-25 Stable

    amnesia released this 2026-07-17 12:25:51 +02:00 | 3 commits to main since this release

    protocol7-core-5.5.3-25 ~ Changelog

    Security Hardening

    • lainos-notifyd and lainos-dbus-bridge: explicitly cleared the Linux capability bounding set (CapBnd) during privilege drop, via a prctl(PR_CAPBSET_DROP, ...) loop over all capabilities, called before setuid() while CAP_SETPCAP is still held.

    Background: prompted by an external review of the security analysis document, which asked a precise, fair question this document had not previously answered: does the privilege drop clear Linux capabilities, or only UID/GID? Rather than answer from kernel-semantics reasoning alone, this was checked directly via /proc/<pid>/status on the live, running daemons.

    Finding: setuid()'s standard kernel behavior already cleared the effective and permitted capability sets (CapEff/CapPrm both confirmed zero, directly, before any change was made). The capability bounding set (CapBnd) is a separate mechanism, not cleared by setuid() alone, and still showed the full root bounding set ~ a ceiling on capabilities the process could regain, for example via a later execve of a file with capabilities set. Not a fix for a live vulnerability (effective/permitted capabilities were already correctly zero), but a real, previously-unverified residual, closed as defense-in-depth.

    Fix: added a prctl(PR_CAPBSET_DROP, cap, 0, 0, 0) loop (0 through CAP_LAST_CAP) to both daemons' drop_privileges(), positioned before the existing setgid()/setuid() calls. Requires <sys/prctl.h> and <linux/capability.h>, added to both files.

    Verification:

    • Re-checked via /proc/<pid>/status post-fix on both daemons ~ all five capability fields (CapInh, CapPrm, CapEff, CapBnd, CapAmb) now read zero, confirmed on the actual running production processes, not just a test build.
    • Full dfuzzer 2.6 regression pass on lainos-dbus-bridge ~ Exit status: 0, all methods/properties PASS; functional D-Bus smoke test (CanReboot) confirmed correct.
    • Valgrind memcheck on both daemons (seccomp-bypass debug-build methodology, matching established practice) ~ 0 errors, 0 leaks; reachable-memory baselines match prior releases exactly (19,837 bytes/79 blocks for dbus-bridge; consistent figures for notifyd under real exercised traffic from a live Tor service restart) ~ confirming the capability change introduced no functional or memory-safety regression.
    • Binary hashes (md5sum) re-confirmed matching between the tested build and the actual production binaries running on the system.

    Note on process: this is the second real finding in this project surfaced by someone other than the primary author reviewing the security documentation itself, rather than the code directly ~ the security analysis document's own precision and willingness to state open questions plainly is what made this question askable in the first place.

    Downloads