Comment by ashishb
6 days ago
Nobody should do 'npm install' or 'pip install' on their machine.
Using a proper sandboxing(https://github.com/ashishb/amazing-sandbox) regularly will drastically limit the blast radius of these attacks.
6 days ago
Nobody should do 'npm install' or 'pip install' on their machine.
Using a proper sandboxing(https://github.com/ashishb/amazing-sandbox) regularly will drastically limit the blast radius of these attacks.
> https://github.com/ashishb/amazing-sandbox
Does your Docker backend run commands in rootless containers? I skimmed the code but didn't see anything to confirm this.
Right now, not. Eventually, they will.
You can pass your favorite rootless Docker image using `--custom-docker-image` CLI parameter.
I hope you see the (IMO, obvious) problem.
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.
Docker isn’t a serious sandboxing strategy
This has been responded to in the past by another HN poster: https://news.ycombinator.com/item?id=47612726
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.
> Nobody should do 'npm install' or 'pip install' on their machine.
What alternative do you suggest?
Do you mean not install outside a sandbox?
I've been playing around with declarative container configurations: https://github.com/AdrianVollmer/ContainerConductor (It's not ready, don't use it!)
It will always introduce friction, though.
Modern software development is simply too fast to be reviewed properly.
Download source. Extract. Move files to correct node_modules folder.
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.
If an attacker can infect the post-install script of an npm package, they can also infect the package source code itself. So if you ever run the project outside the sandbox, you will still get compromised.
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"
3 replies →
> The ability for npm to run scripts on any level should be removed.
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/
You discovered what web development was like in early 2000.
alias npm / bun / ... to run in a docker container, so npm install run automatically in the container.
That's exactly what I started with. It gets unwieldy quickly enough as you need to mount a lot of directories that these you uses as cache.
So, amazing-sandbox at its core is nothing but a glorified docker command generator (in default mode).
Is there a detection component here too? Sandboxing development is great, but the next step is to deploy to production. How do you know if something malicious happened in the sandbox, such that you don't deploy the malware further?
I have some ideas around it. And indeed that's one likely direction of this project in the future.