4 ms·

As you mention, curl into sh is just as safe as any other software installation mechanism, unless you’re the sort of person who reads configure scripts and make

As you mention, curl into sh is just as safe as any other software installation mechanism, unless you’re the sort of person who reads configure scripts and makefiles and the various scripts inside Debian packages and RPMs. Even something like nix runs all sorts of arbitrary side effects when installing packages: the main benefit isn’t preventing the side-effects but the various sandboxing tricks it uses.

kevincox 6y ago
White side effects does Nix have when you install a package? IIUC it just updates the programs that are symlinked into various locations (like a directory in your $PATH).
- fiddlerwoaroof 6y ago
  If you’re installing from a binary cache, that’s true, but a nix expression is just a build specification: it can run any program available to build and install a package. The “normal” way this works is you install the software to $out and $out gets copied into the nix store, but a malicious nix package can bypass this (and, assuming you’re not using nix’s sandboxing mechanisms, do arbitrary things to your computer).
  - kevincox 6y ago
    Building without a sandbox is really pushing the definition of "just installing a package". Also the sandbox is enabled by default on at lest NixOS. I do admit that this sandbox is likely more for purity than security. Nonetheless while there may be exploits it is quite different than executing an installer or packages that have after-install scripts.
    - fiddlerwoaroof 6y ago
      We aren’t really talking about installing packages from official distributions, right? We’re talking about things like installing an interesting tool from GitHub using the ability of nix to download an build master.tar.gz. In most of these cases, there’s always going to be some amount of reliance on the assumption that the developer of the software is trustworthy. Also, I mainly use nix on Mac, where the sandbox is disabled by default and doesn’t work as well as the Linux sandbox, by all accounts.
matheusmoreira 6y ago
> unless you’re the sort of person who reads configure scripts and makefiles I always read these files before building from source. Is this really so rare? Why wouldn't people read the scripts they're about to run? > the various scripts inside Debian packages and RPMs It's reasonable to assume package repository maintainers have ensured their packages are not malicious.
- fiddlerwoaroof 6y ago
  But, we’re talking about installing software from non-distribution sources. E.g. the Minecraft Launcher ships as a .deb that you install: there’s no benefit security-wise for that over curl … | sh And, I doubt most people have the time or ability to read all the scripts that come with large software packages and ensure that they’re safe. For better or worse, executing code downloaded from the internet without verifying it manually is the norm these days.
  - codedokode 6y ago
    No, .deb is safer. You can manually unpack it into a folder without running any scripts as root.
TacticalCoder 6y ago
curl'ing is not the same at all as running, say, a Debian apt-get install. You apt-get signed packages coming from official mirrors (at least I do). Most of the Debian packages, by very far, are also fully deterministic and reproducible. If someone serves a backdoored package, that's probably incredibly noisy, leaving lots of traces everywhere and evidence can be gathered. When you curl, there's no way to know if you're the "lucky" one to get served malware by the server on that one curl call. This is completely different.
- fiddlerwoaroof 6y ago
  In this context we’re not talking about .debs from an official repository PPAs and debs downloaded from a GitHub release page have all the same problems as curl | sh
  - kbenson 6y ago
    Even if you aren't running official debs or RPMs, you're still quite a bit above running a build script off the web. A deb or RPM will include a manifest with checksums, which you can at a minimum use to confirm whether some post-isntall script or process changes an included file (such as removing or cleaning a malicious script that was included). In the case of RPM (at least, I'm not implying debs don't do this, just that I'm not as familiar with them) you can actually query any pre/post install scripts that were shipped with it as well: # rpm -q --scripts bash postinstall scriptlet (using <lua>): nl = '\n' sh = '/bin/sh'..nl bash = '/bin/bash'..nl f = io.open('/etc/shells', 'a+') if f then local shells = nl..f:read('*all')..nl if not shells:find(nl..sh) then f:write(sh) end if not shells:find(nl..bash) then f:write(bash) end f:close() end postuninstall scriptlet (using <lua>): -- Run it only if we are uninstalling if arg[2] == "0" then t={} for line in io.lines("/etc/shells") do if line ~= "/bin/bash" and line ~= "/bin/sh" then table.insert(t,line) end end f = io.open("/etc/shells", "w+") for n,line in pairs(t) do f:write(line.."\n") end f:close() end Even a downloaded package that's not signed is far more auditable after the fact than executing arbitrary commands from a remote source.
jjav 6y ago
> curl into sh is just as safe as any other software installation mechanism It most certainly is not. Grabbing random code from some site is not the same as installing a package from a known repository which has been tested and inspected by a maintainer. Of course the latter isn't perfect, but it is way more assurance than the none whatsoever of a random script from an unknown source.

kevincox 6y ago

White side effects does Nix have when you install a package? IIUC it just updates the programs that are symlinked into various locations (like a directory in your $PATH).

fiddlerwoaroof 6y ago
If you’re installing from a binary cache, that’s true, but a nix expression is just a build specification: it can run any program available to build and install a package. The “normal” way this works is you install the software to $out and $out gets copied into the nix store, but a malicious nix package can bypass this (and, assuming you’re not using nix’s sandboxing mechanisms, do arbitrary things to your computer).
- kevincox 6y ago
  Building without a sandbox is really pushing the definition of "just installing a package". Also the sandbox is enabled by default on at lest NixOS. I do admit that this sandbox is likely more for purity than security. Nonetheless while there may be exploits it is quite different than executing an installer or packages that have after-install scripts.
  - fiddlerwoaroof 6y ago
    We aren’t really talking about installing packages from official distributions, right? We’re talking about things like installing an interesting tool from GitHub using the ability of nix to download an build master.tar.gz. In most of these cases, there’s always going to be some amount of reliance on the assumption that the developer of the software is trustworthy. Also, I mainly use nix on Mac, where the sandbox is disabled by default and doesn’t work as well as the Linux sandbox, by all accounts.

matheusmoreira 6y ago

> unless you’re the sort of person who reads configure scripts and makefiles I always read these files before building from source. Is this really so rare? Why wouldn't people read the scripts they're about to run? > the various scripts inside Debian packages and RPMs It's reasonable to assume package repository maintainers have ensured their packages are not malicious.

fiddlerwoaroof 6y ago
But, we’re talking about installing software from non-distribution sources. E.g. the Minecraft Launcher ships as a .deb that you install: there’s no benefit security-wise for that over curl … | sh And, I doubt most people have the time or ability to read all the scripts that come with large software packages and ensure that they’re safe. For better or worse, executing code downloaded from the internet without verifying it manually is the norm these days.
- codedokode 6y ago
  No, .deb is safer. You can manually unpack it into a folder without running any scripts as root.

TacticalCoder 6y ago

curl'ing is not the same at all as running, say, a Debian apt-get install. You apt-get signed packages coming from official mirrors (at least I do). Most of the Debian packages, by very far, are also fully deterministic and reproducible. If someone serves a backdoored package, that's probably incredibly noisy, leaving lots of traces everywhere and evidence can be gathered. When you curl, there's no way to know if you're the "lucky" one to get served malware by the server on that one curl call. This is completely different.

fiddlerwoaroof 6y ago
In this context we’re not talking about .debs from an official repository PPAs and debs downloaded from a GitHub release page have all the same problems as curl | sh
- kbenson 6y ago
  Even if you aren't running official debs or RPMs, you're still quite a bit above running a build script off the web. A deb or RPM will include a manifest with checksums, which you can at a minimum use to confirm whether some post-isntall script or process changes an included file (such as removing or cleaning a malicious script that was included). In the case of RPM (at least, I'm not implying debs don't do this, just that I'm not as familiar with them) you can actually query any pre/post install scripts that were shipped with it as well: # rpm -q --scripts bash postinstall scriptlet (using <lua>): nl = '\n' sh = '/bin/sh'..nl bash = '/bin/bash'..nl f = io.open('/etc/shells', 'a+') if f then local shells = nl..f:read('*all')..nl if not shells:find(nl..sh) then f:write(sh) end if not shells:find(nl..bash) then f:write(bash) end f:close() end postuninstall scriptlet (using <lua>): -- Run it only if we are uninstalling if arg[2] == "0" then t={} for line in io.lines("/etc/shells") do if line ~= "/bin/bash" and line ~= "/bin/sh" then table.insert(t,line) end end f = io.open("/etc/shells", "w+") for n,line in pairs(t) do f:write(line.."\n") end f:close() end Even a downloaded package that's not signed is far more auditable after the fact than executing arbitrary commands from a remote source.

jjav 6y ago

> curl into sh is just as safe as any other software installation mechanism It most certainly is not. Grabbing random code from some site is not the same as installing a package from a known repository which has been tested and inspected by a maintainer. Of course the latter isn't perfect, but it is way more assurance than the none whatsoever of a random script from an unknown source.