Using a proper sandboxing(https://github.com/ashishb/amazing-sandbox) regularly will drastically limit the blast radius of these attacks.
Using a proper sandboxing(https://github.com/ashishb/amazing-sandbox) regularly will drastically limit the blast radius of these attacks.
Does your Docker backend run commands in rootless containers? I skimmed the code but didn't see anything to confirm this.
You can pass your favorite rootless Docker image using `--custom-docker-image` CLI parameter.
1. Docker (or any Linux container runtime, for that matter) is not intended for, designed for, or effective as a security boundary. 2. Root containers run as root on the host. The "sandboxed" processes have full capabilities, as far as the kernel is concerned with them.
This has been discussed in detail earlier - https://news.ycombinator.com/item?id=47612726
Further, on Mac OS, you can use `--mode=native` for Mac's native sandboxing (seatbelt).
> 2. Root containers run as root on the host. The "sandboxed" processes have full capabilities, as far as the kernel is concerned with them.
That's not always the case. You can run rootless containers or you can use containerization like Podman which does not run as root.
Yes, now you get my point. Do you run rootless containers (with the Docker backed) or do you run "root" containers?
Furthermore, you can use native sandboxing on macOS if you prefer.
If neither looks serious to you, then please educate me on a better sandboxing approach.
What alternative do you suggest?
Do you mean not install outside a sandbox?
If your distribution requires more than this, then it's not really a module, or combines too many non-modular components, and should be distributed differently.
The ability for npm to run scripts on any level should be removed.
Then we can go back to worrying about namespacing issues.
It's like saying "I don't trust a software app with an installer, I just want a .zip with the binaries from the same source that I will run myself"
Which is where the concept of "safe levels" come in. I should be able to install this module in such a way where file operations and process operations are not available to it. That being said, presumably, this types of infiltration would seem to be _much_ easier to spot. "Why is this web framework calling 'spawn'?"
> I just want a .zip with the binaries
I want a .zip with the _code_. Just the code. None of the packaging nonsense. My distribution can handle that.
> I should be able to install this module in such a way where file operations and process operations are not available to i
technically browser sandboxes, WASM, do this. but then you are very limited since you can only sandbox the whole app, and not one module, so if you need local file access, you need to open it up to the whole app and all it's modules
That's the definition of a sandbox, isn't it?
Even Python has that ability now. Also, `npm run dev` is running the script with full disk access.
Heck, Vscode/Cursor will auto-execute code if you open a project. And this has been actively used in the wild https://ashishb.net/security/contagious-interview/
So, amazing-sandbox at its core is nothing but a glorified docker command generator (in default mode).
It will always introduce friction, though.
Modern software development is simply too fast to be reviewed properly.