I've been conducting a security review of our NemoClaw deployment's NeMo Inference Microservice (NIM) containers, with a specific focus on hardening runtime privileges. As part of this, I've been attempting to enforce a custom AppArmor profile to restrict the container's capabilities beyond the default Docker runtime. However, the container consistently fails to start when the profile is applied, exiting with a non-zero code and sparse logs.

The core of my issue appears to be a conflict between the profile's denials and the NIM container's runtime expectations. I have constructed a profile based on a principle of least privilege, denying writes to most of the filesystem, restricting network access to only necessary ports, and limiting capability sets. The container's `docker run` command is as follows:

```bash
docker run --rm
--name test-nim
--security-opt "apparmor=nim-hardened"
-p 8080:8080
nvcr.io/nvidia/nemo/nemoinfer:latest
```

The container logs, obtained via `docker logs` on the briefly extant container, are not particularly verbose but hint at a failure during initial model loading or internal initialization. The relevant entries from `/var/log/syslog` showing AppArmor denials are:

```
type=AVC msg=audit(1678901234.567:890): apparmor="DENIED" operation="open" profile="nim-hardened" name="/proc/self/status" pid=12345 comm="python3" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
type=AVC msg=audit(1678901234.568:891): apparmor="DENIED" operation="mknod" profile="nim-hardened" name="/dev/urandom" pid=12345 comm="python3" requested_mask="w" denied_mask="w" fsuid=0 ouid=0
```

My primary questions for the community are:

* What are the specific filesystem locations, kernel interfaces (e.g., `/proc`, `/sys`), and special device nodes (e.g., `/dev/`) that a NIM container requires for standard operation? The NVIDIA documentation is silent on mandatory runtime permissions.
* Has anyone successfully deployed NIM containers under a custom, restrictive AppArmor or SELinux policy? If so, what were the critical allow rules?
* Beyond simple filesystem access, which Linux capabilities (e.g., `CAP_NET_BIND_SERVICE` for binding to port 8080, `CAP_SYS_PTRACE` for any internal profiling) are absolutely required? The default Docker profile may grant a broad set.

My immediate goal is to construct a functional baseline profile. The longer-term security objective is to share a hardened template that can be adapted for production deployments, particularly those where the NIM endpoint is exposed via the OpenClaw plugin API and must adhere to strict container isolation standards. Any insights from those who have delved into the runtime behavior of these inference containers would be invaluable.

- Lei