Kirill A. Korinsky wrote:
On Sat, 17 Oct 2026 01:52:00 +0200,
David Uhden Collado <[email protected]> wrote:
I would appreciate review of the implementation, particularly the
pledge/unveil policy mapping and its security implications.
I'm a bit puzzeled and before read your code I'd like to ask you how you had
designed your sandbox?
codex is a tool which creates a runs program in perl, python, bash and who
knwos else what; how does your sandbox is working? This tool can easly
create any python or perl programm and run it, or create AGENTS.md where
allows itself to do what it needs...
Hello Kirill,
The sandbox does not attempt to restrict which languages or programs
Codex can generate and execute. Instead, it restricts the operating
system capabilities available to those programs, regardless of whether
they are written in Perl, Python, shell, or another language.
The implementation works as follows:
1. Codex selects a permission profile and launches each sandboxed
command through a separate helper process, using the same Codex executable.
2. The helper translates the profile into unveil(2) filesystem
restrictions and pledge(2) syscall restrictions, locks the unveil
configuration, and executes the requested program.
3. The restrictions persist across execve(2) and apply to subsequently
executed programs. The target cannot expand its pledge promises or
unlock unveil.
4. The Codex controller itself remains unrestricted, as with the other
sandbox backends. Approval and escalation continue to use Codex's
existing mechanisms.
For example, under workspace-write, generated Python or Perl programs
can modify authorized workspace directories but cannot write elsewhere
through ordinary pathname operations. Protected directories such as
.git, .agents, and .codex remain read-only. Network access is controlled
separately through the inet and dns promises.
Regarding AGENTS.md, it can influence Codex's behavior, but it cannot
directly change the kernel-enforced restrictions. Even if Codex
generates instructions telling itself to bypass the sandbox, the
executed commands remain subject to the selected permission profile. Of
course, this does not prevent prompt injection from influencing the
controller or its approval requests; that is a separate concern.
There are limitations. OpenBSD's pledge/unveil interfaces cannot
reproduce every policy supported by other backends. Unsupported policies
fail closed rather than silently weakening restrictions. Also, unveil
does not mediate operations on already opened file descriptors, so
writable profiles cannot guarantee complete metadata immutability.
My intention is not to claim that pledge/unveil provides perfect
isolation against arbitrary untrusted code in Codex. It is to provide a
native OpenBSD backend that enforces Codex's existing permission
profiles within the capabilities and limitations of these interfaces.
Regards,
David.
