![]() ![]() However, that does not come without costs. Homebrew has been popular because it's "easy" - it's files in /usr/local are found without intervention by any compiler or shell. Many of them at present assume things are found automatically in /usr/local. 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. 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). 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. 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. 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. When you invoke the "port" command with "sudo" and provide your administrator password, MacPorts switches to the unprivileged "macports" user. 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. The files MacPorts ports install are usually owned by root, though individual ports can make their own decisions about that. Using MacPorts as installed in this way also requires an administrator password. It also creates a normal unprivileged user account called "macports" for MacPorts to use later. 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. UPDATE received from macports mailing list This way, if there is a security issue, it will be contained and not expose access to the Mac Keychain or other critical data. For instance using VirtualBox, VMWare or Parallels. 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. At this point, I suspect macports has better security functionality. Unfortunately, no response with details on functionality from the Homebrew forum. I checked with the macports mailing list and received quick detailed replies. I'm very curious on best practices from a security expert on this. I know there are many security holes starting with manufacturing and as soon a software app is installed. ![]() 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? As such, an attacker could inject a malicious binary to change the clock or steal an administrator's password (malicious sudo for instance). ![]() The /usr/local/bin tree is by default prefixed before /usr/bin in the path for the shell. 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. I read ( here and here) that Homebrew (the Unix package manager) is a significant Mac security risk.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |