I have used homebrew (https://brew.sh/) for many years and have been extremely happy with the functionality. However, I have become more and more uneasy about the advice (in fact, almost a requirement) to change ownership of /usr/local/bin (and a few other subdirectories under /usr/local) from root/wheel to a user account. The reasons for my concern are the same as those explained here: https://applehelpwriter.com/2018/03/21/how-homebrew-invites-users-to-get-pwned/ and here: https://saagarjha.com/blog/2019/04/26/thoughts-on-macos-package-managers/

There are a couple of other installation options, including to create a separate folder under which to install homebrew (https://docs.brew.sh/Installation). But then you get prompted to add this new ~/homebrew/bin to your PATH, which still seems (to me) to leave the same security vulnerability. Of course I could not add this new directory to the PATH and instead use shell aliases for the homebrew software I need, or only modify the PATH when I need to, but this doesn't seem either practical or entirely robust either.

Instead I am currently using another approach. I have created a new user account via macOS purely for the benefit of homebrew, and then logged in as that user to install homebrew and ONLY to install homebrew. Then I undid the group writeable changes made by homebrew using:

sudo chmod g-w /usr/local/*

EDIT: this would probably have been better as:

sudo chgrp -R wheel /usr/local/*

Finally, I logged back out of the homebrew account and back into my main account, from where I have read-only access to /usr/local (i.e. the same as before hombrew was installed).

My thinking is that the ownership of /usr/local/bin and friends is not under my day-to-day account and therefore any malicious script cannot modify these files without sudo. The homebrew user account would not represent a security threat as I do not use it for anything other than homebrew. Running brew install etc first requires me to su to the homebrew user account, but that is an extremely acceptable compromise as far as I am concerned. The only other downside is the disk space required to carry the “dummy” homebrew account, but that is only 90k…

My question is: have I missed anything from a security perspective that would make this a bad idea, or somehow fail to give me the security benefits that I think it does? Does anybody else use this tactic, or have any suggestions for how it could be improved? Or am I inviting problems with homebrew functionality in removing the write permissions for the admin group (so far everything has worked fine for me, but maybe something will crop up later?).

By the way, here is a related thread, although it is quite old and the answers there do not really address my question: Are my permissions for /usr/local/ correct?

Edit: this is a single-user machine, so I do not have any worries about other accounts also needing to use homebrew on the same machine.

  • 1
    Is this your personal machine mainly/only used by yourself, or a machine in a lab/shared environment? Which attacks/risks are you trying to protect yourself here?
    – nohillside
    Jul 15 at 12:14
  • 1
    Having said that, I have a daily-used non-admin account and sudo/ssh to an admin account to update Homebrew. Works well.
    – nohillside
    Jul 15 at 12:15
  • @nohillside Good question: this is purely my own machine, no others have physical access to it (it is tied into the remote management at my university so IT can ssh onto it, but they don’t do that often). I’ll update my question. As for what risk I am worried about: mostly that I may download and run a script that creates eg /usr/local/bin/sudo with malicious intent without needing to raise any “red flag” by requesting sudo/admin access. I am of course careful about executing scripts that I didn’t create, but I would rather be safe than sorry. Jul 15 at 12:25
  • 2
    Well done for reinventing the way MacPorts does this. Basically all download and compilation is done as the use macports, then install to /opt/local is done as root.
    – mmmmmm
    Jul 15 at 13:17
  • Actually not just macports this is how my company implemented releases of programs in the 1990s but the account doing the build was separate and not accessible by developer, so I suspect a standard Unix way of doing things
    – mmmmmm
    Jul 19 at 15:45

You must log in to answer this question.

Browse other questions tagged .