[Idea] rootless with optional sudo support

[sebastianschauenburg]

Your idea

If I understand correctly, the agent requires root permissions (e.g. runs as root).

As a feature request, I would want to ask to consider a rootless approach.
This could be implemented by using sudo for the parts which actually really require root.
And/or perhaps making the parts which require root permissions, optional.

[g-bougard]

Hi @sebastianschauenburg

yes, it actually requires to run as root on unix/linux and as Administrator on windows. It does so as many inventory data is only available in that context. And, as glpi-agent is a fork of fusioninventory-agent, it historically does like that since the beginning (more than 15 years ago).

I don't think it's a good idea to change that logic today. It would require a lot of changes and I'm sure users will complain about everything this can involve.

Of course we could probably make the root mode remain the default and have a rootless one choose by option. But there's a huge work behind to achieve such an option.

So can you clarify why you think it's a good idea ?

[wodny]

Hi, I stumbled upon this comment searching for information about the agent's design.

Generally, separating privileged and unprivileged operations seems to be beneficial from a security standpoint. That is why daemons and some admin tools run under a dedicated UID whenever they can. There are many options:

• environment can be provided by the init system and the daemon doesn't run as root at all,
• root process can drop privileges with setuid()/seteuid() right after gaining required resources,
• some of the privileges can be acquired using better targeted capabilities.

Examples from two important projects:

• OpenSSH server runs the most complex code of the authentication procedure (including network exchange) in a separate unprivileged process,
• APT, the Debian package manager, runs many of its tasks in separate unprivileged processes since around 2014.

They both initially have full root capabilities.

I think there is a lot of information one can gather running under a regular user - things like list of installed packages, running kernel, disk space etc.

So the architecture that comes to mind is:

• core process taking simple commands from a scheduler (local or network-attached) and spawning child processes dropping privileges by default or retaining them for selected tasks where it's absolutely necessary,
• child processes scheduling tasks,
  • this includes the HTTP server of the agent,
• child processes of the tasks.

Additionally, I am confused after reading the agent's documentation. It defines three modes of operation:

Execution mode	Execution schedule	Execution plan
Managed	Server-side control	Server-side control
Half-managed	Agent-side control	Server-side control
Autonomous	Agent-side control	Agent-side control

Managed mode
[...] It also involves having a privileged process listening on a network port [...]

Half-managed mode
[...] it may as well be a user session start script [...]

For all modes the commands are prefixed with a $, not #, which by convention mean the user and root respectively.

What I cannot reconcile is:

• on one hand having the statement:

  it actually requires to run as root on unix/linux

• on other hand having the half-managed mode available/mentioned in documentation,
• on yet another:
  • note about a privileged process in managed mode,
  • note about half-managed mode that can run under a regular user,
  • both of the modes having the execution plan decided by the server so they have to require exactly the same privileges to run the tasks.

The agent's default HTTP listening port is 62354 so binding to it does not require root privileges.

I absolutely understand that changing the architecture is no simple task and I am rather interested in determining if I understand the current state of things correctly as it will help me assess security risks of running the agent.