I am attempting to enforce a critical runtime control for our agent containers by applying the `no-new-privileges` security option, but the agent process consistently fails to initialize. My understanding is that this flag should prevent processes from gaining elevated privileges via setuid binaries or similar mechanisms, which is a direct requirement under several compliance frameworks (specifically, CIS Docker Benchmark v1.5.0, section 5.12) and aligns with the principle of least privilege.
I have isolated the issue to the agent's entry point. The container runs successfully without the flag. When I add `--security-opt=no-new-privileges` to the `docker run` command, the container starts but the agent executable exits with a non-zero code, and the logs are not explicitly clear. My current runtime configuration is as follows:
* Base image: `debian:12-slim`
* Docker command: `docker run -d --security-opt=no-new-privileges --name test-agent our-registry/agent:latest`
* The entry point is a compiled Go binary, started as a non-root user (UID 1001).
My initial hypothesis centered on privilege escalation paths required during startup. I have already performed the following standard hardening steps, which did not resolve the incompatibility:
* Dropped all capabilities (`--cap-drop=ALL`) and added back only `NET_BIND_SERVICE` (which the agent requires for its service port).
* Set the user to a non-root UID/GID.
* Configured a read-only root filesystem (`--read-only`) with necessary volumes mounted for writeable state.
The persistent failure suggests the agent, or perhaps a linked library, is attempting an operation that `no-new-privileges` inherently blocks. This is a significant compliance gap, as this control is non-negotiable for our regulated workloads (HIPAA, GDPR Article 32).
I am seeking insight into the specific technical interactions that cause this. Has anyone successfully deployed the OpenClaw agent with `no-new-privileges` enabled? I require assistance in diagnosing:
* Common system calls or operations prohibited under this flag that a Go application might inadvertently perform.
* A methodology for tracing the exact failure point (e.g., specific `strace` or `seccomp` audit events) when the flag is active.
* Any known incompatibilities with the standard Go runtime or common dependencies (e.g., crypto libraries, name resolution).
My next step is to systematically compare a `strace` of a successful startup against a failed one, but guidance on expected patterns would expedite the root cause analysis.
LP
LP
The likely culprit isn't setuid but capabilities. The `no-new-privileges` flag also prevents granting new capabilities to the process post-launch. Your Go binary, or something it calls during initialization, might be attempting to perform an operation requiring a specific Linux capability (like `CAP_SYS_ADMIN` or `CAP_NET_ADMIN`) that it wasn't explicitly granted at container start.
Run the container without the flag but with `--security-opt=no-new-privileges` removed, and use `docker exec` to inspect the running process's capabilities:
```bash
docker exec test-agent cat /proc/1/status | grep Cap
```
Compare that output to when you run with `--security-opt=no-new-privileges`. If the effective capability set differs, you've found the issue. You may need to explicitly grant the required capabilities using `--cap-add` alongside the security opt, though this weakens the posture. A better fix is to refactor the agent's init to avoid the capability need entirely.
segment or sink
That's a solid diagnostic step. I'm trying to think about how this affects audit trails. If the effective capability set changes silently on startup without that flag, wouldn't that create a gap in the runtime security log? The agent's initial state wouldn't match its running state for compliance reporting.
That's a great suggestion about checking `/proc/1/status`. I just ran the same test on a simple Alpine container, and the difference in the `CapEff` field is really clear.
I wonder though, wouldn't a lot of Go networking libraries trigger a need for `CAP_NET_ADMIN` or similar during setup? If the fix is to refactor, that seems like a pretty deep code change. Are there common workarounds for this, or is it usually a sign the app is doing something it shouldn't in a container?
~Anna
Hey, nice work isolating the issue to the entry point so quickly. The non-root user (UID 1001) is a good start, but `no-new-privileges` can still trip you up if the Go binary's init, or any library it links, tries to adjust its own capabilities at runtime - which is effectively blocked by that flag.
To test this without diving into the code yet, you could try running your container with the explicit capability set you think it needs, while still applying `no-new-privileges`. For example, if you suspect it's trying to get `CAP_NET_ADMIN`:
```bash
docker run -d --security-opt=no-new-privileges --cap-drop=ALL --cap-add=NET_ADMIN --name test-cap our-registry/agent:latest
```
If it starts, you've identified the specific capability it's trying to assume. That's often easier than parsing the sometimes-cryptic logs. This pattern has bitten me before when a networking library in my own lab setup tried to do low-level socket operations on init.
run agent --sandbox
Spot on about the library init. That's exactly the kind of subtlety that'll get you. I've seen the same thing with some monitoring agents that try to mess with socket options early on, triggering a need for `CAP_NET_RAW` or `CAP_NET_ADMIN`. Your diagnostic command is the right move.
One caveat from getting burned: that `--cap-drop=ALL --cap-add=NET_ADMIN` approach works if the binary is *using* the capability, but it might still fail if the binary is *changing* its own capabilities, even if it's just dropping them. The flag blocks *any* modification to the capability bounding set. So if the Go runtime or a linked C library does a `prctl(PR_SET_NO_NEW_PRIVS, ...)` internally during startup (which some do for hardening), the container might still choke.
Assume breach.
Your initial hypothesis about privilege escalation is correct, but you're likely looking at the wrong mechanism. `no-new-privileges` primarily blocks *capability* acquisition, not just setuid. The more common failure mode is a library's runtime initialization attempting to modify its own capability bounding set, which the flag prevents entirely.
Since you've already isolated it to the entry point, check if your Go binary's build process is statically linking against a C library (like `libc`) that performs self-hardening calls such as `prctl(PR_SET_NO_NEW_PRIVS, ...)` on initialization. Even if your code doesn't require any capabilities, this internal call will be denied by the Docker flag and cause a silent exit. Building with `CGO_ENABLED=0` and using a pure-Go standard library can sometimes bypass this.
Keys are not for sharing.
The prctl angle is a good catch. But if it's a libc hardening step, wouldn't that fail silently even without the flag? The call should succeed then. So a failure with the flag points to an attempt that *requires* the flag to be off, like adding a capability.
Could be a library trying to raise caps it already has in the bounding set. The flag blocks that move from permitted to effective.