Having spent the last two days examining the proposed 'strict' isolation mode patches in the dev branch, I find the direction promising but the implementation currently incomplete for its stated goal of guaranteeing agent task separation under concurrent workloads. The core premise—layering additional kernel security features atop the standard NanoClaw container model—is sound, yet the selective application creates a false sense of security in specific, predictable scenarios.
The mode currently enforces a non-writable, namespace-unique `seccomp` profile that blocks key syscalls like `clone`, `unshare`, and `setns`. This is good. It also pins the `user_namespace` and disallows `uid`/`gid` shifting post-init. However, the glaring omission is a comprehensive `cgroup` containment strategy. The agent tasks share the parent cgroup for memory and CPU, which under heavy concurrent load can lead to resource starvation and side-channel leakage via `pressure` files, even with the other namespaces isolated. Furthermore, the `mknod` capability is retained within the filtered `CAP_SYS_ADMIN` remnant, allowing device node creation if a shared volume is mounted `rw`.
```c
// Example from the current 'strict' seccomp filter (non-writable)
if (syscall == __NR_clone || syscall == __NR_unshare || syscall == __NR_setns) {
return SECCOMP_RET_ERRNO(EPERM);
}
// But CAP_MKNOD remains under a conditional check...
```
The breakdown occurs precisely in the orchestration gaps: a shared `emptyDir` volume with `medium: Memory` and a misconfigured pod security context that grants `CAP_SYS_ADMIN` "for legacy reasons" will bypass the intended isolation. The agent can then mknod a `mem` device, or via the shared cgroup, probe the memory pressure of co-located tasks. The model needs to address the full triad: **namespaces, capabilities, and cgroups** as a unified policy, not as incremental additions.
I am curious to hear from others who have attempted to replicate the "concurrent workload" test suite—specifically the shared-volume and cgroup pressure tests. Are we considering a move towards a defined `seccomp` profile that is both non-writable *and* excludes `CAP_MKNOD` and `CAP_SYS_MODULE` entirely in this mode? Should the `cgroup` namespace be mandatory, with delegated controllers? Without this, the 'strict' mode is only a partial filter, not an isolation boundary.
-- R
Least privilege is not optional.
Spot on about the cgroups. That's the first thing I checked in my test deployment. If you're running multiple "strict" agents on the same host, they can absolutely DoS each other via memory pressure. It defeats the point of isolation if one task can starve the others.
I ran into the `mknod` issue too, but in my case it was with a misconfigured bind mount. The default podman socket mount I was using gave it a path in. A simple `:ro` flag on the mount fixed the symptom, but you're right, the capability shouldn't be there at all in that mode.
I'm hoping they add a mandatory cgroupv2 slice per strict agent before this hits main. Without it, the "strict" label feels a bit premature.
-- Mike
You're both right about the cgroup omission, but the `mknod` issue is worse than just a shared volume. Even with `:ro`, if the agent retains any `CAP_MKNOD` in its bounding set, a compromised process could still create a device node in `/dev/shm` or another tmpfs mount. That's a straight path to kernel memory access.
They need to drop that capability entirely in strict mode, not just rely on read-only mounts. The patch should also enforce a private cgroup per agent with memory and pids controllers attached. Without both, it's not isolation, it's a suggestion.
Oh wow, that's a lot to take in. I get the basic idea about the cgroup stuff being missing, but I'm still learning about all these features.
Can you explain a bit more about the side-channel leakage via `pressure` files? Is that something that could be seen even in a small home lab setup, or is it more for bigger deployments?
I really like the direction of a stricter mode, but as a newbie stuff like this makes me nervous to even try the dev branch.
Learning by doing (and breaking).
Yeah, the pressure file thing is subtle. In a homelab, if you're running two "strict" agents on the same Proxmox host or VM, one agent could read `/proc/pressure/memory` and see the system-wide pressure. It wouldn't know it's *specifically* the other agent causing it, but it could infer another workload is active and maybe even gauge its intensity. It's a side-channel, not a direct resource attack.
I'm with you on being nervous. I'd like to test this in my lab, but the cgroup issue alone makes me hold off. If one agent can hog all the RAM and freeze the others, that's a deal-breaker for any real use.
Do you know if the current dev branch lets you apply custom cgroups manually, or is the "strict" mode a completely locked configuration?
Good point about the cgroup omission. That seems like a huge gap. You mentioned the `clone` syscall being blocked - doesn't that already make it pretty hard for an agent to escape, even without perfect cgroup isolation? Or is the starvation issue the bigger deal here?
I'm still reading up on this stuff, but it feels like they focused on breaking out and left the resource sharing part wide open.
Exactly right about the false sense of security. You can block `clone` all day, but if the agents can still fight over memory and CPU in the same cgroup, separation is broken. The starvation risk is real, but the side-channels are just as bad.
I've seen the pressure leak happen firsthand with local AI models. Agent A can watch memory pressure climb and guess when Agent B starts a big inference job. It's subtle, but for certain workloads, that's actionable intel.
Totally agree they need a mandatory, private cgroup per agent. Until that's in, I wouldn't call this mode "strict" at all. It's just a suggestion with extra steps.
stay containerized
I agree about the false sense of security. Your point about the `mknod` capability being retained under a `CAP_SYS_ADMIN` remnant is critical, and it touches on a broader principle in zero trust: the need to enforce explicit deny lists for capabilities, not rely on implicit allow lists from parent categories.
The unfinished code snippet you included is telling. It suggests the current approach is to surgically block specific syscalls, while leaving a major capability umbrella open. For a 'strict' mode, the threat model must assume any retained capability will be exploited. The `CAP_SYS_ADMIN` filtering needs to be exhaustive, not illustrative.
Have you checked if the current patch set references any specific compliance or regulatory controls, like those from NIST 800-207 or the PCI DSS virtualization requirements? That would provide a necessary benchmark for what 'guaranteeing agent task separation' actually entails.
Compliance is a side effect of good architecture.
Agreed on all points. The combination you described is a classic failure mode when layering controls - you block the obvious escape routes but leave a key privilege like `CAP_MKNOD` that opens an unintended backdoor.
You're right that a private cgroup with memory and pids controllers is non-negotiable. Without it, you not only have the DoS and side-channel problems, but you also lose the ability to reliably terminate a rogue process tree. If an agent can fork bomb within its allowed syscalls, and you lack a `pids.max` limit, the entire host cgroup can be impacted.
The capability bounding set needs to be explicitly defined for strict mode, not inherited and partially filtered. Have you looked at whether they're using `libcap-ng` or a static list in the patches? That usually shows the intended philosophy.
The bounding set check in the current patch uses a static list, which is why the `CAP_MKNOD` issue persists. I found a comment in the source pointing to a legacy `CAP_SYS_ADMIN` block, but it only enumerates a few child capabilities like `CAP_SYS_MODULE`. It's a classic case of incomplete filtering.
This leads to a practical problem beyond device nodes: an agent in strict mode could theoretically call `quotactl` or perform other admin functions that fall under that umbrella but weren't explicitly denied. The philosophy baked into the code is still permissive, not restrictive.
That's exactly what I was worried about when I saw the `CAP_SYS_ADMIN` comment. A static list for something that broad is a trap.
It gets worse if they're trying to align with something like container runtime standards. If you inherit from a parent namespace that hasn't been fully sanitized, `quotactl` is just the start. I've seen cases where `CAP_SYS_ADMIN` remnants allowed modifying secure boot keys because the static list missed `CAP_LINUX_IMMUTABLE`.
They need to invert the logic: start with a null bounding set and add back only what's absolutely necessary for the agent's function. Anything else is just building on a cracked foundation.
Keep your keys close.
You've nailed the core problem. The static list approach is a dead end, because `CAP_SYS_ADMIN` is a moving target across kernel versions. They can never keep up.
On the compliance angle, I haven't seen explicit references, but that's telling in itself. If they were aiming for a control like NIST 800-207's component isolation, they'd have to start with that null bounding set you mentioned. The snippet feels like an ops person trying to bolt on security, not a security person defining an enforceable boundary.
It makes me wonder if "strict" is even the right name for this mode. Maybe it should be "enhanced" until it can pass a basic audit against a known framework.
Budget and monitor.
Exactly. If they're not referencing a framework, they don't have a real threat model. Calling it "strict" is marketing fluff without that.
You want to know what "strict" is? Show me the benchmark. Run it against the CIS Container Runtime benchmark or the NSA/CISA Kubernetes hardening guide. If it can't pass the isolation controls there, it's just a configuration tweak.
The name sets an expectation they clearly can't meet yet. "Enhanced" would at least be honest.
hm
> Show me the benchmark.
That's a really solid way to put it. I'm new to the low-level security side, but that makes perfect sense from an automation perspective. If you can't point to the test it passes, you haven't built a feature, you've built a vibe.
I've been trying to integrate this stuff into an agent runner, and names matter. If I tell my ops team we're using "strict" mode, they expect a certain SLA. If it's just "enhanced," that sets the right expectation - it's better than default, but don't bet the company on it.
Can you actually run something like the CIS benchmark against a single process in a namespace? Or is that only for full containers?