I read (here and here) that Homebrew (the Unix package manager) is a significant Mac security risk. An attack is allowed because Homebrew makes /usr/local/bin writable without root user privilege, which allows another Homebrew process to write a malicious process into this directory tree. The /usr/local/bin tree is by default prefixed before /usr/bin in the path for the shell. As such, an attacker could inject a malicious binary to change the clock or steal an administrator's password (malicious sudo for instance).
Is there anyone out there aware of these vulnerabilities? Does anyone have a better method of gaining access to critical Unix commands without impacting the security of the end user's terminal (MacBook w/ OSX for instance)? Do you use Macports which relies on a package manager that installs using root privilege to /opt? Do you perform all your Unix shell work in an emulator like Virtual Box or VMWare?
I know there are many security holes starting with manufacturing and as soon a software app is installed. I'm very curious on best practices from a security expert on this.
UPDATE 2018-11-07
I checked with the macports mailing list and received quick detailed replies. Unfortunately, no response with details on functionality from the Homebrew forum. At this point, I suspect macports has better security functionality. There can always be a hole somewhere and to be truly secure, I will consider installing these open source applications in a self contained emulated container. For instance using VirtualBox, VMWare or Parallels. This way, if there is a security issue, it will be contained and not expose access to the Mac Keychain or other critical data.
UPDATE received from macports mailing list
Installing MacPorts using the installer package posted on our web page requires an administrator password, and the files and directories it installs are owned by root, meaning nobody but an administrator can change them. It also creates a normal unprivileged user account called "macports" for MacPorts to use later.
Using MacPorts as installed in this way also requires an administrator password. The files MacPorts ports install are usually owned by root, though individual ports can make their own decisions about that. For example, a database server port might create a special user account to be used by the database server when it's running, and it might install an empty directory where the files that the database server will write can live, and the owner of that directory would be set to that new user account.
When you invoke the "port" command with "sudo" and provide your administrator password, MacPorts switches to the unprivileged "macports" user. At that point it no longer has root privileges so even if a malicious portfile were committed that tried to do this, it could not modify files outside of its build directory. MacPorts elevates back to root privileges when doing something that requires root access, for example for the final step that actually installs the files into the /opt/local prefix.
It is possible to build MacPorts from source configured not to use root access, and if you do that, you don't get the above protections. We don't recommend doing this.
MacPorts keeps track of what files each port installs and does not permit one port to overwrite another port's files (unless the user requests this by using the -f flag, so the user should refrain from habitually using this flag).
Another post
It is also to be noted that homebrew can not suddenly change itself to deliver this degree of security without a fairly complete rehash of the way it works, and most/many/all of it's "advantages" of installing in /usr/local that have served to make it popular would then be totally lost, and most likely many/most/all of it's formulae would need to be rewritten to accommodate this change. Many of them at present assume things are found automatically in /usr/local .
homebrew has been popular because it's "easy" -- it's files in /usr/local are found without intervention by any compiler or shell. However, that does not come without costs.
MacPorts requires more work to specifically include certain include paths, library paths, and executable paths -- but that comes with some knowledge of what you're actually getting, and the security of knowing that it can't be messed with without your permission.
