4 ms·

Nobody should do 'npm install' or 'pip install' on their machine. Using a proper sandboxing(https://github.com/ashishb/amazing-sandbox https://github.com/ashis

by ashishb 4mo ago

Nobody should do 'npm install' or 'pip install' on their machine. Using a proper sandboxing(https://github.com/ashishb/amazing-sandbox https://github.com/ashishb/amazing-sandbox) regularly will drastically limit the blast radius of these attacks.

graemep 4mo ago
> 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 4mo ago
  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.
  - dist-epoch 4mo ago
    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 4mo ago
      > 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 4mo ago
        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
      - ashishb 4mo ago
        > I should be able to install this module in such a way where file operations and process operations are not available to it. That's the definition of a sandbox, isn't it?
  - 63stack 4mo ago
    You discovered what web development was like in early 2000.
  - ashishb 4mo ago
    > 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/ https://ashishb.net/security/contagious-interview/
- progx 4mo ago
  alias npm / bun / ... to run in a docker container, so npm install run automatically in the container.
  - ashishb 4mo ago
    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).
- mr_mitm 4mo ago
  I've been playing around with declarative container configurations: https://github.com/AdrianVollmer/ContainerConductor 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.
pritambaral 4mo ago
> https://github.com/ashishb/amazing-sandbox 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.
- ashishb 4mo ago
  Right now, not. Eventually, they will. You can pass your favorite rootless Docker image using `--custom-docker-image` CLI parameter.
  - pritambaral 4mo ago
    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.
    - ashishb 4mo ago
      > 1. Docker (or any Linux container runtime, for that matter) is not intended for, designed for, or effective as a security boundary. This has been discussed in detail earlier - https://news.ycombinator.com/item?id=47612726 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.
      - pritambaral 4mo ago
        > 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?
deleted 4mo ago
[deleted]
8organicbits 4mo ago
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?
- ashishb 4mo ago
  I have some ideas around it. And indeed that's one likely direction of this project in the future.
Bnjoroge 4mo ago
Docker isn’t a serious sandboxing strategy
- ashishb 4mo ago
  This has been responded to in the past by another HN poster: https://news.ycombinator.com/item?id=47612726 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.

by ashishb 4mo ago

graemep 4mo ago

> 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 4mo ago
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.
- dist-epoch 4mo ago
  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 4mo ago
    > 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 4mo ago
      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
    - ashishb 4mo ago
      > I should be able to install this module in such a way where file operations and process operations are not available to it. That's the definition of a sandbox, isn't it?
- 63stack 4mo ago
  You discovered what web development was like in early 2000.
- ashishb 4mo ago
  > 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/ https://ashishb.net/security/contagious-interview/
progx 4mo ago
alias npm / bun / ... to run in a docker container, so npm install run automatically in the container.
- ashishb 4mo ago
  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).
mr_mitm 4mo ago
I've been playing around with declarative container configurations: https://github.com/AdrianVollmer/ContainerConductor 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.

pritambaral 4mo ago

> https://github.com/ashishb/amazing-sandbox 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.

ashishb 4mo ago
Right now, not. Eventually, they will. You can pass your favorite rootless Docker image using `--custom-docker-image` CLI parameter.
- pritambaral 4mo ago
  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.
  - ashishb 4mo ago
    > 1. Docker (or any Linux container runtime, for that matter) is not intended for, designed for, or effective as a security boundary. This has been discussed in detail earlier - https://news.ycombinator.com/item?id=47612726 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.
    - pritambaral 4mo ago
      > 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?

deleted 4mo ago

[deleted]

8organicbits 4mo ago

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?

ashishb 4mo ago
I have some ideas around it. And indeed that's one likely direction of this project in the future.

Bnjoroge 4mo ago

Docker isn’t a serious sandboxing strategy

ashishb 4mo ago
This has been responded to in the past by another HN poster: https://news.ycombinator.com/item?id=47612726 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.