4 ms·
On Linux, chroot(2) is hard to escape and would apply to all child processes without modification.
by PaulDavisThe1st 7mo ago
On Linux, chroot(2) is hard to escape and would apply to all child processes without modification.
- shakna 7mo agochroot 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.
- brianush1 7mo agoclaude is stupid but not malicious; chroot is sufficient
- nofriend 7mo agoMalice is not required. If it thinks it is in the right, then it will do whatever it takes to get around limitations.
- karhagba 7mo agoClaude is far from stupid from my experience. I've used so many models and Claude is king.
- furyofantares 7mo agoI'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.
- j16sdiz 7mo agobreaking a chroot takes more than that..
- hoppp 7mo agoThat doesn't mean claude can't do it, chroot is better than nothing but not a real solution
- furyofantares 7mo agoHow much more? Depends on the system doesn't it? I don't know how many systems have proc mounted but don't you get it from /proc/self/root? Anyway that's beside the point, which is that it doesn't have to "be malicious" to try to overcome what look like errors on its way to accomplishing the task you asked it to do.
- lxgr 7mo agoUntil 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?
- fl7305 7mo agoSure, it's not malicious. But it is very eager to get things done, and surprisingly inventive and knowledgeable in all kinds of workarounds.
- safety1st 7mo agoWe 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.
- search_facility 7mo agoExactly!
- jon-wood 7mo agoOh 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.
- lxgr 7mo ago> 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.)
- jmalicki 7mo agoIt's still possible to give some restricted access to your personal data, through groups and such.
- wasted_intel 7mo agoThat 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."