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.

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).

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.

> 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.

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"

> 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?

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

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.

I have been targeted with this attack in the wild where '.vscode/tasks.json' had the auto-run code.

I smelled something fishy and never ran it though.

https://news.ycombinator.com/item?id=48127469

Hypothesis: a big accelerant of these rapid repository compromise (from Red hat to GitHub to Amazon to small startups) might be GitHub+dependabot automatic dependency updates.

So, just like COVID-19 used air travel, modern malware attacks are relying on GitHub+dependabot to speed up the spread.

Even for single page website built using Vue, I would get about 5 updates a week.

So. Dependabot (and renovate) do have "cooldowns" supported, just need to set them up.

For dependabot it's as simple as

cooldown.default-days: 1

There are security researchers (that don't have cooldowns) that usually detect compromises within hours or less, and package managers almost always manage to remove the offending versions in less than 24 hours (usually much less).

So people will 24 hours cooldowns get protected.

Shameless plug: I maintain depsguard.com that tries to simplify cooldowns setup across anything that supports it, in one command (it scans from where you run it, e.g. if you run it from your user folder it will look for any local repos with dependabot / renovate and suggest a change.

> For dependabot it's as simple as > cooldown.default-days: 1

Most people stick to default of 0. In fact, I am realizing over time that it is best to make it 7-14 days.

It’s plausible. It’s certainly the case that we (meaning security practitioners) spent years trying to move people onto faster and more automated update cycles, and these kinds of compromises have revealed a latent weakness that comes wit doing so.

Nginx was compelled to move to GitHub [1].

The fact that companies request you to star them on GitHub and the stars can be bought tells you that there is a value in these stars. [2]

Now, some astute reader, who thinks the $1 trillion global advertisement market does not influence them, will also claim that they don't care about GitHub stars.

Well, that's not how the world works.

Fake stars can propel a good project to great.

A lot of people will use GitHub stars as a currency to decide the importance of certain FOSS (or even open-core) projects.

The real lock-in is in GitHub stars [3].

1 - https://blog.nginx.org/blog/nginx-open-source-moves-to-githu...

2 - https://finance.biggo.com/podcast/1c9f14e134095b87

3 - https://ashishb.net/tech/github-stars/

They didn't move primarily because of stars, they moved because they had been using Mercurial and most developers aren't familiar with it.

And why didn't they chose self-hosted for git then?

What stops a new platform from just mirroring GitHub stars on import or something, actually?

> What stops a new platform from just mirroring GitHub stars on import or something, actually?

So, the source is still GitHub, right?

Which means I have to keep my FOSS project on GitHub to accumulate stars.

I'm thinking like "you had 200 GitHub stars before coming to us so we start you with 200 stars" as a migration process. maybe they wouldn't be as reputable but everyone knows it's gamed anyway, so why not?

> I'm thinking like "you had 200 GitHub stars before coming to us so we start you with 200 stars" as a migration process. maybe they wouldn't be as reputable but everyone knows it's gamed anyway, so why not?

And how will the project accumulate more?

> everyone knows it's gamed anyway, so why not?

Then why do they still have purchase value?

Copy the same way people can star projects to the new platform too, but maybe allow people to buy them directly from you to cut out the middleman. It could be very efficient.

> everyone knows it's gamed anyway, so why not?

Arbitrage. Devs know its gamed. VCs less so.

Simpler answer: TINA (there is no better alternative)

Alpine is a bad idea for a non-trivial application written in Python, Node.js, or any other interpreted language.

Too many weird edge cases to deal with, especially related to Alpine using musl libc instead of glibc.

At best, your builds are slower.

At worst, certain code paths are broken.

Alpine is a great choice.. Provided you understand what’s included, and the ramifications it has on the stack you’re trying to work with.

99 times out of 100 it’s a terrible choice for an enterprise.

I had this experience as well, nowadays I use Debian slim. Too much random breakage in Alpine.

Uber had 8000 repos at one point with 2000 engineers - https://highscalability.com/lessons-learned-from-scaling-ube...

Probably most of them are forks of some public repo with some patch applied and half of those are probably not even used internally anymore.

Afaik, they eventually cleaned it up.

And it was each team owning multiple internal repos of their own deployments/libraries, and not, primarily, clones of public repos.

Yeah. Real profile names.

Unlikely that those guys were real. And I did reach out to them for explanation. Only to be blocked by both!

This is just a negative filter to see as a warning sign. It is like walking into a dark alley at night.

Nothing might happen but you should be on the alert.

Not for someone who get 10-20 such requests a year. None till date were such scams.

All of them were scams, this was just the first time you were the intended victim.

Those were real companies. The conversation started online and immediately moved in-person.

I was never asked to install anything. I was not even given code access (without NDA) and I did get paid with equity/money in cases there was a mutual match and we proceeded.

Oh god, thanks for the heads up. It's a wonder how many people fell for it, definitely non-zero I reckon. I would hate for this to become a thing on LinkedIn.

Always run third-party code (especially npm packages) inside a sandbox, take your pick: ai-jail, bubblewrap, seatbelt, or amazing-sandbox (the last one, I wrote for myself after trying all others).

Bubblewrap doesn't help with protecting DBus bus (and you can do a lot with unrestricted access to DBus), accessing the GPU, Wayland and audio daemon. It cannot protect /proc and /sys filesystems. So it works only for simplest CLI programs.

As I remember, some Node.js utility (maybe npm) had a bug where it hang if there were no /proc filesystem because it couldn't figure out how many CPUs are available. Telegram crashes because of Apple's Grand Central Dispatch library if run in a sandbox without /proc. That's how bad things are.

Also, Chrome and Electron apps use SUID binaries to build their own sandbox. How would you sandbox an Electron app (obviously running an untrusted SUID binary is not an option)?

Then try https://github.com/ashishb/amazing-sandbox

I use it every day for CLI tools

> How would you sandbox an Electron app

I haven't figured that out yet

This seems to have similar or less features than bubblewrap, but requires Docker which loads huge images and wastes disk space. No Wayland, DBus, Pipewire, proc, sys filtering. Furthermore, Docker docs explicitly says that it cannot be used for security sandboxing. Also, Docker is a huge binary, run as root, with lot of APIs and wide attack surface.

> Also, Docker is a huge binary, run as root, with lot of APIs and wide attack surface.

You can run it without root. And that's what you should do.

> No Wayland, DBus, Pipewire, proc, sys filtering.

Yeah, I don't need Wayland for CLI tools. For others, you get them inside Docker, isolated from the rest of the system. When I run `npm install`, I want isolation.