DF-2706 — kern.proc.pid.<pid> bypasses security.ps_showallprocs=0

Unprivileged local information disclosure / authorization bypass in sysctl_kern_proc() (sys/kern/kern_proc.c).

Build

On the guest (any user):

cc -O -o /tmp/pidsnoop /tmp/pidsnoop.c

Run

Root prepares a root-owned marker process and turns the visibility knob off:

cp /bin/sleep /tmp/snoopmark && chmod 700 /tmp/snoopmark
nohup /tmp/snoopmark 600 &            # uid-0 process, pid noted
sysctl security.ps_showallprocs=0

Unprivileged user runs the A/B/C contrast:

/tmp/pidsnoop <root-pid>   # [A] kern.proc.pid.<pid>  (raw-MIB form)
/tmp/pidsnoop -all         # [B] kern.proc.all        (gated path)
/tmp/pidsnoop -uid 0       # [C] kern.proc.uid.0      (gated path)

Expected output (vulnerable kernel)

[A] kern.proc.pid.<pid> -> 1 record(s)
    pid=<pid> ppid=1 uid=0 pgid=.. sid=.. comm="snoopmark"
    kp_paddr (kernel heap ptr) = 0xfffff8..          <-- BYPASS
[B] kern.proc.all       -> 3 record(s)   (only the caller's own)
[C] kern.proc.uid.0     -> 0 records

[A] returning the full struct kinfo_proc of a uid-0 process (including the raw kernel-heap pointer kp_paddr) while [B]/[C] correctly hide it proves the KERN_PROC_PID fast path skips the ps_showallprocs/p_trespass() gate that all sibling selectors enforce.

Root cause

sys/kern/kern_proc.c:1686-1694 — the oid == KERN_PROC_PID fast path only applies PRISON_CHECK(cr1, crcache) (jail boundary), then calls sysctl_out_proc() unconditionally. The main enumeration loop applies the visibility gate at kern_proc.c:1715-1721 (ps_showallprocs == 0 → p_trespass(cr1, crcache) → continue), and KERN_PROC_PGRP/TTY/UID/RUID all flow through it; only KERN_PROC_PID dodges it. Reachability of the branch with an arbitrary trailing pid component is provided by kern_sysctl.c:1476-1478, which forwards trailing MIB components to a node handler (sysctlnametomib("kern.proc.pid") + append pid; the string form kern.proc.pid.<pid> does not name-resolve — that is why sysctl(8) alone does not expose it, but any C program trivially does).

DF-2706 VERDICT — kern.proc.pid. bypasses security.ps_showallprocs

Status: REPRODUCED (impact: leak — visibility-control bypass / kernel-pointer re-disclosure), confidence: certain.

What was claimed

sysctl_kern_proc()'s KERN_PROC_PID fast path (sys/kern/kern_proc.c:1686-1694) omits the ps_showallprocs == 0 → p_trespass() visibility gate that the main enumeration loop applies (kern_proc.c:1715-1721). Consequence: with security.ps_showallprocs=0 (the knob admins set on shared multi-user boxes to hide other users' processes), any unprivileged local user can still retrieve the complete struct kinfo_proc of any pid — including uid-0 daemons — by walking kern.proc.pid.<pid> for pid in 1..99999. The record includes kp_comm, credentials, session/pgrp ids, signal state, and the raw kernel-heap pointer kp_paddr (re-enabling the DF-0179/DF-0016 address disclosure that the knob is supposed to gate for untrusted users).

How it was verified (guest: DragonFly 6.5-DEVELOPMENT, stock INVARIANTS

kernel #0, uname -a in env.txt)

1. Root started a uid-0 marker (/tmp/snoopmark, a copy of /bin/sleep), pid 893, and set security.ps_showallprocs=0.
2. Unprivileged user (uid 1001) built and ran pidsnoop (build.log / run.log): - [A] kern.proc.pid.893 → 1 record: pid=893 ppid=1 uid=0 pgid=890 sid=890 comm="snoopmark", kp_paddr=0xfffff80116aa9180 — full disclosure of a root process. - [B] kern.proc.all → 3 records — only the caller's own processes (gate enforced on the main loop). - [C] kern.proc.uid.0 → 0 records — gate enforced on the uid selector.
3. Stability re-run (run.2.log) reproduced [A] byte-identically and additionally disclosed pid 1 (comm="init", kp_paddr=0xfffff80089977280).
4. Guest left clean: knob restored to 1, marker killed, no kernel state dirtied.

The A/B/C contrast isolates the defect to the KERN_PROC_PID branch: sibling selectors through the same handler honor the knob; only the pid fast path bypasses it.

PoC fixes vs the naive approach

sysctlbyname("kern.proc.pid.<pid>") fails with ENOENT: DFly's name2oid does not register per-pid children of the node. The branch is reached via the raw MIB — sysctlnametomib("kern.proc.pid", mib, &len) then mib[len++] = pid — because kern_sysctl.c:1476-1478 forwards trailing MIB components into the node handler as arg1/arg2. This is exactly how the sysctl(8) string form would work if the resolver supported numeric children; it is a 3-line C program.

Why this matters / impact ceiling

• Metadata of every process (names, uids/gids, sessions, pgrps, signal masks, thread lists with _lwp variants) → process-table reconnaissance that the admin explicitly disabled.
• kp_paddr / kl_wchan / kp_ktaddr raw kernel pointers (DF-0179/DF-0016) remain readable per-pid even with the knob at 0 → KASLR-defeat mitigation value of the knob is void.
• No memory corruption; read-only disclosure. Severity Low (requires the non-default hardened setting; default ps_showallprocs=1 shows everything anyway).

Fix

Gate the fast path exactly like the main loop (fix.diff):

        crcache = pcredcache(crcache, p);
-       if (PRISON_CHECK(cr1, crcache))
+       if (PRISON_CHECK(cr1, crcache) &&
+           (ps_showallprocs || !p_trespass(cr1, crcache))) {
            error = sysctl_out_proc(p, req, flags);
+       }
        PRELE(p);

Fix validated: not rebuilt (one-line logic gate, non-memory-corruption class; contract mandates kernel rebuild validation only for memory-corruption findings). The behavioral A/B/C proof above pins the code path unambiguously.