71–80 of 108 posts
Linux by default allows all users to read CLI arguments of running processes. While it looks like your bwrap invocation prevents the sandbox from looking at this process (--unshare-pid), any other process running on your system can read the secret.
Wish it wasn’t rust… it’s so hard to read.
Very interesting. I just started researching this topic yesterday to build something for adjacent use cases (sandboxing LLM authored programs). My initial prototype is using a wasm based sandbox, but I want something more robust and flexible. Some of my use cases are very latency sensitive. What sort of overhead are you seeing?
> zerobox --secret OPENAI_API_KEY=$OPENAI_API_KEY Linux by default allows all users to read CLI arguments of running processes. While it looks like your bwrap invocation prevents the sandbox from looking at this process (--unshare-pid), any other process running on your system can read the secret.
Earlier quoted context omitted.
For just logging would it really give any more info than a trace already does?
*strace that is - annoyingly it seems it was autocorrected away
Does Zerobox support audit logging for blocked network or file operations?
Very interesting. I just started researching this topic yesterday to build something for adjacent use cases (sandboxing LLM authored programs). My initial prototype is using a wasm based sandbox, but I want something more robust and flexible. Some of my use cases are very latency sensitive. What sort of overhead are you seeing?
Wasm sandboxes are fast for pure compute but get painful the moment LLM code needs filesystem access or subprocess spawning. And it will, constantly. Containers with seccomp filters give you near-native speed and way broader syscall support — overhead is basically startup time (~2s cold, sub-second warm). For anything IO-heavy it's not even close. We're doing throwaway containers at https://cyqle.in if anyone's curio…