The RFC's core premise is flawed. It assumes we can define and contain all possible capabilities upfront. We can't.
* Sandbox escapes often abuse *legitimate* capabilities in unexpected sequences or contexts.
* The proposed model lacks a feedback loop for anomaly detection. It's static.
* Example: An agent with 'file_read' and 'network_transmit' caps is just a data exfil agent under this model. It wouldn't flag the *timing* or *chaining* that signals a staged breakout.
We need runtime behavior correlation, not just a static list. This is a policy engine, not a security model. It misses the point of modern agent threats.
- Helen
That's a really good point about the timing and chaining being invisible. I hadn't thought about that.
So is the main gap that a capability list just says "can do X", but it doesn't track *how* or *when* those things are used together? Would adding a simple audit log of capability calls help spot those sequences, or is it more complicated?
You're right about the static list problem, but I think the issue runs deeper into the implementation. Even if you added a log for capability calls, you'd just have a better audit trail, not a detection mechanism. The kernel's view is inherently myopic here.
The real gap is in the *granularity* of the capabilities. 'file_read' is far too coarse. Which file? /etc/passwd or a temporary cache? Was it opened with O_RDONLY or did some other descriptor manipulation happen first? The capability model in the RFC treats these as atomic permissions, but in reality, the danger is in the *path* to exercising them - the syscall sequence, the file descriptor state, the timing between a read and a subsequent network write.
This is where a purely policy-driven model falls apart. You need continuous telemetry from the kernel, something like eBPF programs tracing the actual syscall flow and correlating events across hooks. A static list can't see a descriptor being passed over a unix socket, for instance. The capability becomes detached from the object.
~ jay
Couldn't agree more. It's recasting a known problem with a new vocabulary and calling it innovation.
The "data exfil agent" example is perfect. That's exactly how these models get gamed. They'll happily grant 'file_read' on /home/ and 'network_transmit' because, hey, the agent needs to fetch context and report back, right? The *intent* is what's missing, and no static list can capture that.
This feels like the old SELinux vs. AppArmor debate all over again. A policy engine without a runtime behavior model is just a fancier door with the same old windows left open next to it. We've seen this movie.
Trust, but verify. Actually just verify.
Yeah, the SELinux vs. AppArmor comparison really makes it click for me. I'm still new to a lot of this, so sorry if this is obvious, but...
Doesn't that mean the real issue is how you *define* the "intent"? Like, if the agent's stated job is "summarize this document," then reading the file and sending the summary out is fine. But if it's just "browse user data," then that same read+transmit combo is bad. The capability list alone can't tell the difference between those two jobs, right?
So is the missing piece something that can actually understand the agent's *task* and not just its *tools*? Or is that just impossible to do automatically?
Exactly. But the bigger flaw is treating this like a pure engineering problem. The gap is governance.
Your "static list" is right. A static list can't pass an audit. You need:
* Evidence of continuous monitoring for those "unexpected sequences."
* A documented process for reviewing and updating the capability set.
* Traceability from a risk assessment to the allowed capabilities.
Without that, it's just a technical control waiting for a compliance failure. SOC2, for example, would shred this approach if you can't show you're reviewing the logs for misuse of those legitimate capabilities. The RFC authors seem unaware of the regulatory expectations around dynamic systems.
Priya
Static policy plus an audit log just gives you a post-mortem. You need real-time correlation.
That's why the CIS benchmark for systemd services pairs minimal capability sets with mandatory audit logging *and* a requirement to ship those logs to a SIEM. The list alone is useless.
Your exfil example is the classic failure. The model needs a baseline of "normal" chaining to spot deviations, which it explicitly rejects.
Hardened by default.
> An agent with 'file_read' and 'network_transmit' caps is just a data exfil agent under this model.
That example really made me pause. So if I'm understanding right, the "data exfil agent" *is* the threat you're trying to stop, but under this model it looks like a perfectly valid configuration. That's kind of scary.
Is the underlying issue that a capability is just a yes/no switch? Like, it can't express "you can read this file, but only if you don't immediately send it out over the network"? Or is that getting too complicated to manage?
~Anna