4 ms·

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

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?

haburka 6y ago
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.
burnthrow 6y ago
Install scripts typically have access to build environments.
- deleted 6y ago
  [deleted]
- jessaustin 6y ago
  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.
  - paledot 6y ago
    Database credentials hopefully not, but the build environment will almost certainly have access to a private git repo somewhere.
  - dtech 6y ago
    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?
    - enigmo 6y ago
      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.
    - plorkyeran 6y ago
      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.
      - IshKebab 6y ago
        Yeah I've never seen anyone go to that much effort in practice.
dec0dedab0de 6y ago
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.
- ljm 6y ago
  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.
  - diggan 6y ago
    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.
  - catears 6y ago
    There is already protection against this form of attack in the browser with CORS: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
    - the_duke 6y ago
      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/Content-Security-Policy https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...
est31 6y ago
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.
- jessaustin 6y ago
  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.
  - est31 6y ago
    > 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?
  - johnisgood 6y ago
    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/ (https://zolk3ri.name/cgit/zpkg/tree/src/zpkg.ml https://zolk3ri.name/cgit/zpkg/tree/src/zpkg.ml)

haburka 6y ago

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.

burnthrow 6y ago

Install scripts typically have access to build environments.

deleted 6y ago
[deleted]
jessaustin 6y ago
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.
- paledot 6y ago
  Database credentials hopefully not, but the build environment will almost certainly have access to a private git repo somewhere.
- dtech 6y ago
  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?
  - enigmo 6y ago
    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.
  - plorkyeran 6y ago
    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.
    - IshKebab 6y ago
      Yeah I've never seen anyone go to that much effort in practice.

dec0dedab0de 6y ago

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.

ljm 6y ago
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.
- diggan 6y ago
  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.
- catears 6y ago
  There is already protection against this form of attack in the browser with CORS: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
  - the_duke 6y ago
    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/Content-Security-Policy https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...

est31 6y ago

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.

jessaustin 6y ago
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.
- est31 6y ago
  > 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?
- johnisgood 6y ago
  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/ (https://zolk3ri.name/cgit/zpkg/tree/src/zpkg.ml https://zolk3ri.name/cgit/zpkg/tree/src/zpkg.ml)