erase /proc/PID/environ

[ThomasWaldmann]

Split off from #2525:

It might be possible to erase /proc/PID/environ using the PR_SET_MM_ENV_START prctl; if it works, it requires capabilities/root and a kernel option.

[ThomasWaldmann]

Summary

PR_SET_MM_ENV_START / PR_SET_MM_ENV_END is a dead end, but the goal behind this ticket is achievable without any privileges: overwrite the BORG_PASSPHRASE=... bytes in place inside the kernel-provided environment block. Verified on Linux (kernel 7.0, Yama ptrace_scope 0 and 1) and macOS 15.7 with small ctypes test scripts; the BSD rows below are from kernel-source knowledge only, not measured.

Why not PR_SET_MM_ENV_START

• Requires CAP_SYS_RESOURCE: measured EPERM as an unprivileged user, works as root. Root can read any process anyway, so where it works it buys nothing.
• It only moves two pointers; the bytes stay in memory.

What works instead

/proc/PID/environ is served from live memory between mm->env_start and mm->env_end. The process can get its own bounds from fields 50 and 51 of /proc/self/stat (since Linux 3.5) and wipe the string:

import ctypes, os
with open("/proc/self/stat") as f:
    fields = f.read().rsplit(")", 1)[1].split()          # fields[0] is stat field 3 (state)
env_start, env_end = int(fields[50 - 3]), int(fields[51 - 3])
region = ctypes.string_at(env_start, env_end - env_start)
assert region == open("/proc/self/environ", "rb").read()  # sanity check before writing anything
i = region.find(b"BORG_PASSPHRASE=")
if i >= 0:
    os.environ.pop("BORG_PASSPHRASE")                     # unsetenv(): libc + child processes
    ctypes.memset(env_start + i, 0, region.index(b"\0", i) - i)

• os.environ.pop("BORG_PASSPHRASE") alone does not do this: libc getenv() and child processes stop seeing the variable, but the original string stays in the block and remains visible in /proc/PID/environ (measured).
• After the in-place wipe, a same-uid reader sees the environ block with the secret gone; other variables, getenv("HOME") etc. and child environments are unaffected (measured).

Platform	Exposure channel	Who can read it	In-place wipe	Status
Linux	/proc/PID/environ, ps eww, htop e	same uid (any Yama level), root	works (bounds from /proc/self/stat)	measured
macOS 15.7	ps -E / sysctl KERN_PROCARGS2	same uid; ptrace(PT_DENY_ATTACH) does not hide it	works (memset through the environ[] pointer, taken before unsetenv)	measured
FreeBSD / NetBSD / OpenBSD	ps -e, procstat -e read ps_strings from live process memory	same uid (FreeBSD: gated by security.bsd.unprivileged_proc_debug)	should work the same way	not measured
Windows	PEB environment block via PROCESS_VM_READ	same user	unknown	not investigated

What it buys (honestly)

• Yama ptrace_scope=1 (Ubuntu default): measured that a same-uid, non-descendant process can read borg's /proc/PID/environ but gets EPERM on /proc/PID/mem (Yama only restricts PTRACE_MODE_ATTACH; environ is a PTRACE_MODE_READ check). There the environment is the only place a same-user process can get the passphrase from, so wiping closes a real gap.
• ptrace_scope=0: the same attacker can read /proc/PID/mem, so passphrase and derived AEAD keys are exposed regardless; wiping does not help against a deliberate attacker. prctl(PR_SET_DUMPABLE, 0) closes both channels (measured), but it also prevents the owner from using gdb / py-spy / strace / lsof -p on borg and is Linux-only (FreeBSD: procctl(PROC_TRACE_CTL_DISABLE); macOS: nothing equivalent).
• Accidental exposure is probably the bigger practical win: ps eww output pasted into bug reports, htop, monitoring agents that collect process environments, support bundles, systemd-coredump (COREDUMP_ENVIRON= stores /proc/pid/environ of the crashed process in the journal).
• Child processes matter more than the ticket suggests: borg2 enters the repository (which opens the store) before it reads the passphrase, and borgstore's REST-over-ssh backend spawns ssh with the inherited environment (no env=), so for ssh:// repos the ssh process carries BORG_PASSPHRASE for the whole backup. borg 1.x stripped it via prepare_subprocess_env() in remote.py; borgstore does not use that. borg mount / borg webdav daemons keep it for the whole mount lifetime, too.
• Does not help against root, against whatever launched borg with the variable already in its own block (e.g. a systemd unit with Environment=), against the PyInstaller onefile parent process that waits for the child, or against Python heap copies, swap and core dumps.

Implementation sketch

Pure Python with ctypes, no new C code, roughly 60 lines:

• A helper scrub_environment(names) in helpers/process.py: capture the values into a private dict, del os.environ[name], then wipe. Linux: bounds from /proc/self/stat, and only write if the region's bytes equal the content of /proc/self/environ (so a wrong address is never touched). macOS/BSD: scan the environ array (_NSGetEnviron() on Darwin) before deleting and memset through the pointer. Elsewhere: no-op.
• Call it at the start of Archiver.run(), before any repository is opened, so ssh, passcommand, filter processes and daemonized children never inherit the secret. Passphrase reads from the captured dict first. Restoring the values into os.environ at the end of run() keeps the in-process test suite working; the restored copy lives on the heap, so /proc/PID/environ stays clean.
• Cover BORG_PASSPHRASE, BORG_NEW_PASSPHRASE, BORG_OTHER_PASSPHRASE, probably also BORG_PASSCOMMAND (often embeds paths / secret names). prepare_subprocess_env() currently drops only BORG_PASSPHRASE.
• Tests must be subprocess-based: read /proc/PID/environ on Linux, ps -E on macOS.
• The quickstart tip recommending /proc/<PID>/environ for debugging the environment needs adjusting.

Recommendation

Implement the in-place wipe plus early removal from os.environ as low-cost defense in depth, keep BORG_PASSCOMMAND / BORG_PASSPHRASE_FD as the primary advice in the docs, and offer PR_SET_DUMPABLE=0 at most as an opt-in hardening switch.