5 ms·
I think it's much more likely that something bad will happen during a build with "sudo brew install some-package" than someone successfully hijacking, say, my S
by dhess 17y ago
I think it's much more likely that something bad will happen during a build with "sudo brew install some-package" than someone successfully hijacking, say, my Safari session and then installing a trojan in my user-writable /usr/local directory. This is Mac OS X we're talking about: if you've written an exploit like that, why would you bother attacking apps in a directory that doesn't even exist on the vast majority of Mac installs when you could just as easily modify something in /Applications instead, and exploit practically all of them?
Anyway, back to the dangers of using sudo with Homebrew or Macports. When you build software by hand, without a package manager, do you ever do it as root? I sure don't. But that's exactly what Macports does in its default configuration, and that's what Homebrew would require if you used it with a non-writeable /usr/local. It doesn't have to be a malicious attack, either: just a simple bug in the build system would suffice. For example, if a "clean" rule in a Makefile has a step that looks something like, god forbid, "rm -rf $(BUILD_ROOT)/" and you're running the make as root, you'd better hope that BUILD_ROOT is not defined to be "".
Ideally, all of these package managers would separate the step of building from the step of installing so that you would only need root privileges for the latter, a la Debian's sbuild and friends. Then using a traditional privileged /usr/local directory would be a no-brainer, for the theoretically smaller attack surface it would provide. But none of the Mac packaging systems work like that, to my knowledge. They go for the convenience of a single build+install command. Given that, I'll stick with my user-writable directory and risk the hijacking scenario.
- bl4k 17y agoports does have the separation, you fetch/build as the local user and run install escalated. running a fetch as root or blindly changing the permission structure of /usr/local should scare everybody.
- dhess 17y ago> ports does have the separation, you fetch/build as the local user and run install escalated. I see from the Macports 1.8 release notes that privilege dropping is supported. That's good news, but is it the default? The release notes indicate that you need to pass command-line options to get this behavior. I assume that most people just "sudo port install foopkg". > blindly changing the permission structure of /usr/local should scare everybody. On Mac OS X (as of Snow Leopard, anyway), there are no permissions to change, since /usr/local doesn't even exist until you create it. Nothing in the OS itself depends on it or anything that lives there. There's nothing special or privileged, neither by design nor by convention, about /usr/local on Mac OS X. Making it user-writable and using it with a package manager is no different than creating a 2nd home directory for that purpose. If you're running that rare bird that is a multi-user Mac and co-managing packages with other trusted users, then you can simply make it group-writable by those users. It's safer than giving them any sudo privileges.
- bl4k 17y ago$ port fetch wget $ port build wget $ sudo port install wget > "is no different than creating a 2nd home directory for that purpose" except that a million build scripts and make files out there assume /usr/local/ as a default location. setting up something like '/home/shared/' is not a problem, just don't mess with paths that are defaults
- dhess 17y agoThanks, I didn't know about fetch/build in Macports. > except that a million build scripts and make files out there assume /usr/local/ as a default location. setting up something like '/home/shared/' is not a problem, just don't mess with paths that are defaults Yet Macports puts everything in /opt/local and that doesn't cause any significant problems. I haven't run across a free software project in years that didn't have support for an install prefix. Anyway, I should have been more specific: on a Mac, making /usr/local user-writable and using it with a package manager is no different than creating a 2nd home directory for that purpose, from a security standpoint. I agree that putting things in /usr/local is the most logical place to put compiled software (mainly for consistency with one's own scripts that run on multiple platforms), and that's one of the reasons I use /usr/local with Homebrew instead of something in my home directory.