| ▲ | ashishb 3 hours 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. |
|
| ▲ | Bnjoroge 34 minutes ago | parent | next [-] |
| Docker isn’t a serious sandboxing strategy |
|
| ▲ | 8organicbits an hour ago | parent | prev | next [-] |
| 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? |
|
| ▲ | pritambaral 3 hours ago | parent | prev | next [-] |
| > 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. |
|
| ▲ | graemep 3 hours ago | parent | prev | next [-] |
| > Nobody should do 'npm install' or 'pip install' on their machine. What alternative do you suggest? Do you mean not install outside a sandbox? |
| |
| ▲ | themafia 3 hours ago | parent | next [-] | | 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. | | |
| ▲ | 63stack 2 hours ago | parent | next [-] | | You discovered what web development was like in early 2000. | |
| ▲ | dist-epoch 3 hours ago | parent | prev [-] | | 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" | | |
| ▲ | themafia 2 hours ago | parent [-] | | > they can also infect the package source code itself 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. | | |
| ▲ | dist-epoch 2 hours ago | parent [-] | | do you really think you will see a clear "spawn" call? there is a long history of obfuscating what the code does to hide backdoors, in quite ingenious ways > 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 |
|
|
| |
| ▲ | progx 2 hours ago | parent | prev [-] | | alias npm / bun / ... to run in a docker container, so npm install run automatically in the container. |
|
|
| ▲ | 3 hours ago | parent | prev [-] |
| [deleted] |
