Difference Between Running as root or a Service Account With a sudoers file entry

Question

I have an evolution of an Earlier Question.

Main Question: What are the meaningful differences between running a program as root, vs. via service account with a sudoers file entry?

I have to deploy a 3rd party software agent into my security-conscious customer's RHEL environment. The default installation results in the agent's files and folders being owned by root, and it is scheduled to run on startup, or shutdown, or via the crontab file; but either way it runs as a root process which no one in the security team seems to like.

The vendor have suggested that a more secure alternative is to execute the agent via a service account with a sudoers file entry: e.g.:

agent-user ALL=NOPASSWD: /opt/agent/agent-executable

But is this actually better from a security viewpoint? Or what is best practice in this situation?

The way I see it, the agent will get privileged access to the server either way. And the service account is a customisation that (while supported by the vendor) seems like an opportunity to make mistakes.

Is NOPASSWD: a security weakness, and would stipulating a shell of /sbin/nologin improve security?

score 2 · Accepted Answer · edited Jun 11 '20 at 10:02

What are the meaningful differences between running a program as root, vs. a via service account with a sudoers file entry?
But is this actually better from a security viewpoint? Or what is best practice in this situation?

TLDR

The end result is indeed the same: /opt/agent/agent-executable is running with root privileges, with all the risk associated with that level of privilege.

"Best practice is often just another opinion."

IMHO the sudo option is what I would recommend when a service consists of a main process and (many) components that don't need root privileges to function correctly and which will happily run along when using the agent-user identity , but there are some specific, easily identified components (like the agent-executable) do need such root access.
That requires both an admin to grant, and the main service to support, the ability to run those specific components in a modified context with elevated privileges. sudo is particularly suited for that (and a much better option than for instance setting a SUID bit on the executable).

Then you adhere to the security principle of least privilege.

When you for instance create a systemd unit such as this:

[Service]
User=agent-user
ExecStart=sudo /opt/agent/agent-executable

which instructs systemd (that runs as root) to switch to the identity of agent-user to run a service in an environment with reduced privileges. Then, as that restricted user, you use sudo to elevate the privileges again to run the service as root.
In that scenario you are just being silly and might as well start agent-executable as root from the start and do this:

[Service]
# User=root
ExecStart=/opt/agent/agent-executable

_{Note: there are some subtle differences the resulting environment when you start processes via sudo or systemd (with and without an explicit User=root) that are probably not relevant at this point in time.}

Is NOPASSWD: a security weakness?

In the case of services and automation often unavoidable.

Would stipulating a shell of /sbin/nologin improve security?

In general: not nearly as much as people think. See for instance this Q&A.

Difference Between Running as root or a Service Account With a sudoers file entry

1 Answers1

TLDR