mirror of
https://github.com/openai/codex.git
synced 2026-05-03 02:46:39 +00:00
## Why The Linux managed-proxy bridge helpers are long-lived child processes in the sandbox networking path. Before this change they stayed dumpable and the network seccomp profile did not block cross-process memory syscalls, so another same-user process could potentially inspect or modify bridge memory instead of interacting only through the intended proxy interface. ## What changed - reuse the shared `codex-process-hardening` helper to mark bridge helper children non-dumpable before they begin serving - deny `process_vm_readv` and `process_vm_writev` in the existing network seccomp filter ## Security impact Bridge helpers are less exposed to same-user cross-process inspection or memory writes, which reduces the chance that sandboxed code can interfere with proxy support processes outside the intended IPC path. ## Verification - `cargo test -p codex-process-hardening` - `cargo test -p codex-linux-sandbox` - attempted `cargo check -p codex-linux-sandbox --target x86_64-unknown-linux-gnu`; blocked on missing `x86_64-linux-gnu-gcc` on this macOS host --------- Co-authored-by: Codex <noreply@openai.com>
codex-process-hardening
This crate provides pre_main_hardening(), which is designed to be called pre-main() (using #[ctor::ctor]) to perform various process hardening steps, such as
- disabling core dumps
- disabling ptrace attach on Linux and macOS
- removing dangerous or noisy environment variables such as
LD_PRELOAD,DYLD_*, and macOS malloc stack-logging controls