7

The Sendmail Installation and Operation Guide (§1.3.1) asserts:

For security reasons, /, /usr, and /usr/sbin should be owned by root, mode 07552
[...]
2Some vendors ship them owned by bin; this creates a security hole that is not actually related to sendmail. [...]

Why is this a security hole? Are there systems that run processes as user bin?

Steven Taschuk
  • 173

1 Answers1

5

Disregarding the "group" and "other" permissions, something being owned by root means only root has total control over the file/directory.

Something being owned by another user means that user in addition to root has total control over that file. Now you have two entities that have total control over that file/directory, whereas before you only had one.

This is particularly bad for executables placed in the standard locations as other users on the system may call it, and the owning user can replace the executable at his/her will, possibly using it for malicious means. Hopefully on this system the user "bin" is prevented from logging in interactively via a null shell or similar in /etc/passwd. I'm betting this is done to enable a package manager to not have to run as root. This in of itself probably brings other benefits.

However, if only the directory /usr/sbin is owned by bin, and not executables within, then it's not as bad.

LawrenceC
  • 10,992
  • 1
    “if only the directory /usr/sbin is owned by bin, and not executables within, then it's not as bad”: No! It's just as bad (well, except insofar as it's rarely a problem in practice). If bin has write permission on /usr/sbin, it can remove the executables that are there and replace them by the ones it chooses. – Gilles 'SO- stop being evil' Jun 17 '12 at 23:32