Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go hard on agents, not on your filesystem

jai.scs.stanford.edu

Post reply on HN
Print view View original

111–120 of 374 posts

Re: Go hard on agents, not on your filesystem

#111

Post by willy_k »

lifis wrote: post #90
mazieres wrote: post #65

Earlier quoted context omitted.

Human author here. The fact that I don't know web design shouldn't detract from my expertise in operating systems. I wrote the software and the man page, and those are what really matter for security. The web site is... let's say not in a million years what I would have imagined for a little CLI sandboxing tool. I literally laughed out loud when claude pooped it out, but decided to keep, in part ironically but also s…

It seems that the LLM has not only designed the site, but also written the text on at least the frontpage, which is a pretty bad signal. You need to rewrite all the text and Telde it with text YOU would actually write, since I doubt you would write in that style.

Needs to? Is there some new law mandating all landing pages must contain exclusively handwritten text that people haven’t heard of?

To your actual point, the people that would take the landing page being written by an LLM negatively tend to be able to evaluate the project on its true merits, while another substantial portion of the demographic for this tool would actually take that (unfortunately, imo) as a positive signal.

Lastly, given the care taken for the docs, it’s pretty likely that any real issues with the language have been caught and changed.

Re: Go hard on agents, not on your filesystem

#112

Post by attentive »

girvo wrote: post #10
messh wrote: post #8

How is this different than say bubblewrap and others?

https://jai.scs.stanford.edu/comparison.html#jai-vs-bubblewr... > bubblewrap is more flexible and works without root. jai is more opinionated and requires far less ceremony for the common case. The 15-flag bwrap invocation that turns into a wrapper script is exactly the friction jai is designed to remove. Plus some other comparisons, check the page

bubblewrap is in many modern distros standard packages.

With all the supply chain issues these days onboarding new tools carries extra risks. So, question is if it's worth it.

Re: Go hard on agents, not on your filesystem

#113

Post by rmunn »

john_strinlai wrote: post #105
lifis wrote: post #90

Earlier quoted context omitted.

It seems that the LLM has not only designed the site, but also written the text on at least the frontpage, which is a pretty bad signal. You need to rewrite all the text and Telde it with text YOU would actually write, since I doubt you would write in that style.

any negative signal you get from the front page should probably end up cancelled out by the whole decades of experience + stanford professor thing.

Except that the "this was generated by an LLM" feeling you get from the front page would then make you automatically question whether the "decades of experience + stanford professor thing", as you put it, was true or just an LLM hallucination.

Author would, indeed, be wise to rewrite all the text appearing on the front page with text that he wrote himself.

Re: Go hard on agents, not on your filesystem

#116

Post by john_strinlai »

rmunn wrote: post #113
john_strinlai wrote: post #105

Earlier quoted context omitted.

any negative signal you get from the front page should probably end up cancelled out by the whole decades of experience + stanford professor thing.

Except that the "this was generated by an LLM" feeling you get from the front page would then make you automatically question whether the "decades of experience + stanford professor thing", as you put it, was true or just an LLM hallucination. Author would, indeed, be wise to rewrite all the text appearing on the front page with text that he wrote himself.

>question whether the "decades of experience + stanford professor thing", as you put it, was true or just an LLM hallucination.

the scs.stanford.edu domain and stanford-scs github should help with that.

Re: Go hard on agents, not on your filesystem

#117

Post by j16sdiz »

furyofantares wrote: post #85
brianush1 wrote: post #68

Earlier quoted context omitted.

claude is stupid but not malicious; chroot is sufficient

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.

breaking a chroot takes more than that..

Re: Go hard on agents, not on your filesystem

#118

Post by erinnh »

fc417fc802 wrote: post #80
enduser wrote: post #46

Earlier quoted context omitted.

By default it will automatically retry many tool calls that fail due to the sandbox with the sandbox disabled. In other words it can and will leave the sandbox. For example: Bash(swift build 2>&1 | tail -20) ⎿ warning: /Users/enduser/Library/org.swift.swiftpm/configuration is not accessible or not writable, disabling user-level cache features. warning: /Users/enduser/Library/org.swift.swiftpm/security is not accessib…

What is even the point in that case? The behavior you describe is no better than if SELinux were to automatically re-execute a process with containment disabled.

Looking at the settings, its an option:

  Configure Overrides:                                                                                                                                                       
                                                                                                                                                                             
   1. Allow unsandboxed fallback                                                                                                                                            
    2. Strict sandbox mode (current)                                                                                                                                         
                                                                                                                                                                             
  Allow unsandboxed fallback: When a command fails due to sandbox restrictions, Claude can retry with dangerouslyDisableSandbox to run outside the sandbox (falling back to  
   default permissions).                                                                                                                                                     
                                                                                                                                                                             
  Strict sandbox mode: All bash commands invoked by the model must run in the sandbox unless they are explicitly listed in excludedCommands.

Re: Go hard on agents, not on your filesystem

#119

Post by totallymike »

fc417fc802 wrote: post #79
puttycat wrote: post #75

I am still amazed that people so easily accepted installing these agents on private machines. We've been securing our systems in all ways possible for decades and then one day just said: oh hello unpredictable, unreliable, Turing-complete software that can exfiltrate and corrupt data in infinite unknown ways -- here's the keys, go wild.

People were also dismissing concerns about build tooling automatically pulling in an entire swarm of dependencies and now here we are in the middle of a repetitive string of high profile developer supply chain compromises. Short term thinking seems to dominate even groups of people that are objectively smarter and better educated than average.

“Objectively smarter” is the last descriptor I’d apply to software developers

Re: Go hard on agents, not on your filesystem

#120

Post by oefrha »

giancarlostoro wrote: post #95
mazieres wrote: post #57

Earlier quoted context omitted.

I've seen claude get confused about what directory it's in. And of course I've seen claude run rm -rf *. Fortunately not both at the same time for me, but not hard to imagine. The claude sandbox is a good idea, but to be effective it would need to be implemented at a very low level and enforced on all programs that claude launches. Also, claude itself is an enormous program that is mostly developed by AI. So to have…

In my opinion Claude should be shipped by a custom implementation of "rm" that Anthropic can add guardrails to. Same with "find" surprised they don't just embed ripgrep (what VS Code does). It's really surprising they don't just tweak what Claude uses and lock it down to where it cannot be harmful. Ensure it only ever calls tooling Claude Code provides.

You can define your own rm shell alias/function and it will use that. I also have cp/mv aliases that forces -i to avoid accidental clobbering and it confuses Claude to no end (it uses cp/mv rare enough—rarer than it should, really—that I don’t bother wasting memory tokens on it).
Post reply on HN