4 ms·
This is a good explanation of how standard filesystem sandboxing works, but it's hopefully not trying to be convincing to security engineers. > At Greptile, we
by thundergolfer 1y ago
This is a good explanation of how standard filesystem sandboxing works, but it's hopefully not trying to be convincing to security engineers.
> At Greptile, we run our agent process in a locked-down rootless podman container so that we have kernel guarantees that it sees only things it’s supposed to.
This sounds like a runc container because they've not said otherwise. runc has a long history with filesystem exploits based on leaked file descriptors and `openat` without NO_FOLLOW.
The agent ecosystem seems to have already settled on VMs or gVisor[2] being table-stakes. We use the latter.
1. https://github.com/opencontainers/runc/security/advisories/GHSA-xr7r-f8xq-vfvv https://github.com/opencontainers/runc/security/advisories/G...
2. https://gvisor.dev/docs/architecture_guide/security/ https://gvisor.dev/docs/architecture_guide/security/
- ujrvjhtifcvlvvi 1y agoif you don't mind me asking: how do you deal with syscalls that gVisor has not implemented?
- thundergolfer 1y agogVisor has implemented a lot of them, but every few months we have an application that hits an unimplemented syscall. We tend to reach for application workarounds, and haven't yet landed a PR to add a syscall. But I'd expect we could land such a PR.
- zobzu 1y agochroot'ing isn't sandboxing or "containers". And I don't think it's a very good explanation, actually - not that its necessarily easy to explain. It looks like the author just discovered the kernel and syscalls and is sharing it - but, it's not exactly new or rocket science. The author probably should use the existing sandbox libraries to sandbox their code - and that has nothing to with AI Agents actually, any process will benefit from sandboxing, that it runs on LLM replies or not.