Clarify and harden cleanroom rules around reference executable instrumentation

从当前的 ProgramBench 和 mini-SWE-agent 指令以及 issue 中描述的推荐 Docker 设置开始。将明确允许的黑盒探测与对环境、loader、进程状态和文件系统的插桩进行比较，然后确定文档化的 cleanroom 边界是否足够，或者是否需要一个隔离的结构化 oracle harness。规则以及（如果继续实施）harness 的行为明确且可复现，即视为完成。

Hi ProgramBench team, thanks for releasing the benchmark.

I wanted to ask for clarification about the intended cleanroom boundary for the provided reference executable during inference.

The current ProgramBench / mini-SWE-agent instructions are very clear that agents should infer behavior only by running the provided executable and reading bundled documentation. The default ProgramBench config also disallows internet access (--network none), runs as a non-root user, and drops SYS_PTRACE. The prompt explicitly forbids source lookup, wrapping/reusing the original binary, decompilation/disassembly, and strace/ltrace or similar instrumentation.

My question is whether the following should also be explicitly considered cleanroom violations, which I have observed during inference of my tested model:

• executing the reference with a polluted environment, e.g. PATH=/tmp:$PATH ./executable ... to make it call agent-written fake dependencies
• using loader instrumentation such as LD_PRELOAD, LD_LIBRARY_PATH, or dynamic linker tricks against ./executable
• inspecting runtime process state via /proc/$pid/{maps,fd,environ,cmdline} or core/memory dumps
• changing cwd/tmp/config files specifically to observe implementation-level effects rather than normal public CLI behavior

These are different from normal allowed black-box probing, such as running ./executable --help, passing inputs, and observing stdout/stderr/exit codes/filesystem side effects.

The current recommended Docker setup appears to run the agent and the reference executable in the same container. This blocks important classes of abuse (--network none, non-root user, SYS_PTRACE dropped), but it does not fully isolate the true reference executable from agent-controlled environment variables, writable /tmp/workspace state, PATH/cwd pollution, or same-container process observation.

Would you consider either:

1. documenting the above behaviors explicitly as disallowed instrumentation/wrapping of the oracle, and/or
2. adding an optional hardened inference harness where the true reference executable runs behind a separate sanitized oracle process/container, with the agent only able to issue structured black-box execution requests?

This is not intended as a security vulnerability report. It is a benchmark semantics / reproducibility question: the goal is to ensure scores measure behavioral inference from the public interface, not implementation-level oracle instrumentation.