←back to thread

441 points longcat | 1 comments | | HN request time: 0.001s | source
Show context
inbx0 ◴[] No.45040282[source]
Periodic reminder to disable npm install scripts.

    npm config set ignore-scripts true [--global]
It's easy to do both at project level and globally, and these days there are quite few legit packages that don't work without them. For those that don't, you can create a separate installation script to your project that cds into that folder and runs their install-script.

I know this isn't a silver bullet solution to supply chain attakcs, but, so far it has been effective against many attacks through npm.

https://docs.npmjs.com/cli/v8/commands/npm-config

replies(17): >>45040489 #>>45041292 #>>45041798 #>>45041820 #>>45041840 #>>45042872 #>>45043977 #>>45045311 #>>45045447 #>>45045979 #>>45046082 #>>45046981 #>>45047430 #>>45047994 #>>45049197 #>>45049793 #>>45050820 #
homebrewer ◴[] No.45041798[source]
I also use bubblewrap to isolate npm/pnpm/yarn (and everything started by them) from the rest of the system. Let's say all your source code resides in ~/code; put this somewhere in the beginning of your $PATH and name it `npm`; create symlinks/hardlinks to it for other package managers:

  #!/usr/bin/bash

  bin=$(basename "$0")

  exec bwrap \
    --bind ~/.cache/nodejs ~/.cache \
    --bind ~/code ~/code \
    --dev /dev \
    --die-with-parent \
    --disable-userns \
    --new-session \
    --proc /proc \
    --ro-bind /etc/ca-certificates /etc/ca-certificates \
    --ro-bind /etc/resolv.conf /etc/resolv.conf \
    --ro-bind /etc/ssl /etc/ssl \
    --ro-bind /usr /usr \
    --setenv PATH /usr/bin \
    --share-net \
    --symlink /tmp /var/tmp \
    --symlink /usr/bin /bin \
    --symlink /usr/bin /sbin \
    --symlink /usr/lib /lib \
    --symlink /usr/lib /lib64 \
    --tmpfs /tmp \
    --unshare-all \
    --unshare-user \
    "/usr/bin/$bin" "$@"
The package manager started through this script won't have access to anything but ~/code + read-only access to system libraries:

  bash-5.3$ ls -a ~
  .  ..  .cache  code
bubblewrap is quite well tested and reliable, it's used by Steam and (IIRC) flatpak.
replies(7): >>45043567 #>>45045504 #>>45046093 #>>45049572 #>>45049755 #>>45053685 #>>45092016 #
shermantanktop ◴[] No.45043567[source]
This is trading one distribution problem (npx) for another (bubblewrap). I think it’s a reasonable trade, but there’s no free lunch.
replies(1): >>45045056 #
homebrewer ◴[] No.45045056{3}[source]
Not sure what this means. bubblewrap is as free as it gets, it's just a thin wrapper around the same kernel mechanisms used for containers, except that it uses your existing filesystems instead of creating a separate "chroot" from an OCI image (or something like it).

The only thing it does is hiding most of your system from the stuff that runs under it, whitelisting specific paths, and optionally making them readonly. It can be used to run npx, or anything else really — just shove move symblinks into the beginning of your $PATH, each referencing the script above. Run any of them and it's automatically restricted from accessing e.g. your ~/.ssh

https://wiki.archlinux.org/title/Bubblewrap

replies(1): >>45045600 #
conception ◴[] No.45045600{4}[source]
It means that someone just has to compromise bubblewrap instead of the other vectors.
replies(5): >>45045751 #>>45045980 #>>45046340 #>>45047397 #>>45049907 #
throwawaysoxjje ◴[] No.45047397{5}[source]
Am I getting bubblewrap somewhere other than my distro? What makes it different from any other executable that comes from there?
replies(1): >>45054097 #
1. shermantanktop ◴[] No.45054097{6}[source]
Nothing. Does your threat model assume 100% trust in your distro? I understand saying you trust it a lot more than the garbage on npm. But if your trust is anything less than 100%, you are balancing risk and benefit.