Comment by staticassertion
2 days ago
What would be really helpful is if software sandboxed itself. It's very painful to sandbox software from the outside and it's radically less effective because your sandbox is always maximally permissive.
But, sadly, there's no x-platform way to do this, and sandboxing APIs are incredibly bad still and often require privileges.
> It's easy to patch the security model of Linux with userspaces, and even easier with eBPF, but the community is somehow stuck.
Neither of these is easy tbh. Entering a Linux namespace requires root, so if you want your users to be safe then you have to first ask them to run your service as root. eBPF is a very hard boundary to maintain, requiring you to know every system call that your program can make - updates to libc, upgrades to any library, can break this.
Sandboxing tooling is really bad.
If the whole point of sandboxing is to not trust the software, it doesn't make sense for the software to do the sandboxing. (At most it should have a standard way to suggest what access it needs, and then your outside tooling should work with what's reasonable and alert on what isn't.) The android-like approach of sandboxing literally everything works because you are forced to solve these problems generically and at scale - things like "run this as a distinct uid" are a lot less hassle if you're amortizing it across everything.
(And no, most linux namespace stuff does not require root, the few things that do can be provided in more-controlled ways. For examples, look at podman, not docker.)
> If the whole point of sandboxing is to not trust the software, it doesn't make sense for the software to do the sandboxing.
That's true, sort of. I mean, that isn't the whole point of sandboxing because the threat model for sandboxing is pretty broad. You could have a process sandbox just one library, or sandbox itself in case of a vulnerability, or it could have a separate policy / manifest the way browser extensions do (that prompts users if it broadens), etc. There's still benefit to isolating whole processes though in case the process is malicious.
> (And no, most linux namespace stuff does not require root, the few things that do can be provided in more-controlled ways. For examples, look at podman, not docker.)
The only linux namespace that doesn't require root is user namespace, which basically requires root in practice. https://www.man7.org/linux/man-pages/man2/clone.2.html
Podman uses unprivileged user namespaces, which are disabled on the most popular distros because it's a big security hole.
> It's very painful to sandbox software from the outside and it's radically less effective because your sandbox is always maximally permissive.
Not really.
Let's say I am running `~/src/project1 $ litellm`
Why does this need access to anything outside of `~/src/project1`?
Even if it does, you should expose exactly those particular directories (e.g. ~/.config) and nothing else.
How are you setting that sandbox up? I've laid out numerous constraints - x-platform support is non-existent for sandboxing, sandboxing requires privileges to perform, whole-program sandboxing is fundamentally weaker, maintenance of sandboxing is best done by developers, etc.
> Even if it does, you should expose exactly those particular directories (e.g. ~/.config) and nothing else.
Yes, but now you are in charge of knowing every potential file access, network access, or possibly even system call, for a program that you do not maintain.
> Yes, but now you are in charge of knowing every potential file access, network access, or possibly even system call, for a program that you do not maintain.
Not really. I try to capture the most common ones for caching [1], but if I miss it, then it is just inefficient, as it is equivalent to a cache miss.
I'll emphasize again, "no linter/scanner/formatter (e.g., trivy) should need full disk access".
1 - https://github.com/ashishb/amazing-sandbox/blob/fddf04a90408...
7 replies →