Permission requirements for OneAgent installation and operation on Linux

To fully automate the monitoring of your operating systems, processes, and network interfaces DESK requires privileged access to your operating system during both installation and operation.

Installation

OneAgent requires root privileges for:

• Installing OneAgent components in system library directories.
• Setting up /etc/ld.so.preload to automatically monitor processes.
• Adapting SELinux policies to allow for the monitoring of processes.

If you have Log Monitoring enabled, root privileges are also required for:

• Creating the DESK Log Monitoring OneAgent configuration file, which stores security flags (for example, log content access and log auto-detection) and rules that define files that should be treated as log files (based on file extension and location).

Operation

DESK OneAgent requires root privileges to:

• Access the list of open sockets for each process.
• Access the list of libraries loaded for each process.
• Access the name and path of the executable file for each process.
• Access command line parameters for each process.
• Monitor network traffic.
• Read application configuration files.
• Parse executables for Go Discovery.
• Gather monitoring data related to Docker containers.

If you have Log Monitoring enabled, root privileges are also required for:

• Accessing system logs: /var/log/syslog and /var/log/messages.
• Accessing the list of open file handlers for each process (/proc file system).
• Accessing the log file for each process.

System logs downloaded by OneAgent

OneAgent downloads specific system logs so that DESK can diagnose issues that may be caused by conditions in your environment. Most often such issues are related to deep monitoring or auto-update installations.

List of system logs downloaded by OneAgent

/var/log/boot.log
/var/log/dmesg
/var/log/dpkg.log
/var/log/kern.log
/var/log/messages
/var/log/syslog
/var/log/yum.log
/var/log/audit/audit.log
/var/log/zypper.log

Output of /usr/sbin/apparmor_status command

Output of /bin/journalctl -t auditd command

Revoke access to system logs

To revoke access to Linux system logs, invoke the installer using the DISABLE_SYSTEM_LOGS_ACCESS=[0|1] parameter.

• 1 disables access, which means that these logs won't be downloaded.
• 0 grants access to system logs.

Usage example: ./DESK-OneAgent-Linux.sh DISABLE_SYSTEM_LOGS_ACCESS=1

Note:
Disabling system log access limits our ability to diagnose and solve issues proactively. With access to system logs revoked, you may need to manually provide DESK with the contents of your system logs to help us diagnose issues within your environment.

Linux non-privileged mode

You can install OneAgent in non-privileged mode, in which superuser privileges are used once to initiate the installation process.

Then, OneAgent is run under an unprivileged user, retaining the complete set of functionalities.

See OneAgent installation on Linux to learn how to enable non-privileged mode during OneAgent installation.

Installation

OneAgent installer run in non-privileged mode requires superuser privileges to:

• Set file capabilities for OneAgent binaries located at /opt/desk/oneagent/agent/lib[64]/*.
• Invoke the oneagent service script to start oneagentwatchdog.
• On systems with systemd, communicate with systemd daemon via d-bus to run the following commands:
  • systemctl <start|stop|enable|disable> oneagent.service
  • systemctl daemon-reload
• On systems with SysV, execute /sbin/chkconfig to add the oneagent service script to autostart or to remove it.
• Write to /proc/sys/kernel/core_pattern.

Superuser privileges are dropped when the DESK OneAgent service script is executed:

• On systems with systemd, the unprivileged user is included in the service definition (unit file). Thus, the systemd daemon runs the OneAgent service script in unprivileged mode.
• On systems with SysV, the privileges are dropped in the script when starting the OneAgent Watchdog process.

DESK OneAgent Watchdog starts and runs all other processes under an unprivileged user without superuser access. OneAgent binaries leverage the following Linux System Capabilities.

Binary	Linux System Capabilities
oneagentwatchdog	cap_sys_resource1- for setting system resource limits when starting OneAgent processes
oneagentos	cap_dac_override - for filesystem access cap_chown2- for setting ownership of files replaced in the filesystem, e.g. runc binary cap_fowner - for setting ownership of files replaced in the filesystem cap_sys_ptrace - for reading data from /proc pseudo-filesystem and tracing processes cap_setuid3- for temporary elevation of privileges to execute certain operations. For details, see Automatic updates and operation. cap_kill 2, 4 - required by installer during auto-update cap_setfcap 2, 4 - required by installer during auto-update cap_fsetid 2, 4 - required by installer during auto-update
oneagentnetwork	cap_net_raw - for opening raw sockets cap_net_admin5- for reading network interface information
oneagentloganalytics	cap_dac_read_search - for access to all logs stored on host cap_sys_ptrace - for reading data from /proc pseudo-filesystem
oneagentplugin	cap_set_gid1- for adding docker to the process supplementary groups list, which allows for the container data to be retrieved
oneagenthelper	cap_sys_admin - for mount() syscall cap_dac_override - for inspection and modification of filesystems of the running containers cap_sys_ptrace - for tracing the Docker daemon cap_sys_chroot - for chroot() syscall cap_fowner - for changing ownership and permissions of files within container filesystem cap_fsetid - for changing ownership and permissions of files within container filesystem
OneAgent Installer executed during auto-update	cap_dac_override - for filesystem access cap_chown - for filesystem access cap_fowner - for filesystem access cap_fsetid - for filesystem access cap_kill - to be able to signal all the running processes, e.g. stopped orphaned OneAgent processes cap_setfcap - for setting Linux Filesystem capabilities file capabilities on agent binaries during the installation
oneagentosconfig	cap_setuid 4- for execution of privileged operations during the installation process

¹ Required only during initialization phase and is unconditionally dropped afterwards.
² Kept in permitted set only and raised to the effective set when needed.
³ Only if ambient capabilities aren't supported.
⁴ Only if ambient capabilities are supported.
⁵ Only on kernels older than 2.6.33.

Installing OneAgent in non-privileged mode on a filesystem mounted as noexec or nosuid isn't possible. In such cases, the installer ignores the NON_ROOT_MODE=1 parameter and installs OneAgent in standard mode.

Automatic updates and operation

The scope of privileges required by OneAgent depends on whether or not the kernel supports Linux ambient capabilities. As a general rule, kernel 4.3+ supports ambient capabilities. However, in the case of Red Hat Enterprise Linux, these may be supported in older kernel versions, because of the Red Hat policy to backport patches. This makes ambient capabilities supported by kernel versions as old as 3.10.x.

Kernels with ambient capabilities (version 4.3+)

During the automatic update, the installer starts under an unprivileged dtuser with proper ambient capabilities set. OneAgent doesn't require root access to perform the automatic update.

Red Hat Enterprise Linux 7 has a too low systemd (v219 instead of the required v221), and to be able to run automatic updates in non-privileged mode, we're temporarily elevating the privileges to run systemctl <start|stop|enable|disable> oneagent.service.

Kernels without ambient capabilities (version 2.6.26 to 4.3)

DESK OneAgent will work under the non-privileged dtuser in the majority of cases. When the kernel doesn't provide ambient capabilities, it automatically elevates its privileges to the superuser level using setuid(0) in the following cases:

• DESK OneAgent automatic updates
• Host OSI ID generation on Azure hosts
• Docker containers properties detection
• Self-diagnostics

If you don't want to grant the superuser permission level to DESK OneAgent, you can disable it by adding the DISABLE_ROOT_FALLBACK=1 parameter to the DESK OneAgent installation command. For example:

sudo /bin/sh DESK-Agent-Linux-1.0.0.sh NON_ROOT_MODE=1 DISABLE_ROOT_FALLBACK=1

In such cases, you must perform manual updates on individual hosts. We don't recommend using the DISABLE_ROOT_FALLBACK=1 parameter for OneAgents on Azure or Docker containers.

Non-privileged mode and Linux Filesystem Capabilities

Linux Filesystem Capabilities are required to install OneAgent in non-privileged mode. SUSE Linux Enterprise Server 11 has Linux Filesystem Capabilities disabled by default. These capabilities may also be disabled in other supported Linux distributions or they may be the result of a custom configuration. Since version 1.171, the OneAgent installer prints the following message if Linux Filesystem Capabilities are disabled:

Warning: Failed to enable non-privileged mode, kernel does not support file capabilities.

You can also check the kernel boot options to see if Linux Filesystem Capabilities are enabled. Run the following command to check your kernel boot options.

$ cat /proc/cmdline

If you find file_caps=1 in the output, your setup is fine.

To enable Linux Filesystem Capabilities, add file_caps=1 to your kernel boot options. For example, on SUSE Linux Enterprise Server 11, use YaST, edit kernel boot options, add file_caps=1 and reboot the machine.

How do I know if I've successfully enabled non-privileged mode?

The installer prints a message at the end of DESK OneAgent installation. Depending on the kernel version and its support for ambient capabilities, you will see one of the following messages:

Non-privileged mode is enabled— The kernel supports ambient capabilities, the root access is not used for updates or operation.

Enabled non-privileged mode, but ambient capabilities are not supported by kernel— The kernel is within the minimum supported version, but due to non-supported ambient capabilities, DESK OneAgent needs to elevate privileges in select cases, see above.

Failed to enable non-privileged mode— The kernel doesn't meet the minimum version requirements to enable non-privileged mode.