This node npm supply chain attack incident is a wake up call that the current security model of mainstream operating systems such as Linux, MacOSX or Windows are no longer suitable for modern day threats and they need a "zero-trust" like model for applications. Mitigating supply chain attacks like this one requires adopting application sandboxing by default, assuming that any application can be compromised, and capability-based security model like Fuchsia, Genode OS or mobile operating systems like Android or Apple's IOS. In the case of Linux, the most suitable sandboxes are docker container and Firejail tool that can restrict operating system resources which an application can access, including the $HOME directory. Firejail can even provide a fake $HOME directory. In the case of Microsoft windows, there is the Windows Sandbox, but it is only available on Windows pro or enterprise. But even so those countermeasures would only prevent the user data from being damaged, malicious NPM packages could still attempt to send credentials, tokens or database information back to the attacker. More details at: https://hkubota.wordpress.com/2020/12/31/comparing-sandboxin... and https://docs.microsoft.com/en-us/windows/security/threat-pro....

Another suitable mitigation strategy may be lock dependencies version or switch to other programming languages with a proper standard library and limited number of packages where one can at least audit the code.

Run it in a container. Don't let the container run as root - create an account which has the same ID as a dummy account on your host system. If you have to volume mount, be very explicit about what paths you mount and use the read only flag if it makes sense. If you can't mount read only because you need to write to certain files, then grant the container account access to those files using ACLs (eg: on Linux user 'chmod' or 'setfacl').

Running it as user nobody within the container should be enough, no?

That should do it, as long as both host and container systems implement the nobody user on the same ID. Which is likely. But I'd check all the same

I switched from Node to Deno partly for exactly this functionality.

But you’re probably looking for something more general, like containers, virtual machines, or other sandboxes (chroot?).

I don't think fetching arbitrary code over url's is somehow better than npm.

Deno has module hashing and sanboxes OS access AFAIK

    yarn install --flat
    git add node_modules

Then the next time you run yarn upgrade:

    yarn upgrade --flat
    git diff

Carefully read through what changed in each of the packages.

    git add node_packages
    git commit -m "yarn upgrade"

You will see a lot of bad code, but also learn stuff. But most importantly - your project will be secure.

Yes, don't give your main account admin sudo access without a password.

Keep backups on an external file store just in case.

Use a filesystem that has snapshot capabilities.

What is the point of that. Sudo doesn't give access to anything important. Very much reminds me of this https://xkcd.com/1200/

Snapshots on an external system is useful but few are disciplined enough to take regular enough snapshots.

It kinda does… root can write to places that the user cannot. Like Boot partitions, or entire device nodes, or load kernel modules that the user cannot see. That xkcd is a funny historical joke, but the root/user distinction is still a critical part of operating system security today.

But it is true. Who cares if the program can write to your system configuration when it can encrypt your entire home directory and use your private SSH keys to encrypt all your servers as well.

I'd argue the root/normal user separation is largely useless on single user desktop computers.

Presumably only the homedirs of the servers.

You want a world where a browser exploit can drop a bootkit? Nahhh

They could just drop something in bashrc or somewhere else for a persistent exploit. The system files contain nothing worth touching on a personal device.

Persistent userspace. And while I understand privesc in major platforms is not the insurmountable problem it seems, it is still a layer of protection important to the model of preventing SMM, hypervisor efi boot and root level persistence, without something else up its sleeves.

I guess people have forgotten the lessons of 90s Windows: Don't download and run random .exe from the internet, assume they are hostile until proven otherwise.

Don't download, install and run random code libraries from the internet, assume they are hostile until proven otherwise.

I don't think that's really fair. Unity 3d and Vue.js are not random.exe.

I think their point might have been that Unity forgot that lesson. And everyone else, transitively, along the chain.

As horrible and impracticable as it sounds, the only way to prevent this happening is to read the source of every (/transitive) dependency you install. Yes, we can trust people, and yes, we can blame them when they betray our trust - we can even prosecute them - but as this shows, that's not always going to stop people. And it's certainly not going to stop attackers who gain control of those dependencies.

This is something we really need to think about as a profession. I would favour a system where dependencies are restricted to pure computation only (no syscalls) and any greater permissions must be granted explicitly. But that's extremely onerous, and likely - for many devs - to lead to a 'just click yes' mentality; even besides that, there are doubtless many cases it won't prevent. All I'm sure of is that we can't continue like this.