11–20 of 24 posts
pretty close to anthropic’s version, yes? or am I mistaken https://github.com/anthropic-experimental/sandbox-runtime
https://github.com/Use-Tusk/fence?tab=readme-ov-file#attribu...
This could allow finer control than the application's own sandbox offers. For example, Flatpak apps run in bubblewrap containers with all-or-nothing network permissions. Being able to restrict access by domain name would be useful.
pretty close to anthropic’s version, yes? or am I mistaken https://github.com/anthropic-experimental/sandbox-runtime
That's acknowledged in the readme though I don't know if there is a comparison https://github.com/Use-Tusk/fence?tab=readme-ov-file#attribu...
Fence adds additional controls on top of what is available on sandbox-runtime:
- Command deny rules
- SSH command filtering
- Port exposure for inbound connections (useful for running dev servers inside the sandbox). This is a key reason why I decided to create Fence - because https://github.com/Use-Tusk/tusk-drift-cli spins up users’ services locally for trace replays and Fence helps to block unintended localhost outbound connections.
- Built-in templates for common developer workflows
- Better ergonomics for violation monitoring (`fence -m` gives you real-time violation logging on both macOS and Linux via eBPF, vs sandbox-runtime where Linux requires manual strace)
In summary, Fence layers extra permission-management features for wrapping popular CLI agents. If you just need filesystem + network isolation and you're in the Node ecosystem, sandbox-runtime is great. If you want command blocking, SSH filtering, inbound port exposure, or a standalone Go binary, Fence adds that.
Can fence wrap applications that do their namespace-based sandboxing? This could allow finer control than the application's own sandbox offers. For example, Flatpak apps run in bubblewrap containers with all-or-nothing network permissions. Being able to restrict access by domain name would be useful.
When you run `fence flatpak run `, Fence creates a bwrap sandbox with its own user namespace, Flatpak then tries to create another user namespace inside, so you'd get something like `bwrap: setting up uid map: Permission denied`.
The outer sandbox doesn't grant the capability for nested namespace creation (otherwise it would defeat much of the security), so Fence can't wrap Flatpak (or similar namespace-based sandbox tools) in a useful way. Ideally you'd need something at the network level outside any sandbox.
That said, open to suggestions if anyone knows of a feasible solution.
Can fence wrap applications that do their namespace-based sandboxing? This could allow finer control than the application's own sandbox offers. For example, Flatpak apps run in bubblewrap containers with all-or-nothing network permissions. Being able to restrict access by domain name would be useful.
Unfortunately nested bubblewrap sandboxes don't work. When you run `fence flatpak run `, Fence creates a bwrap sandbox with its own user namespace, Flatpak then tries to create another user namespace inside, so you'd get something like `bwrap: setting up uid map: Permission denied`. The outer sandbox doesn't grant the capability for nested namespace creation (otherwise it would defeat much of the security), so Fence…
https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/t...
Is there anything like this for macOS?
Is there anything like this for macOS?
- https://github.com/webcoyote/clodpod: sandboxes AI agents in a MacOS virtual machine
Note: I’m the author of both of these Apache open-source projects
- can i run user submitted untrusted code in this? and can it do a pip install if user wants or an npm install?
``` fence -t code pip install requests fence -t code npm install express ```
This restricts writes to workspace + cache dirs, blocks reading credentials, limits network to allowlisted domains, and blocks dangerous commands (`rm -rf`, `npm publish`, etc).