Comment by PaulDavisThe1st
20 hours ago
On Linux, chroot(2) is hard to escape and would apply to all child processes without modification.
20 hours ago
On Linux, chroot(2) is hard to escape and would apply to all child processes without modification.
We anthropomorphize these agents in every other way. Why aren't we using plain ol' unix user accounts to sandbox them?
They look a lot like daemons to me, they're a program that you want hanging around ready to respond, and maybe act autonomously through cron jobs are similar. You want to assign any number of permissions to them, you don't want them to have access to root or necessarily any of your personal files.
It seems like the permissions model broadly aligns with how we already handle a lot of server software (and potentially malicious people) on unix-based OSes. It is a battle-tested approach that the agent is unlikely to be able to "hack" its way out of. I mean we're not really seeing them go out onto the Internet and research new Linux CVEs.
Have them clone their own repos in their own home directory too, and let them party.
Openclaw almost gets there! It exposes a "gateway" which sure looks like a daemon to me. But then for some reason they want it to live under your user account with all your privileges and in a subfolder of your $HOME.
> for some reason they want it to live under your user account
The entire idea of Openclaw (i.e., the core point of what distinguishes it from agents like Claude Code) is to give it access to your personal data, so it can act as your assistant.
If you only need a coding agent, Openclaw is the completely wrong tool. (As a side note, after using it for a few weeks, I'm not convinced it's the right tool for anything, but that's a different story.)
I tried this with Claude code on macOS. I created a new agent user and a wrapper do run Claude has that user, along with some scripts to set permissions and ownership so that I could run simple allow/deny commands. The only problem was that the fancy oauth flow broke. I filed an issue with Anthropic and their ticket bot auto closed it “for lack of interest” or whatever.
I fiddled with transferring the saved token from my keychain to the agent user keychain but it was not straightforward.
If someone knows how to get a subscription to Claude to work on another user via command line I’d love to know about it.
Oh that’s an idea. I was going to argue that it’s a problem that you might want multiple instances in different contexts but sandboxing processes (possibly instanced) is exactly what systemd units are designed to deal with.
Exactly!
That comparison is made on the project homepage:
"Not a security mechanism. No mount isolation, no PID namespace, no credential separation. Linux documents it as not intended for sandboxing."
chroot is not a security sandbox. It is not a jail.
Escaping it is something that does not take too much effort. If you have ptrace, you can escape without privileges.
claude is stupid but not malicious; chroot is sufficient
Sure, it's not malicious. But it is very eager to get things done, and surprisingly inventive and knowledgeable in all kinds of workarounds.
I've many times seen Claude try to execute a command that it's not supposed to, the harness prevents it, and then it writes and executes a python script to do it.
3 replies →
Malice is not required. If it thinks it is in the right, then it will do whatever it takes to get around limitations.
Until it gets prompt injected. Are you reading every single file your agent reads as part of the tasks you give it, including content fetched from the web or third-party packages?
Claude is far from stupid from my experience. I've used so many models and Claude is king.