Hacker News Reader

Comment by jessaustin | Hacker News Reader

How many people are this careful about install scripts, but then allow the installed code to run with just the same permissions as the install script would have run? Is that a meaningful difference? Is it more difficult to audit install scripts than to audit the rest of the code?

View on HN

I only use npm to install frontend libraries, so the installed code is limited by the browser when it runs.

As far as I know the install scripts can do anything they want, which is upsetting whenever I think about it or they try to do something that annoys the corporate web proxy.

I bet an install script that dumped environment variables, then encoded them into something seemingly innocent like the extra fields of a dns request would gather all kinds of fun info from all the different ci/cd systems.

That doesn't really provide any meaningful reassurance when the code in the browser can still do anything it wants, such as stealing auth tokens, keylogging, etc. It's a different class of vulnerabilities and if you happened to be doing fancy SPA stuff, you could reasonably get a double bonanza by getting into the server environment on the SSR side.

npm scripts having same-as-you access to your computer in a linux-like environment is very different than JS running inside the browser sandbox though. By default its scoped to the origin its running on and with some additional header/html tags, can be further limited to just running your specific code and no get/post to other origins, and more.

So while running 3rd party code without inspecting it closely is always risky, its a lot more risky to run via node than via the browser js engine.

There is already protection against this form of attack in the browser with CORS: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

CORS doesn't help with compromised client code, since the CORS headers would allow access anyway.

CSP [1] can help by preventing malicious code to leak data to third parties, but it's far from trivial to close all loopholes. Especially with the myriad of tracking and other third party scripts most sites/apps use.

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...

Install scripts are kinda like make install, with which I had bad experiences. Often there is no command to uninstall again, and even if, can you trust that it works and really uninstalls stuff cleanly? What if there is an error in one half of the execution? Scripts are not a good way to install software. Do everything with declarative schemes if you can. Then have the runtime deal with partial installs/uninstalls etc.

This is less of a security issue and more of a conventions issue. Also, install scripts often run as root instead of the compiling user.

With "make install", I usually just pass a "--prefix=/usr/local/stow/" flag and let GNU stow take care of actual install and uninstall. You may be able to alter the perms on that subdirectory to avoid running as root, although I haven't bothered. I only go to such trouble when it's necessary to use something that hasn't been packaged by OS maintainers. Like make, npm isn't really intended to replace OS package management. npm is for using really "fresh" software. Of course we have to be more careful doing that, so we only do it when the benefits outweigh the costs.

> Like make, npm isn't really intended to replace OS package management. npm is for using really "fresh" software.

I'm not sure what you suggest here. Chrome extensions are heavily sandboxed and thanks to that you can remove them cleanly. Does this mean that Chrome replaces OS package management? Is your intent to say that making npm installation more "dangerous" for users is a good idea as it drives people towards OS package management? What about the large set of software that is not won't ever be packaged for your distro/OS?

I use zpkg[1] for that. I only mention it because I doubt anyone really knows about it. I got to know about it by "accident". There is no README, so I am afraid you have to just listen to the output you get from running it and/or reading the source code. I used GNU stow before, but this one does what I want and not much more.

[1] https://zolk3ri.name/cgit/zpkg/ (https://zolk3ri.name/cgit/zpkg/tree/src/zpkg.ml)

> With "make install", I usually just pass a "--prefix=/usr/local/stow/" flag and let GNU stow take care of actual install and uninstall

I used to do something like that 10 years ago. From what I remember, GNU stow was not really able to do that properly though, because of the way it handles nested un-existing directories. I. E. It will symlinks a whole directory if it does not previously exist, which will make later deployments of new symlinks inside impossible. Also it did not handle absolute symlinks.

For these reasons, I used "xstow".

Edit: just had a look at the latest version of GNU stow, looks like they corrected the folding issue, that's great!

Actually the installed code may have less permissions and may execute in a different context. For example, an npm js library for a photo gallery may only ever run in the context of the browser. Of course some libraries for server code / build code may run in node js which ostensibly allows for ACE. But the surface area is smaller with this.

Install scripts typically have access to build environments.

Of course you're right in many situations, but in general secrets should not be allowed in build environments. If one doesn't expend the effort to limit permissions in the production environment, however, it's no different.

Database credentials hopefully not, but the build environment will almost certainly have access to a private git repo somewhere.

I've never seen a CI/CD without secrets, how else are you going to access private repos, access some live dependency during e2e testing or deploy the binary to its target?

I've used multiple that run the build in a sandbox without secrets. One of them didn't even mount in the .git directory, it just propagated some commit info via environment variables. I also like to split the publishing of artifacts from the deployment process to make sure it's repeatable. This also ensures that the CI pipeline doesn't have direct access to production.

You isolate the stages which require secrets from the stages that run untrusted code. One step has access to your SSH private key and runs git clone. The next step runs the actual build without access to any secrets. A third step has access to the secret key required to publish the result.

It's certainly more complicated to set up than a simple "the CI system invokes a single shell script that does everything" build, but it's not actually that complicated and every CI system I've used has supported doing this.

Yeah I've never seen anyone go to that much effort in practice.

Reply on news.ycombinator.com