8

Package manager Homebrew (I'm on OS X, but I'm curious about Unix-based security in general, as it pertains to directory permissions) set the owner of /usr/local/bin to my user (it's root by default, right?), which means that now I can install executables by simply moving them to /usr/local/bin (no sudo required).

  1. Am I right about this, that normally /usr/local/bin is owned by root?
  2. Isn't chowning /usr/local/bin with your normal user a huge security issue, because now any software that I run can install programs on my behalf without my password being required?
orokusaki
  • 2,693
  • 4
  • 28
  • 42

1 Answers1

6

From their FAQ, this is to avoid the dangerous practice of having to run arbitrary code off the internet as root when installing packages. It's a reasonable compromise for most users - Homebrew's generally used on a single person's development machine, not production multi-user servers.

Homebrew is designed to work without using sudo. You can decide to use it but we strongly recommend not to do so. If you have used sudo and run into a bug then it is likely to be the cause. Please don’t file a bug report unless you can reproduce it after reinstalling Homebrew from scratch without using sudo.

You should only ever sudo a tool you trust. Of course, you can trust Homebrew ;) But do you trust the multi-megabyte Makefile that Homebrew runs? Developers often understand C++ far better than they understand make syntax. It’s too high a risk to sudo such stuff. It could break your base system, or alter it subtly.

And indeed, we’ve seen some build scripts try to modify /usr even when the prefix was specified as something else entirely.

Did you chown root /Applications/TextMate.app? Probably not. So is it that important to chown root wget?

If you need to run Homebrew in a multi-user environment, consider creating a separate user account especially for use of Homebrew.

For why it doesn't just install in your ~, see the earlier FAQ question "Why does Homebrew prefer I install to /usr/local?".

ceejayoz
  • 32,469
  • 7
  • 81
  • 105
  • I know why they do it. This doesn't answer my question. My question is to figure out if what Homebrew is doing is a really really bad idea (despite the fact that it protects against another kind of attack). My question is the more broad: is it a bad idea to chown `/usr/local/bin` period, despite what convenience or other bad practices it helps avoid. – orokusaki Mar 15 '16 at 14:22
  • @orokusaki As they note in the FAQ, "Did you chown root /Applications/TextMate.app? Probably not." Like I said, it's a reasonable compromise for the average Homebrew install. – ceejayoz Mar 15 '16 at 14:23
  • 2
    Touché on their part (just checked - while I don't use TextMate, I did find several packages owned by me in `/Applications`), but it sounds like they're using on wrong to commit another, right? Why can't Homebrew ask you for your password during installation, not so that the installing program can run arbitrary code as `root`, but so that Homebrew can `chown root:admin` the installed package after the fact? Homebrew could manage the ownership of files and directories without allowing packages to run code as `root`, right? – orokusaki Mar 15 '16 at 14:27
  • @orokusaki "they're using on wrong to commit another" I think the argument is that your filesystem's security policy is only as strong as its weakest point. So if a person can already get arbitrary code execution and run, say, a keylogger, there's not much point to ensuring they can't also replace `wget`. That having been said, if it seemed at all likely Apple would change its security model in the near future, then homebrew should also change its security model. However, Apple is unlikely to make the changes necessary to run apps securely. – Parthian Shot Mar 15 '16 at 14:34
  • @ParthianShot ugh... this feels so icky to me, but I understand. Thanks for explaining. – orokusaki Mar 15 '16 at 14:35
  • @orokusaki As I noted, Homebrew's typically for single-user development machines being run by tech-savvy programmers. They've made a choice that not requiring sudo every time you run an installer/updater is safer for that demographic. – ceejayoz Mar 15 '16 at 14:35
  • 1
    @ceejayoz I understand that part. The more concerning part is that I should be able to make a mistake and run a program that does bad things, and then when I discover it does bad things, I should be able to get rid of it and be done with it. Instead, all that program has to do is `cp /usr/local/bin/`. It could leave behind powerful drops of poo that I will never know about, but which infect my machine for eternity. In the ideal world, an app can only change things in my home directory and below, meaning apps can affect my locally saved data, but not ruin my machine. – orokusaki Mar 15 '16 at 14:38
  • Frankly, the really stupid thing is that- even after over 40 years- most *nix-based systems don't have separate package manager accounts for each user's ~/bin . Even for a DAC security model, that's pretty weak. Realistically you should only need root for package management when you're installing a new kernel / some package which modifies the kernel. – Parthian Shot Mar 15 '16 at 14:39
  • 1
    Now, from the perspective of space efficiency, if everyone installs the same package separately, that's non-ideal. But you could always have an API whereby users register a package install request with the userland non-root package management daemon, it installs a package once, and for all users requesting that package it softlinks or hardlinks the necessary resources. There are systems that do that. Unfortunately they're not mainstream *nixes... :/ – Parthian Shot Mar 15 '16 at 14:41
  • @ParthianShot: And if `piskvor@localhost` installs, for example, osmosis 0.36.1, and then `parthianshot@localhost` installs osmosis 0.43.0, which drops some functionality, that's also decidedly non-ideal. – Piskvor left the building Mar 15 '16 at 14:58
  • 1
    @Piskvor There's a kinda cool operating system (which I admit I haven't actually tried out, but it sounds cool) called [NixOS](https://en.wikipedia.org/wiki/NixOS), which apparently solves a lot of those kinds of issues. – Parthian Shot Mar 15 '16 at 15:15