Considerations before running the agent as an unprivileged user

Owned by Robin Gierse
Last updated: Sept 26, 2024 by Matthew Hierholzer
3 min read

Items to consider before running the Checkmk agent as an unprivileged user, for example, as described in this community guide.

APPLICABLE TO ALL CHECKMK VERSIONS

Table of Contents

Background

This article focuses on the Linux agent, but is generally valid for the Windows agent as well. Where relevant, exceptions are explicitly noted.

Considerations

I do not know what the agent does, so I do not want it to have high privileges.

This argument is actually invalid, as the agent is essentially a fully open-source shell script. Of course, there are some more components, but those are also freely inspectable on GitHub. Take your time to review the relevant components, so you can feel affirmed that no shenanigans are going on.

While the Windows ecosystem differs, all open-source sources can be reviewed and inspected.

Why does the agent run as root in the first place?

The following is a (non-extensive) list of reasons why the agent needs to run as root:

  • mk-job potentially needs to become different users, which can only be achieved as root.
  • Some system information is accessible to no one but root.
  • Automatic agent updates need root privileges to install the new agent package.

What about Remote Code Execution?

The agent is entirely read-only and does not accept any input from the outside whatsoever. There is some information handed to the agent by the Checkmk server exclusively, but this is expected, validated, sanitized, and does not affect the agent's operation in any dangerous way. Additionally, the agent controller - which takes care of communication leaving the host - is running separately from the agent as an unprivileged user, and it is the only component talking to the outside. Even when run with sudo, it drops the privileges instantly. The agent itself runs as root but cannot be contacted from the outside in any way.

On Windows, there is currently no such separation. Both the agent service and the agent controller run as local SYSTEM.

What if someone injects arbitrary files into the agent, e.g., into the plugins or configuration folder?

This is not a Checkmk security issue but rather one of the monitored host. If an attacker can access the OS with privileges to modify the agent, the agent cannot protect itself. In such a scenario, you have far greater concerns than the Checkmk agent. We can only ensure that the agent itself is not a security concern from the outside.

I fear someone will compromise the agent's supply chain to escalate privileges.

Our Linux and UNIX agents only rely on built-in operating system tools. So a supply chain attack would mean that practically all Linux and UNIX operating systems themselves would be vulnerable too, as OS-level tools would be the reason.

Pitfalls

You will lose automatic agent updates.

As the agent needs root privileges to update itself, you will lose this ability when running the agent as an unprivileged user.

You might lose monitoring data.

Without the correct permissions, the agent can not query relevant parts of the system for monitoring data. You will lose monitoring data if you just run the agent as a different user without further configuration.

Improperly configuring sudo can pose a significantly higher threat than directly running the agent as root.

Configuring sudo can be tricky; hence the risk of configuration errors is real. One common issue is that you lock yourself out, which is unfortunate. The by far greater risk is that your configuration is too open, and you allow more users than intended to run a command, or you allow one user to run more commands than intended. One way or the other, this can be a far greater security concern than running the agent as root in the first place.

Bottom line

It is technically possible and overall supported to run the Checkmk Agent as an unprivileged user. But you want to be aware of the pitfalls and considerations above.

In conclusion, the additional work and effort far outweigh the security benefits of running the agent as an unprivileged user. Hence, we do not recommend it.