Describe the bug

The safe-reload script is invoked upon systemctl reload icinga2.service as root (see ExecReload in service unit file).

The icinga processes typically run with lowered privileges, e.g. as icinga:icinga on openSUSE Tumbleweed. The PID file there is found in this location:

root# ls -lhd /run/icinga2/icinga2.pid
-rw-r--r-- 1 icinga icinga 5 Jul 31 10:20 /run/icinga2/icinga2.pid
root# ls -lhd /run/icinga2/
drwxr-xr-x 3 icinga icingacmd 80 Jul 31 10:20 /run/icinga2/

The safe-reload script performs the following operation based on the pidfile data:

pid=`cat "$ICINGA2_PID_FILE"`
if ! kill -HUP "$pid" >/dev/null 2>&1; then
	echo "Error: Icinga not running"
	exit 7
fi

This effectively means that the safe-reload script processes data controlled by the icinga service user. The PID file could be replaced by a symbolic link, or a named pipe, which would lead to a local denial-of-service against the reload invocation.

Furthermore an arbitrary PID can be placed in the file, which would cause safe-reload to send the SIGHUP to an arbitrary other process in the system, causing integrity violation and/or denial-of-service.

This is a defense-in-depth issue, because the isolation between the icinga service user and root is lacking. It is not directly exploitable, but becomes a problem when the icinga service user account is compromised.

To fix this the safe-reload script could be invoked with service user credentials from the very beginning, or parts of the script could use a utility like sudo, to drop to service user privileges.