4 ms·

would you feel better if your Makefile looks like this: install: [ $(id -u) -ne 0 ] && echo 'please run sudo make install' || curl https//my.thing

would you feel better if your Makefile looks like this: install: [ $(id -u) -ne 0 ] && echo 'please run sudo make install' || curl https//my.thing | /bin/sh it goes back to what jve said - it's a matter of trust. how often do you blindly run 'sudo make install' w/o reading the entirety of the build script? all the time I bet - it's because you trust the source

LockAndLol 7y ago
No. I think I have never run `sudo make install`. Things I install come from package managers. Docker or a VM is used to test other software. And of course trust is important, but if I encounter things like `curl | bash`, my trust is lost.
- yori 7y ago
  What difference does it make if you run `make install` or `curl | bash`? In both cases, you are running code you have not audited yourself. Or are you the kind who inspects every Makefile and installer script before installing? If not, why is one better than the other?
  - sudosysgen 7y ago
    Because at least with make install you can have some trust in the delivery method, ie encrypted git or whatever. If you use just plain http....
    - yori 7y ago
      So wget https://example.com/installer.tar.gz; https://example.com/installer.tar.gz; tar -xvzf installer.tar.gz; cd installer; make install is okay for you? But curl https://example.com/installer.sh https://example.com/installer.sh | bash is not? Why?
      - sudosysgen 7y ago
        I'm fine with the second too as long as the host is trustworthy and it's always https. Most of the time it isn't.
- GordonS 7y ago
  Whether it's `sudo make install` or `curl | bash`, in both cases you have the opportunity to first inspect the code that will be executed.
  - Avamander 7y ago
    You don't have the opportunity in the latter case. https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...
    - GordonS 7y ago
      Sorry, I don't follow. If I have a makefile, I can inspect it and see what it does. If I have shell script (or indeed a makefile!) that calls `curl | bash`, I can inspect that shell script and see the URL that is used with curl, and then inspect the contents that the URL returns.
      - Avamander 7y ago
        You can't see what comes from `curl | bash` before you actually pipe it to bash, click the link and read the article please.
        GordonS 7y ago
        OK, I see - in theory, an attacker in control of the backend could write a handler that could craft a bash script that writes different content when `curl | bash` is used. TBH, while I take your point, I do think it's a little disingenuous of you to claim that "You don't have the opportunity" to inspect the script prior to executing it - you ordinarily will, but can't in the unlikely event of an attack like the article describes, which would require an attacker to be in full control of the web server. Off the top of my head, this could be mitigated in a couple of ways: 1. Hash a known-good script and check the hash matches prior to executing (this does however mean that you need to update the hash every time the remote script is changed) 2. Use curl to download the remote script to a local file first, and provide the opportunity to inspect it prior to piping it into bash
Doxin 7y ago
Basically all makefiles you run into in the wild for mature projects allow you to install it with a prefix. e.g. into the home folder. No need to sudo anything if you do that.
- markhahn 7y ago
  This is an important point lost in the noise. The problem is that cattle should apply only to containers, not hosts or VMs. Why? root. Which is also why Docker is a nonstarter for anyone who wants to use containers securely.

LockAndLol 7y ago

No. I think I have never run `sudo make install`. Things I install come from package managers. Docker or a VM is used to test other software. And of course trust is important, but if I encounter things like `curl | bash`, my trust is lost.

yori 7y ago
What difference does it make if you run `make install` or `curl | bash`? In both cases, you are running code you have not audited yourself. Or are you the kind who inspects every Makefile and installer script before installing? If not, why is one better than the other?
- sudosysgen 7y ago
  Because at least with make install you can have some trust in the delivery method, ie encrypted git or whatever. If you use just plain http....
  - yori 7y ago
    So wget https://example.com/installer.tar.gz; https://example.com/installer.tar.gz; tar -xvzf installer.tar.gz; cd installer; make install is okay for you? But curl https://example.com/installer.sh https://example.com/installer.sh | bash is not? Why?
    - sudosysgen 7y ago
      I'm fine with the second too as long as the host is trustworthy and it's always https. Most of the time it isn't.
GordonS 7y ago
Whether it's `sudo make install` or `curl | bash`, in both cases you have the opportunity to first inspect the code that will be executed.
- Avamander 7y ago
  You don't have the opportunity in the latter case. https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...
  - GordonS 7y ago
    Sorry, I don't follow. If I have a makefile, I can inspect it and see what it does. If I have shell script (or indeed a makefile!) that calls `curl | bash`, I can inspect that shell script and see the URL that is used with curl, and then inspect the contents that the URL returns.
    - Avamander 7y ago
      You can't see what comes from `curl | bash` before you actually pipe it to bash, click the link and read the article please.
      - GordonS 7y ago
        OK, I see - in theory, an attacker in control of the backend could write a handler that could craft a bash script that writes different content when `curl | bash` is used. TBH, while I take your point, I do think it's a little disingenuous of you to claim that "You don't have the opportunity" to inspect the script prior to executing it - you ordinarily will, but can't in the unlikely event of an attack like the article describes, which would require an attacker to be in full control of the web server. Off the top of my head, this could be mitigated in a couple of ways: 1. Hash a known-good script and check the hash matches prior to executing (this does however mean that you need to update the hash every time the remote script is changed) 2. Use curl to download the remote script to a local file first, and provide the opportunity to inspect it prior to piping it into bash

Doxin 7y ago

Basically all makefiles you run into in the wild for mature projects allow you to install it with a prefix. e.g. into the home folder. No need to sudo anything if you do that.

markhahn 7y ago
This is an important point lost in the noise. The problem is that cattle should apply only to containers, not hosts or VMs. Why? root. Which is also why Docker is a nonstarter for anyone who wants to use containers securely.