Do you know if there is a select group that reviews source changes to the installer package and ports installer? This seems like a good entry point to slip in malicious binaries as root. Therefore I'm curious if there is a good security lock on it.
Thanks again for your help On Tue, Nov 6, 2018 at 12:54 PM Ryan Schmidt <[email protected]> wrote: > > > On Nov 6, 2018, at 09:14, Nicholas Papadonis wrote: > > > This article goes into depth on how Homebrew opens OSX to a number of > security issues. I'm curious if a security expert could comment if similar > vulnerabilities exist with Macports. > > > > One vulnerability is a malicious program acquiring the administrators > password. The attack is opened up when Homebrew modifies /usr/local/bin > permissions for r/w by a non-root user. This permission change allows an > installed brew app to modify other binaries in this path, for instance > sudo. Homebrew defaults the path prefix as follows /usr/local/bin:/usr/bin > and therefore the malicious binary can take advantage of this by inserting > another fake malicious binary. > > > > The article is as follows: > > > https://applehelpwriter.com/2018/03/21/how-homebrew-invites-users-to-get-pwned/ > > More vulnerabilities here: > > https://hackerone.com/homebrew/ > > > > The author claims that Macports is more secure because the installed > explicitly uses root privilege during package installation. > > > > Are there any security experts out there that can comment on the > security impact of using Homebrew and Macports? To be more secure should > one use all their Unix applications in a emulated Linux VirtualBox session? > > > > Thanks for any insight you may have. > > > 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). > >
