The Principal of Least Privilege suggests that network services should not run with powerful and unnecessary capabilities. History teaches us that this is painfully necessary; 25 years ago Sendmail and BIND ran as root, and shifted to run as non-privileged users to limit the damage demonstrated by numerous buffer overflows and other attacks. Alternative mail servers like Postfix and qmail were foundationally designed to run as non-root users, and the user context of Apache was an item on every checklist I've ever seen to secure Apache.

However, running a service as root is not a vulnerability per se; to quote OWASP,

The failure to drop system privileges when it is reasonable to do so is not a vulnerability by itself. It does, however, serve to significantly increase the Severity of other vulnerabilities.

So, for example, there's no OWASP Top Ten saying "Don't run services as root." Just other issues (like 2004-A5 "Buffer Overflows") whose impact is made more severe if the service is run as root.

Which makes it difficult to convince non-Security personnel that this is a Bad Thing.

So my question:

Can you point me to any cite-able references from reputable authorities that can be used to impress upon non-Security personnel (e.g. developers, IT, management) the importance of not running services with root privileges?

  • I'm guessing that there unimpressed with statements coming from the #15 all-time highest rep user on security.SE. How sad :( – Neil Smithline Jan 7 '16 at 20:20
  • @NeilSmithline, It's hard to sell security on the weight of "Because I say so" unless you're Bruce Schneier. People want citations to give weight to an argument; on the other side of the equation is "(Very Large Software Vendor) ships it running as root, and only supports that configuration. If they're so wrong to do so, why can't you cite other sources validating what you say?" (And, OMG, #15? I had no idea.) – gowenfawr Jan 7 '16 at 20:40

Not sure which kind of reference you're looking for, but The Principle of Least Privilege was first enunciated by Saltzer and Schroeder in their 1974 paper "The Protection of Information in Computer Systems":

Every program and every user of the system should operate using the least set of privileges necessary to complete the job. Primarily, this principle limits the damage that can result from an accident or error. It also reduces the number of potential interactions among privileged programs to the minimum for correct operation, so that unintentional, unwanted, or improper uses of privilege are less likely to occur. Thus, if a question arises related to misuse of a privilege, the number of programs that must be audited is minimized. Put another way, if a mechanism can provide "firewalls," the principle of least privilege provides a rationale for where to install the firewalls. The military security rule of "need-to-know" is an example of this principle.

(Saltzer, Jerome H. (1974). "Protection and the control of information sharing in multics". Communications of the ACM 17 (7): 389. doi:10.1145/361011.361067. ISSN 0001-0782.)

The full paper can be read here.

That should be a valid enough reference.

| improve this answer | |
  • That's an excellent reference and I'm glad to see it. However, citing a 40-year-old scientific paper helps define the problem, it doesn't help convince non-Security people that anything built today should change - from their point of view, if this paper is so true, how did this software get written the way it was decades later? – gowenfawr Jan 7 '16 at 20:49
  • Because it happens that programmers (for laziness, incompetence, rush, or often for simple mistake) don't respect that principle. – dr_ Jan 8 '16 at 8:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.