News for hackers. Stuff that matters.
Re:Don't YOLO your file system by PaulDavisThe1st on Friday March 27, 2026 @11:44PM (#47551401)
On Linux, chroot(2) is hard to escape and would apply to all child processes without modification.
Re:Don't YOLO your file system by shakna on Friday March 27, 2026 @11:50PM (#47551442)
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.

Re:Don't YOLO your file system by brianush1 on Saturday March 28, 2026 @12:06AM (#47551527)
claude is stupid but not malicious; chroot is sufficient
Re:Don't YOLO your file system by nofriend on Saturday March 28, 2026 @12:16AM (#47551576)
Malice is not required. If it thinks it is in the right, then it will do whatever it takes to get around limitations.
Re:Don't YOLO your file system by karhagba on Saturday March 28, 2026 @12:20AM (#47551596)
Claude is far from stupid from my experience. I've used so many models and Claude is king.
Re:Don't YOLO your file system by furyofantares on Saturday March 28, 2026 @12:43AM (#47551702)
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.
Re:Don't YOLO your file system by j16sdiz on Saturday March 28, 2026 @01:58AM (#47552029)
breaking a chroot takes more than that..
Re:Don't YOLO your file system by hoppp on Saturday March 28, 2026 @10:11AM (#47554795)
That doesn't mean claude can't do it, chroot is better than nothing but not a real solution
Re:Don't YOLO your file system by furyofantares on Saturday March 28, 2026 @01:09PM (#47556472)
How 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.

Re:Don't YOLO your file system by lxgr on Saturday March 28, 2026 @07:08AM (#47553489)
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?
Re:Don't YOLO your file system by fl7305 on Saturday March 28, 2026 @02:59PM (#47557305)
Sure, it's not malicious. But it is very eager to get things done, and surprisingly inventive and knowledgeable in all kinds of workarounds.
Re:Don't YOLO your file system by safety1st on Saturday March 28, 2026 @03:23AM (#47552370)
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.

Re:Don't YOLO your file system by search_facility on Saturday March 28, 2026 @04:01AM (#47552532)
Exactly!
Re:Don't YOLO your file system by jon-wood on Saturday March 28, 2026 @04:46AM (#47552771)
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.
Re:Don't YOLO your file system by lxgr on Saturday March 28, 2026 @07:06AM (#47553481)
> 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.)

Re:Don't YOLO your file system by jmalicki on Sunday March 29, 2026 @12:34AM (#47560415)
It's still possible to give some restricted access to your personal data, through groups and such.
Re:Don't YOLO your file system by gwking on Saturday March 28, 2026 @10:41AM (#47555036)
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.

Re:Don't YOLO your file system by afzalive on Monday March 30, 2026 @12:44AM (#47570462)
Someone tried this earlier this year but they ended up going with bubblewrap (what Anthropic uses for the sandbox). Here's the blog if you're interested. https://patrickmccanna.net/a-better-way-to-limit-claude-code...

I ended up creating an LXC on my homelab and providing it access there, with a self-hosted gitea server but that's only for side projects that I want to host, not develop actively.

Re:Don't YOLO your file system by wasted_intel on Saturday March 28, 2026 @10:32AM (#47554975)
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."