gi-dellav/zerostack

> sandboxing via --sandbox is the recommended way to protect zerostack

Sandboxing is generally a good idea, but it really is orthogonal, and it is too crude for many operations. E.g. for automating many workflows you really want to give limited write access to some folder for specific operations, and sandboxing generally only makes it a yes/no option.

Have a look into how OpenAI Codex does this, it seems a bit better.

In general, it's best when harnesses allow the user to control precisely which execve commands which which arguments are allowed.
See https://github.com/RooCodeInc/Roo-Code/issues/11095 for some ideas.

> Could you try to launch Claude Code with its suggestions to try to patch it out?

I won't have time for that, and I am not even a zerostack user. Pointing this out is just a drive-by contribution out of general interest for safe, free-software coding harnesses.

Thanks, will add as configurable in v1.2.0 (later today, together with some TUI improvements)

Yes, I have to admit that the permission system was an afterthought, as sandboxing via --sandbox is the recommended way to protect zerostack.

Could you try to launch Claude Code with its suggestions to try to patch it out?

Thanks,
G.

@billywhizz the option "-Zlocation-detail=none" was complaining here about using the 'nigthly' toolchain, I removed it and still got a working static binary.

It should simply be a configurable value instead of a hardcoded string, I guess.

https://github.com/gi-dellav/zerostack/blob/69a4cb0c20f3b2598d65210adf882f119baffd70/src/sandbox.rs#L19

In this case, it makes sense to support also [dash](https://git.kernel.org/pub/scm/utils/dash/dash.git), which is the default and very lean shell on debian and ubuntu.

This would be excellent! Following

Not the OP, but I think that would be a quite valuable patch. One of the big selling points of this project is that, since it's so tiny and easy to compile statically, you can stick it in a whole host of places where ordinary systems may not tread.

Curious if an LLM ever had a look at that code, because for me Claude Opus 4.6 says the below for prompt

> Explore https://github.com/gi-dellav/zerostack to check wether its permission model to allow "safe" commands as stated in the README is unsafe.

(Note I have not verified everything that Claude says here, I was merely curious if it would find what I found above.)

## Security Analysis of zerostack's Permission Model — Top 3 Findings

### 1. **Trivial Bypass via Shell Metacharacters (CRITICAL)**

The permission checker in [`checker.rs`](https://github.com/gi-dellav/zerostack/blob/69a4cb0c20f3b2598d65210adf882f119baffd70/src/permission/checker.rs#L98) calls `pattern.matches(input)` where `input` is the **entire raw command string** passed to bash. The pattern matching in [`pattern.rs`](https://github.com/gi-dellav/zerostack/blob/69a4cb0c20f3b2598d65210adf882f119baffd70/src/permission/pattern.rs#L21) uses simple glob-to-regex conversion that matches the command as a flat string.

Th...

OK, I now actually read some code, and it's a lot unsafer than I initially thought.

The `git log **` is translated to a regex on the shell expression.

So that can be even more trivailly exploited by prompt injection, such as `git log > /etc/password` to delete all users.

https://github.com/gi-dellav/zerostack/blob/69a4cb0c20f3b2598d65210adf882f119baffd70/src/permission/pattern.rs#L47-L64

it also works with gnu on Ubuntu 22.04.

```shell
RUSTFLAGS="-C target-feature=+crt-static -Zlocation-detail=none" cargo build --release --target x86_64-unknown-linux-gnu
```

Thanks, will update the CI

I'll admit the tone was completely wrong in the original post, I do genuinely apologize for that (it was written at 2AM, but this is of course just an excuse and doesn't resolve me of basic decency).
And you're additionally right, I should have provided more simple, direct feedback.

However, "advertising", whether it be for a weekend project or elsewise, is referring to the stated features - it's what gets people to use your agent over others. I did provide feedback, and gave specific examples of why and where the security model fails as well.
In the repo:
> Permission system: four configurable modes with per-tool patterns, session allowlists, and external directory policies

On an HN comment _specifically stating why one would use this agent over others_

> 4. Permission mode; as you can see in the README, there was lots of concern around the permission model, and I landed on a 4-mode system that goes from "Restrictive" (no commands) to "YOLO" (whatever the agent wants to do" + cu...

> If you are going to advertise "_Permission system: four configurable modes with per-tool patterns, session allowlists, and external directory policies_", you should really make sure these actually work before posting your work everywhere. In it's current state, the "permissions system" is worse than nothing, as it provides a false sense of security that you will be "protected" from harmful commands. This is a massive security issue waiting to happen.
>
> * Having _any_ subset of shell commands trusted by default is egregious, especially given the below. Every bash tool call should be deny by default or not granular at all past the tool level (e.g. pi, aider).
> * Shell injection is trivial. Because the check is literally just a glob pattern, you can bypass any "allowed" command in about 100 different ways; `;`, `&&`, `|`, IFS manipulation, command substitution, process substitution, subshells - you get the point. Even if we were to ignore this, about every other command you have lis...

I understand that the security model might not be good enough, but I don't think that it's worse than Pi or Opencode.

Nonetheless, I will work on an improved permission system.

Do you have practical tips on how to improve it?

(Also, it's explicitly recommended to use bwrap sandboxing in order to avoid issues)


Thanks,
G.