3 ms·

> Instead, to instal in /usr/local it wants me to recursively chown /usr/local to myself, which is a Really Bad Idea (tm). Why is this a really bad idea for a

> Instead, to instal in /usr/local it wants me to recursively chown /usr/local to myself, which is a Really Bad Idea (tm). Why is this a really bad idea for a personal machine? The only problems I can think of are some subdirectories that are conventionally given some other user ownership to make running a related server under a specific user, and the problem of putting potentially arbitrary probably unreviewed executables in a system-wide path. But the former problem is one you wrestle with anyway if /usr/local is owned by root. And the latter problem... you're going to have some path where you're putting all this stuff, and it's either going to be a personally owned or system owned path. The system-owned choice means giving your package manager sudo and having to run things with sudo (which, without attention, means giving the executables system-wide access). What other problems does a personally owned path create? What's the alternative?

lisper 10y ago
> Why is this a really bad idea for a personal machine? It's a security risk. Having user access to /usr/local allows me (or, more to the point, an attacker running as me and not root) to surreptitiously replace system binaries, some of which may be run by other users. Some of those other users may have access to parts of the system that I don't have. Some of those other users may even be running as root. > What's the alternative? /usr/local/homebrew/bin. Or even better /opt/homebrew/bin. Or even better, a path that is set in an environment variable.
- lucaspiller 10y ago
  Other than being in a different directory, what difference is that going to make? You are going to have both in your $PATH in order to run the binaries, so if an attacker can write to either bad stuff could happen. Also you can actually install it wherever you like, this is just the default/recommended location: https://github.com/Homebrew/brew/blob/master/docs/Installation.md#untar-anywhere https://github.com/Homebrew/brew/blob/master/docs/Installati...
  - stcredzero 10y ago
    Other than being in a different directory, what difference is that going to make? Because, if they had picked their own directory and not a standard one like /usr/local/bin, then they would only be putting the homebrew installed binaries at risk. It would be better for defense in depth if they had not. As it is, all of their users are incentivized to unnecessarily give up a little security in favor of convenience. It's precisely that mindset that's one of the "enemies." (The other "enemy" is security without concern for convenience. We know from practice that's just as broken.) You are going to have both in your $PATH in order to run the binaries, so if an attacker can write to either bad stuff could happen. Normally, you'd need root privileges to write to /usr/local/bin. Since it's a very popular location for installing 3rd party tools, homebrew is effectively incentivizing users to have more writable executables than otherwise. Homebrew also aids security by making it easier for devs to keep executables updated. They also deserve credit for making something useful. I use homebrew as well. However, I still really wish they would've made a different decision about /usr/local/bin.
  - lisper 10y ago
    /usr/local/bin is a global resource populated by binaries run by many different users including root. Making it user-writable opens the door to privilege escalation attacks by replacing binaries that are then run by other users.
    - falsedan 10y ago
      Why would using /opt/homebrew/bin stop these sorts of attacks?
      - lisper 10y ago
        It would prevent privilege escalation attacks on binaries that I have already installed in /usr/local/bin. Yes, packages installed in /opt/homebrew/bin could be attacked separately, but at least the vulnerable binaries are isolated so it's easier to keep an eye on them and make sure none of them are ever run with privileges. But you're right: to really fix this problem requires that homebrew change its installation process entirely.
stephenr 10y ago
> What's the alternative? Install software as root, eg by invoking sudo. The "don't compile as root" argument is correct, that too is a bad idea. But that's exactly why traditional "./configure; make; sudo make install" instructions separate the initial build (using the default make target) from a the install target. It's why binary packages for basically every platform are built using a controlled, non root-user environment, but installed using root-equivalent permissions.

lisper 10y ago

> Why is this a really bad idea for a personal machine? It's a security risk. Having user access to /usr/local allows me (or, more to the point, an attacker running as me and not root) to surreptitiously replace system binaries, some of which may be run by other users. Some of those other users may have access to parts of the system that I don't have. Some of those other users may even be running as root. > What's the alternative? /usr/local/homebrew/bin. Or even better /opt/homebrew/bin. Or even better, a path that is set in an environment variable.

lucaspiller 10y ago
Other than being in a different directory, what difference is that going to make? You are going to have both in your $PATH in order to run the binaries, so if an attacker can write to either bad stuff could happen. Also you can actually install it wherever you like, this is just the default/recommended location: https://github.com/Homebrew/brew/blob/master/docs/Installation.md#untar-anywhere https://github.com/Homebrew/brew/blob/master/docs/Installati...
- stcredzero 10y ago
  Other than being in a different directory, what difference is that going to make? Because, if they had picked their own directory and not a standard one like /usr/local/bin, then they would only be putting the homebrew installed binaries at risk. It would be better for defense in depth if they had not. As it is, all of their users are incentivized to unnecessarily give up a little security in favor of convenience. It's precisely that mindset that's one of the "enemies." (The other "enemy" is security without concern for convenience. We know from practice that's just as broken.) You are going to have both in your $PATH in order to run the binaries, so if an attacker can write to either bad stuff could happen. Normally, you'd need root privileges to write to /usr/local/bin. Since it's a very popular location for installing 3rd party tools, homebrew is effectively incentivizing users to have more writable executables than otherwise. Homebrew also aids security by making it easier for devs to keep executables updated. They also deserve credit for making something useful. I use homebrew as well. However, I still really wish they would've made a different decision about /usr/local/bin.
- lisper 10y ago
  /usr/local/bin is a global resource populated by binaries run by many different users including root. Making it user-writable opens the door to privilege escalation attacks by replacing binaries that are then run by other users.
  - falsedan 10y ago
    Why would using /opt/homebrew/bin stop these sorts of attacks?
    - lisper 10y ago
      It would prevent privilege escalation attacks on binaries that I have already installed in /usr/local/bin. Yes, packages installed in /opt/homebrew/bin could be attacked separately, but at least the vulnerable binaries are isolated so it's easier to keep an eye on them and make sure none of them are ever run with privileges. But you're right: to really fix this problem requires that homebrew change its installation process entirely.

stephenr 10y ago

> What's the alternative? Install software as root, eg by invoking sudo. The "don't compile as root" argument is correct, that too is a bad idea. But that's exactly why traditional "./configure; make; sudo make install" instructions separate the initial build (using the default make target) from a the install target. It's why binary packages for basically every platform are built using a controlled, non root-user environment, but installed using root-equivalent permissions.