6

As a Linux admin, is one of my jobs to carry out some sort of task to drop root privileges of the applications running on my systems?

Or do I simply rely upon the application developers to ensure they have written their code to do this?

3 Answers 3

9

As a Linux admin, is one of my jobs to carry out some sort of task to drop root privileges of the applications running on my systems?

Yes. It is your job make sure it is done. If the application doesn't do it, you have to notice that the application isn't doing it and do it yourself.

Or do I simply rely upon the application developers to ensure they have written their code to do this?

Don't rely on application developers to have done anything. There are plenty of tools available to a Linux system administrator for getting the facts of what applications are doing at runtime.

3

It is the duty of the application's programmer to ensure that the application drops root privileges and operates with unprivileged rights. If the application doesn't do this, there is nothing you can do about it -- apart from refraining to use the application, submit a bugreport to the dev, or implement the necessary changes yourself in the code.

On the other hand, it is you, as an admin, who chooses as which user the application starts; the golden rule is to never grant a process more privileges than it needs to run. So you can create a unprivileged user - have a look in /etc/passwd to get an idea of system accounts - and run the application as this user. (You rarely have to do this by hand; usually this is all taken care of when you install a software via the package manager.) However, if the application requires root privileges to start, and then fails to drop such privileges in the middle of the run, then it's out of your control.

For instance, older versions of sendmail required to run SUID root, which was a security hole if a remote attacker managed to successfully exploit a vulnerability of the program. If you had sendmail running uniquely as a mail relay, you could run it as an unprivileged user.

3
  • There is something you can do about an application's failure to drop privileges: submit a patch, or at least a bug report. You can judge from the maintainer's response whether they care about software security or not (even if their response is, "that's just a start; it breaks feature XYZ, and we have other areas we want to harden", that's better than "we don't care"). If you get the latter (or equivalently, no response), then start looking for alternatives! Dec 2, 2016 at 9:35
  • Also, if you're installing a properly packaged application, it should set up appropriate users and their privileges - any over-provision there should be reported to the package maintainer, who is not necessarily the application maintainer. Usually, the job of creating a suitable user is the admin's only when the application has been built locally. Dec 2, 2016 at 9:38
  • @TobySpeight Good point, I've added it to the answer.
    – dr_
    Dec 2, 2016 at 11:18
3

I would say that as sysadmins it is our job to give the least privilege possible to applications and users (that allow them to do their work).

A user deploying Tomcat/Java apps, or web pages, or deploying an app with database access seldom has few or little legitimate needs for root access.

Most frameworks also drop root by default nowadays.

For instance for devs here using Java frameworks we just give devs access to a non privileged user capable of deploying, and some sudo commands restricted to (re)start and stop a few key services.

I would go even further that it is not the business of the dev team to deal with production servers.

From my life experience often the dev team is just worried with getting their job done, and are not capable of getting security and capacity management right without planning, guidance, and proactive intervention from the sysadmin team.

Not the answer you're looking for? Browse other questions tagged .