3 ms·

This works if you want it to be available for just you. Say for instance you have a dev server, so security isn't as big a deal* used by a team of people, all

by azanar 17y ago

This works if you want it to be available for just you. Say for instance you have a dev server, so security isn't as big a deal* used by a team of people, all of whom would want access to the same basic packages. It seems that /usr/local/ or some other world-visible place would be the location for this stuff. That you don't have to be root is the same way that you don't necessarily have to be root to install programs in the usual MacOS way of running a GUI installer. If you are part of admin, you're already privileged to sudo anyway, so the protection you get is primarily psychological; you type 'sudo', and it triggers the part of your brain that pays much closer attention to what you put on the command-line. But as I mentioned to rbanffy, it is very possible I am missing a key risk that makes this a very bad thing to do. I am open to enlightenment. ;-)

kree10 17y ago
Say there's a hole in your web browser that lets an attacker run arbitrary code. That's bad news for your home directory, but at least if the binaries on your machine (under /usr/local or wherever) are owned by root, the browser is running as "you" so it can't overwrite them with malware. Then again, making /usr/local writable by admins goes along with the OS X convention of giving admins write permission to /Applications but I'm not a fan of that either.
- jrockway 17y ago
  But of course, for the average user, losing all of his personal data is a lot worse than losing the default OS install. (For non-average users, the hacked binaries will secretly steal your personal information, so that's bad. But this only happens in real life... well, never.)
- azanar 17y ago
  Hmm. Good point. This becomes a much larger problem if something runs things from /usr/local with increased privileges -- something from launchd run as root, for instance. I was originally thinking just from the perspective of the active user, but a lot of things get run without the logged in user's knowledge, and with a varying level of privilege. Ok, yeah, I agree with the original poster of this thread: yikes, time to start chmodding things.
  - 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 ago
      ports 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.
dasil003 17y ago
True, but this is OS X. The dominating use case is solo workstations. Who uses OS X Server? I'm actually pretty excited to try out homebrew and install everything in ~/ with my new MBP which I'll purchase as soon as the next refresh comes. Currently I'm still on 10.5 with a system that has been forward ported via Time Machine backups and account copy-on-install going back to a 2004 PowerBook. The prospect of having a completely vanilla system with all customizations isolated to my home directory is pretty exciting.

by azanar 17y ago

kree10 17y ago

Say there's a hole in your web browser that lets an attacker run arbitrary code. That's bad news for your home directory, but at least if the binaries on your machine (under /usr/local or wherever) are owned by root, the browser is running as "you" so it can't overwrite them with malware. Then again, making /usr/local writable by admins goes along with the OS X convention of giving admins write permission to /Applications but I'm not a fan of that either.

jrockway 17y ago
But of course, for the average user, losing all of his personal data is a lot worse than losing the default OS install. (For non-average users, the hacked binaries will secretly steal your personal information, so that's bad. But this only happens in real life... well, never.)
azanar 17y ago
Hmm. Good point. This becomes a much larger problem if something runs things from /usr/local with increased privileges -- something from launchd run as root, for instance. I was originally thinking just from the perspective of the active user, but a lot of things get run without the logged in user's knowledge, and with a varying level of privilege. Ok, yeah, I agree with the original poster of this thread: yikes, time to start chmodding things.
- 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 ago
    ports 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.

dasil003 17y ago

True, but this is OS X. The dominating use case is solo workstations. Who uses OS X Server? I'm actually pretty excited to try out homebrew and install everything in ~/ with my new MBP which I'll purchase as soon as the next refresh comes. Currently I'm still on 10.5 with a system that has been forward ported via Time Machine backups and account copy-on-install going back to a 2004 PowerBook. The prospect of having a completely vanilla system with all customizations isolated to my home directory is pretty exciting.