[phiresky]

That seems a bit excessive to sandbox a command that really just downloads arbitrary code you are going to execute immediately afterwards anyways?

Also I can recommend pnpm, it has stopped executing lifecycle scripts by default so you can whitelist which ones to run.

[tetha]

At work, we're currently looking into firejail and bubblewrap a lot though and within the ops-team, we're looking at ways to run as much as possible, if not everything through these tools tbh.

Because the counter-question could be: Why would anything but ssh or ansible need access to my ssh keys? Why would anything but firefox need access to the local firefox profiles? All of those can be mapped out with mount namespaces from the execution environment of most applications.

And sure, this is a blacklist approach, and a whitelist approach would be even stronger, but the blacklist approach to secure at least the keys to the kingdom is quicker to get off the ground.

[ashishb]

firejail, bubblewrap, direct chroot, sandbox-run ... all have been mentioned in this thread.

There is a gazillion list of tools that can give someone analysis paralysis. Here's my simple suggestion: all of your backend team already knows (or should) learn Docker for production deployments.

So, why not rely on the same? It might not be the most efficient, but then dev machines are mostly underutilized anyway.

[ashishb]

> Also I can recommend pnpm, it has stopped executing lifecycle scripts by default so you can whitelist which ones to run.

Imagine you are in a 50-person team that maintains 10 JavaScript projects, which one is easier?

  - Switch all projects to `pnpm`? That means switching CI, and deployment processes as well
  - Change the way *you* run `npm` on your machine and let your colleagues know to do the same

I find the second to be a lot easier.

[larusso]

I don’t get your argument here. 10 isn’t a huge number in my book but I don’t know of course what else that entails. I would opt for a secure process change over a soft local workflow restriction that may or may not be followed by all individuals. And I would definitely protect my CI system in the same way than local machines. Depending on the nature of CI these machines can have easy access rights. This really depends how you do CI and how lacks security is.

[ashishb]

I'll do soft local workflow restriction right away.

The secure process change might take anywhere from a day to months.

[afavour]

There are a great many extra perks to switching to pnpm though. We switched on our projects a while back and haven’t looked back.

[alt227]

Yeah, id just take the time to convert the 10 projects rather than try to get 50 people to chnage their working habots, plus new staff coming in etc.

Switch your projects once, done for all.

[ashishb]

So, switching to pnpm does not entail any work habit changes?

[fragmede]

Am I missing something? Don't you also need to change how CI and deployment processes call npm? If my CI server and then also my deployment scripts are calling npm the old insecure way, and running infected install scripts/whatever, haven't I just still fucked myself, just on my CI server and whatever deployment system(s) are involved? That seems bad.

[ashishb]

Your machine has more projects, data, and credentials than your CI machine, as you normally don't log into Gmail on your CI. So, just protecting your machine is great.

Further, you are welcome to use this alias on your CI as well to enhance the protection.

[arghwhat]

Attacking your CI machines means to poison your artifacts you ship and systems they get deployed to, get access to all source it builds and can access (often more than you have locally) and all infrastructure it can reach.

CI machines are very much high-value targets of interest.

[fragmede]

> Further, you are welcome to use this alias on your CI as well to enhance the protection.

Yes, but if I've got to configure that across the CI fleet as well as in my deploy system(s) in order to not get, and also be distributing malware, what's the difference between having to do that vs switching to pnpm in all the same places?

Or more explicitly, your first point is invalid. Whether you ultimately choose to use docker to run npm or switch to pnpm, it doesn't count to half-ass the fix and only tell your one friend on the team to switch, you have to get all developers to switch AND fix your CI system, AND also your deployment system (s) (if they are exposed).

This comment proffers no option on which of the two solutions should be preferred, just that the fix needs to made everywhere.

[jve]

You do the backward logic here. I would go for a single person to deal with pnpm migration and CI rather than instruct other 10 for everyone to hopefully do the right thing. And think about it when the next person comes in... so I'd go for the first option for sure.

And npm can be configured to prevent install scripts to be run anyways:

> Consider adding ignore-scripts to your .npmrc project file, or to your global npm configuration.

But I do like your option to isolate npm for local development purposes.

[azangru]

> which one is easier?

> Switch all projects to `pnpm`?

Sorry; I am out of touch. Does pnpm not have these security problems? Do they only exist for npm?

[joshkel]

pnpm doesn't execute lifecycle scripts by default, so it avoids the particular attack vector of "simply downloading and installing an NPM package allows it to execute malicious code."

As phiresky points out, you're still "download[ing] arbitrary code you are going to execute immediately afterwards" (in many/most cases), so it's far from foolproof, but it's sufficient to stop many of the attacks seen in the wild. For example, it's my understanding that last month's Shai-Hulud worm depended on postinstall scripts, so pnpm's restriction of postinstall scripts would have stopped it (unless you whitelist the scripts). But last month's attack on chalk, debug, et al. only involved runtime code, so measures like pnpm's would not have helped.

[ashishb]

Exactly so you should still execute all JS code in a container.

[ashishb]

> That seems a bit excessive to sandbox a command that really just downloads arbitrary code you are going to execute immediately afterwards anyways?

I won't execute that code directly on my machine. I will always execute it inside the Docker container. Why do you want to run commands like `vite` or `eslint` directly on your machine? Why do they need access to anything outside the current directory?

[bandrami]

I get this but then in practice the only actually valuable stuff on my computer is... the code and data in my dev containers. Everything else I can download off the Internet for free at any time.

[ashishb]

No.

Most valuable data on your system for a malware author is login cookies and saved auth tokens of various services.

[hinkley]

Maybe keylogging for online services.

But it is true that work and personal machines have different threat vectors.

[spicybright]

Yes, but I'm willing to bet most workers don't follow strict digital life hygiene and cross contaminate all the time.

[kolme]

You don't have any stored passwords? Any private keys in your `.ssh/`? DB credentials in some config files? And the list goes on and on.

[bandrami]

I don't store passwords (that always struck me as defeating the purpose) and my SSH keys are encrypted.

[jamesnorden]

This kind of mentality, and "seems a bit excessive to sandbox a command that really just downloads arbitrary code", is why the JS ecosystem is so prone to credential theft. It's actually insane to read stuff like that said out loud.

[bandrami]

Right but the opposite mentality winds up putting so much of the eggs in the basket of the container that it defeats a lot of the purpose of the container.

[throwaway290]

It's weird that it's downvoted because this is the way

[apsurd]

maybe i'm misunderstanding the "why run anything on my machine" part. is the container on the machine? isn't that running things on your machine?

is he just saying always run your code in a container?

[minitech]

> is the container on the machine?

> is he just saying always run your code in a container?

yes

> isn't that running things on your machine?

in this context where they're explicitly contrasted, it isn't running things "directly on my machine"

[apsurd]

it annoys me that people fully automate things like type checkers and linting into post commit or worse entirely outsourced to CI.

Because it means the hygiene is thrown over the fence in a post commit manner.

AI makes this worse because they also run them "over the fence".

However you run it, i want a human to hold accountability for the mainline committed code.

[ashishb]

I run linters like eslint on my machine inside a container. This reduces attack surface.

How does this throw hygiene over the fence?

[apsurd]

Yes in a sibling reply, i was able to better understand your comment to mean "run stuff on my machine in a container"

[simpaticoder]

pnpm has lots of other good attributes: it is much faster, and also keeps a central store of your dependencies, reducing disk usage and download time, similar to what java/mvn does.

[johannes1234321]

> command that really just downloads arbitrary code you are going to execute immediately afterwards anyways?

By default it directly runs code as part of the download.

By isolation there is at least a chance to do some form of review/inspection

[Kholin]

I've tried use pnpm to replace npm in my project, it really speed up when install dependencies on host machine, but much slower in the CI containers, even after config the cache volume. Which makes me come back to npm.

[worthless-trash]

> That seems a bit excessive to sandbox a command that

> really just downloads arbitrary code you are going to

> execute immediately afterwards anyways?

I don't want to stereotype, but this logic is exactly why javascript supply chain is in the mess its in.