16

macports

  • binaries are useable from /opt/local/bin/, i.e. for tesseract

    bin$ which tesseract
/opt/local/bin/tesseract

bin$ ls /opt/local/bin/tesseract
-rwxr-xr-x  1 root  admin  28120 15 Sep  2016 /opt/local/bin/tesseract  

bin$ ls /opt/local/ | grep bin
drwxr-xr-x  719 root  admin  24446  6 Aug 19:55 bin

  • install requires sudo

sudo port install tesseract

homebrew

bin$ which packer
/usr/local/bin/packer   

bin$ ls /usr/local/bin/packer
lrwxr-xr-x  1 myuser  admin  33  7 Aug 14:28 /usr/local/bin/packer -> ../Cellar/packer/1.2.5/bin/packer

bin$ ls /usr/local | grep bin
drwxrwxr-x  41 myuser  admin  1394  7 Aug 14:28 bin
  • install does not require sudo

brew install packer

PATH

trimming out other software, this is my $PATH order:

/opt/local/bin  #macports
/usr/local/bin  #homebrew
/usr/bin        #Apple binaries

/usr/loca/bin permissions.

I believe, from https://apple.stackexchange.com/a/261710, that /usr/local/bin, before homebrew, starts out as root-writeable only:

drwxr-xr-x  26 root  wheel  -                 884 Oct 17 03:36 bin

Risks?

Is there a real difference between those 2 approaches? What happens if either port or brew itself has been hacked? What if the package you're installing has been hacked?

I realize that installing hacked stuff is going to end badly regardless, so, assuming brew/port are OK and the installed package isn't corrupted either, what about the implications of either approach when it comes to other malware trying to alter your system?

Looks to me as if /usr/local/bin is wide open and the binaries there can in effect take the place of any Apple programs. Should I be concerned?

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
Italian Philosophers 4 Monica
  • 372
  • 2
  • 15
  • IMHO of all your questions only the first one is really up for discussion, because as long as you are willing to install software you are prone to installing malicious software. – Tom K. Aug 14 '18 at 16:23
  • I think you are misreading my comment. While your first question is answerable and specific, your others are not. If you do not narrow down the threats you have described, these questions cannot be answered in a meaningful way. – Tom K. Aug 15 '18 at 17:28

2 Answers2

13

If I am understanding your question correctly, it boils down to:

Homebrew changes the permissions of /usr/local/bin from the default drwxr-xr-x root wheel to the less secure drwxrwxr-x myuser admin. What are the risks?

As you point out, your user (or anyone in the admin group, or any virus that manages to run as you) can now install software, including over-writing default system stuff.

How big of a problem is this?

Multi-user system

On a multi-user system like a server where there are other users logged in, this would be a big problem. I don't have access to a Mac, but I assume my linux box is similar enough; /usr/local/bin is empty (nothing to replace) but

$ echo $PATH
/usr/local/bin:/usr/bin:/home/mike/bin:/usr/local/sbin:/usr/sbin

So assuming that other users have the same bash config as me, then it looks in /usr/local/bin first. Therefore I could put a malacious program called ls in /usr/local/bin and the next time someone tries to navigate the filesystem, my code will run inside their user account. The nefarious possibilities are endless.

So I would agree with you that this is a problem on a multi-user server.

Single-user personal computer

For all intents and purposes, there is only one user on your laptop. xkcd illustrates this quite well:

xkcd authorization comic

If an attacker / malware / etc has already gotten inside your account, then they have all your data, it's only a matter of time until they keylog you typing your sudo password, so do you really care whether they install further malware in /usr/local/bin or put it in /home/myuser and add that to your path? The end result is the same.

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
  • 2
    I agree with your assessment, to a point. Security best practices in Unix world is not to execute programs from current directory, unless specifically told so. i.e. `./foo` will work, `foo` won't even if foo is on current directory. You can add `.` to $PATH but that's again considered a no-no. The reasoning behind that is to thwart malicious actors that don't have root privileges to write to $PATH directories but can write elsewhere. `/us/local/bin` being fairly open would seem to go against that intent. – Italian Philosophers 4 Monica Aug 15 '18 at 19:02
  • Uhh, sorta. We're mixing threat models a bit. The "Don't add `.` to your path" advice is to prevent you from accidentally executing a file that's harmlessly sitting in, for example, your `Downloads` folder. On the other hand, the threat model implied by `/usr/local/bin` being writable is that once an attacker has compromised your user account, they can spread malware to root locations. So there's also nothing stopping them from modifying your path via `/home/myuser/.bashrc` or the environment variable to add whatever folder they want to it. If it's a single-user system, does it matter where? – Mike Ounsworth Aug 15 '18 at 20:20
  • would you say then that the trade-off is increased risk, with `macports`, at package install, via `sudo port install ` vs `brew install `. if pkg is malicious, the `sudo` at install time makes that worse. but, with `brew`, the rest of the time the mac is somewhat less locked down, esp wrt multiple users, because of `usr/local/bin`'s more modifiable state? certainly if you mistakenly `sudo brew install ` you get a stern warning that it doesn't support `sudo` as that would be a big risk. – Italian Philosophers 4 Monica Aug 15 '18 at 21:25
  • I feel like we're splitting hairs. Presumably installing brew in the first place needed sudo? It looks like brew changes the owner:group of `/usr/local/bin` to `myuser:admin`, which means that admins can now modify `/usr/local/bin` without needing sudo, but they're admins, so they have sudo anyway, right? Maybe it slightly broadens the damage that can be done with a compromised admin account (maybe ... there's already a lot of damage that can be done...) – Mike Ounsworth Aug 15 '18 at 21:39
  • Basically I feel like it doesn't matter: if it's a security-hardened server then I would hope your admins are trustworthy and they are not installing unvetted packages. If it's a personal computer then it doesn't matter either because as the xkcd comic points out: the important stuff doesn't need sudo anyway. So my professional opinion is that it doesn't matter. – Mike Ounsworth Aug 15 '18 at 21:43
  • txs for your inputs, learned quite a lot being walked through on this. 2 things that I don't quite agree with: this XKCD is far as I can tell, about what happens when your computer is stolen. My question about is about hardening wrt normal operations. Second, as far as I understand, you are in the `admin` group as soon as you are the mac's main (admin) user. It's not optional or a sign of special favor. Per the `homebrew` take, that gives you write access to execute capable directories. Whereas `macports` would have you sudo. Having said all that, I truly appreciate your insights, TXS! – Italian Philosophers 4 Monica Aug 21 '18 at 20:42
  • @ItalianPhilosopher I think that for a personal laptop, the following are all within normal use, and all completely equivalent in terms of how you protect against them: "Someone steals your laptop while you are logged in", "Someone uses your computer while you're logged in", "Some piece of malicious software gets on to your system and runs as you". – Mike Ounsworth Aug 21 '18 at 21:40
  • Let my try the question this way: assuming we're talking about a single-user macbook, what is `sudo` actually protecting? Does it matter whether or not the single user is in the `admin` group or not? Why is writing to `/usr/local/bin` any more dangerous than writing to `/home/user/bin` and then adding that to your path to make it executable? xkcd's point is that talking about the `admin` group or `sudo` as a security feature _only makes sense on a multi-user system_. – Mike Ounsworth Aug 21 '18 at 21:42
  • 1
    ah, yes, I keep on forgetting editing `~/.profile`'s path. again, this is why I appreciated your insights. – Italian Philosophers 4 Monica Aug 21 '18 at 21:54
  • that hairy thing on a slide seems symbolic. from this perspective security turns into a job security rather than its healthier alternatives, e.g. simple and transparent system design – IlliakaillI Feb 24 '21 at 02:11
3

The fact that homebrew opens up /usr/local has been one of the reasons for me to move to MacPorts (the other was that MacPorts is better when the target is system-level additions, which may include all kinds of things that require su privileges to install properly so they are installed safely). MacPorts having its own library tree and being fully independent from macOS itself is also important for me, I don't want a macOS update kill my MacPorts additions (as these are services multiple users will depend on them). The price to pay is that you have to do all the LCM and patching (by updating ports).

So, on my macOS Server, where I am running postfix, dovecot, nginx, minio, etc. I am using MacPorts for these.

I started out with homebrew (as it is mentioned everywhere) but as homebrew does not have (probably is pretty much incapable in a reasonable way) postfix, I started looking into MacPorts and got convinced MacPorts is better (for me).

The MacPorts system installs software using su privileges, so you have to trust the fact that the "Port" has not been tampered with using patches or alternate source downloads (MacPorts compiles software, no binaries are downloaded, which I think is an advantage as well). Given that you download Ports from a common repo with reasonably strict access control, the risk is minimal, I think. And the resulting environment on your system in /opt is — as a result — better protected.

gctwnl
  • 131
  • 1