Running the Linux Agent Unprivileged, With Run as Root and Per-Command Audit

Updated November 5, 2026. This post first described a flow in which the dashboard asked the operator for the host's sudo password and the agent ran the command with sudo -S. No dashboard view showed that prompt, and the flow is retired. This version describes Run as root, which replaces it.

The Linux agent runs as an unprivileged service user. A Live Session shell command that needs root is sent with Run as root. The cloud API checks who sent it and whether the host allows it, and every root command is recorded in the dashboard audit log, the agent's audit log and the host journal. This post describes those checks, how the host runs the command, and what is recorded.

Agent privilege model

The Linux agent installs as the etducky user under a hardened systemd unit. The unit sets ProtectSystem=strict, so the agent sees /etc and most of the file system read-only, and its capability bounding set leaves out CAP_SYS_ADMIN, CAP_SYS_MODULE and CAP_AUDIT_CONTROL. cgroup limits cap CPU at 50%, memory at 512 MB, and task count at 256.

The sudoers drop-in at /etc/sudoers.d/etducky-rmm grants passwordless sudo for a narrow list: read-only diagnostics, the agent's own service restart, package operations through the allowlisted etducky-pm helper unit, repository subscription through the etducky-subscribe unit, network isolation, the on-device approval prompt, and the one Run as root command line described below. The full list is in the Linux agent documentation.

Who can send a root command

On a Linux agent, the Live Session shell has a Run as root checkbox beside the shell type. It starts unticked in every session. When a command arrives with it ticked, the API checks all of the following before anything is queued:

• The sender may run shell commands on agents in the organization. Every shell command passes this check.
• The sender holds the Linux root shell privilege. Workspace and organization owners hold it. Administrators and members hold it only when an owner grants it to them by name, and it cannot be attached to an invitation.
• The command was typed in the shell. Saved scripts cannot run as root, and commands the AI proposes never do.
• The shell type is bash or sh, and the command is at most 64 KB with no NUL characters.
• The agent's last capability report says Run as root is available. An agent reports that only when it is a release that carries Run as root and the host's root created /etc/etducky/root-shell.enabled.

A request that fails a check is refused with a sentence the shell shows, and nothing is sent to the agent. A root command still goes through the same blocked-command checks as any other shell command. The privilege is checked for every command, so a revoked grant stops the next one; for a grant made for the whole workspace, this can take up to a minute to reach the other organizations.

How the host runs it

The agent starts one fixed command line, which is the only form the sudoers rule allows:

sudo -n /usr/bin/systemd-run --pipe --wait --collect --quiet /opt/etducky/agent/scripts/etducky-root-shell.sh

The rule takes no arguments, so nothing on the command line can be changed. The agent writes a header line with the command id and timeout, then the command itself, to the script's standard input. systemd starts the script as its own service, outside the agent's sandbox, so the command has the same root access as a console session. That is the reason for systemd-run: a root child of the agent keeps the unit's restrictions, and writes under /proc/sys, modprobe and auditctl fail there.

The script is owned by root and sits under /opt/etducky/agent, which the agent's unit sees read-only. It refuses to run anything unless /etc/etducky/root-shell.enabled exists, is not a symlink, is owned by root and is not writable by a group or other users. The agent cannot create that file, because its unit sees /etc read-only. The script runs the command with bash, without profile files, in a clean environment, with empty input, and stops it when it passes its timeout (5 minutes for a Live Session command).

The host administrator turns Run as root on with:

sudo install -o root -g root -m 0644 /dev/null /etc/etducky/root-shell.enabled
sudo systemctl restart etducky-agent

Deleting the file turns it off. The script refuses from the next command, and the dashboard stops sending root commands after the next agent restart. Hosts installed with the .run installer have no sudoers file, so Run as root is not available there.

What is recorded

Record	Contents
Shell command row	The command text, the Run as root flag, the sender's user id and source address, timestamps, exit code and output.
Dashboard audit log entry shell_root_command	The sender, source address and browser user agent, the command's length and SHA-256, and the timeout. Written before the agent is told about the command.
Agent audit log	A line with the command id and the first 12 characters of the same SHA-256.
Host journal, tag etducky-root-shell, facility authpriv	The command id and SHA-256 before the command runs, and its exit code after it.

The SHA-256 is the same in every record, so an entry on the host can be matched with the dashboard entry. To read the host entries: sudo journalctl -t etducky-root-shell.

What this does and does not protect

On a host without the opt-in file, the Run as root rule grants nothing. On a host with it, the host administrator has accepted that the agent can start root commands, as the Windows agent, which runs as LocalSystem, always can. A compromised agent process on that host can start root commands too. What the design controls is who can send root commands from the dashboard, and that every one is recorded. Deleting the opt-in file turns it off.

If a dashboard account that holds the privilege is compromised, the attacker can send root commands to hosts that opted in. Each one carries that account's user id and source address in the command row and the audit log.

sudo in the shell

On Linux agents newer than 2.8.5.3, typing sudo in the Live Session shell does not ask for a password. sudo fails at once unless a rule in the drop-in covers the command, and the shell suggests Run as root. On Linux agents 2.8.5.3 and older, a sudo line still waits up to five minutes for a password prompt the dashboard does not show, and two such lines hold both of the agent's shell slots. Upgrade those agents.

Windows agent

The Windows agent runs as LocalSystem for ETW kernel access, so its shell commands already run with full rights and Run as root is not offered there. Each shell command is still recorded in the dashboard audit log.