Does anyone have a solution to wrap binary execution (or npm execution) and require explicit user authorization for network or fs calls?
(Deno is a JavaScript runtime co-created by Ryan Dahl, who created Node.js - see his talk "10 Things I Regret About Node.js"[1] for more of his motivations in designing it.)
Then would halt due to file access or network permissions.
Could still get you if you lazily allow all everywhere though and this is why you shouldn’t do that.
deno run npm:@angular/cli --helpIf you use that, I'd highly recommend configuring it to throw an error instead of just silently skipping the postInstall though: https://github.com/karlhorky/pnpm-tricks#fail-pnpm-install-o...
Bun is two things. Most commonly, it's known for its Node-competitor runtime, which is of course a very invasive change. But it can also be used purely as a package manager, with Node as your runtime: https://bun.sh/docs/cli/install
As a package manager, it's much more efficient, and I would recommend switching over. Haven't used pnpm, though--we came from yarn (v2, and I've used v1 in past).
We still use Node for our runtime, but package install time has dropped significantly.
This is especially felt when switching branches on dev machines where one package in the workspace has changed, causing yarn to retry all packages (even though yarn.lock exists), where bun only downloads the new package.
Go encourages package authors to simply link to their git repository. It is quite literally cloning source files onto your computer without much thought
It’s ripe for an exploit
This is talking about the same thing, but at install time as well.
Best practice now is to not run postinstall scripts by default. Yarn and pnpm allow you to do this (and pnpm at least won’t run them by default) and I believe npm now does too, and is looking at a future where it won’t run them by default.
The other difference is Go had several chances to do better, and they didn’t take any steps to do so.
The maintainers of NPM (the registry and tool) I’m sure would love to make a lot of changes to the ecosystem but they can’t make some of them without breaking too much, and at the scale that NOM operates it’s going to always be playing catch up with work around a and such for previous choices so they don’t say, break hundreds of thousands of CI runs simultaneously.
Go iterated on its package ecosystem several times and ultimately did very little with it. They didn’t make it vastly more secure by default in any way, they were actually going to get rid of vendoring at one point, and a whole host of other SNAFUs.
Go’s packaging and distribution model while simple is extremely primitive and they have yet to really adopt anything in this area that would be beneficial for security
I stopped using npm a while back and push and pull tar files instead.
Naturally I get js modules from npm in the first place, but I never run code with it after initial install and testing of a library for my own use.
The de facto compromise is to use package.json for deps, but your distributable blob is a docker image, which serializes a concrete node_modules. Something similar (and perhaps more elegant) is Java's "fat jar" approach where all dependencies are put into a single jar file (and a jar file is just a renamed zip so it's much like a tarball).
If you vendor and tar your dependencies correctly you could functionally build a system around trust layers by inspecting hashes before allowing unpacking for instance.
It’s a thought exercise certainly but there might be legs to this idea
The problem is, as soon as it becomes remotely popular, every module is going to end up saying "I must be run in a context where I have access to all the functions version 13.2 of the filesystem module wrapped up in a structure that claims to be version 13.2 of the filesystem module and which has been signed by the private key that corresponds to the filesystem module author's public key" - even though they only need a random access file handle for use as a temporary file - because otherwise developers will be anxious about leaked implementation details preventing them from making version 1.4.16 (they'll just have to make version 2.0 - who cares? their implementation detail is my security).
Example: in order to write to open a file, you need a capability object corresponding to write access to the file's parent directory. Now you can be sure that a dependency doesn't write any files unless you actually pass it one of these capability objects.
Only Java, .Net and R just download files, at a declared (reproducible) version.
You can set a custom security policy to block or warn on file system, network, shell, or environment variable access.
But the result of a compiler will run on the machine anyway, but once again, it should be in a Docker.
Even KVM escapes have been demonstrated. KVM is not a security boundary ... except that in practice it is (a quite effective one at that).
Taken to the extreme you end up with something like "network connected physical machines aren't a security boundary" which is just silly.
1. This is why some places with secret enough info keep things airgapped.
2. OTOH, from what I recall hearing the machines successfully targeted by Stuxnet were airgapped.
In our threat model the upper bound on the useful lifetime of the system is limited by the light-distance time from the nearest adversary.
What percentage of malware is programmed to exploit Docker CVEs vs. just scanning $HOME for something juicy? Swiss cheese model comes to mind.
Container technology is awesome, and it’s a huge step forward for the industry, but are places where it’s not feasible to use, at least for now.
Much better.