Verify Agent setup

[Brett Jenkins]

I have inherited an Automic environment that I believe is not set up corrrectly:

The client servers are Oracle Linux/RedHat linux. On each server there is an application running as a defined user, ie, wm, siadmin, ifwadmin, etc.

The current setup, all automic related files are under /opt/automic. The userid for that server's application owns all directories and files under /opt/automic. For some reason, the automic ServiceManager and Agent is being started by a configuration manager product called CFEngine. I was told that was the only way they could get this setup to work because the effective ID was always root while the real ID was the application ID, or vice-versa. So, they configured CFEngine to fork a shell under the application ID and then fork another shell to start the ServiceManager and Agent.

I have been advised to change all ownership to root:root, run the processes as root, and make sure any user running jobs has r/w/x to the Agent's temp directory. This obviously will work as root can do whatever it wants, but is that setup exploitable? Is there any way a user can execute a script to do nefarious things, or run a job that does something like reboot the server, delete OS files, change root password etc?

[Spencer Cockrell]

Hi Brett, 

Hopefully I can help answer some of this, though perhaps not as in-depth as you need. The Agent running as root should be, generally, the requested/recommended configuration from Automic/Broadcom:

https://docs.automic.com/documentation/webhelp/english/AA/12.3/DOCU/12.3/Automic%20Automation%20Guides/help.htm#Installation_Manual/InstallAgents/InstallAgentUNIX.htm?Highlight=unix%20agent

The agent for UNIX operating systems can be installed to either run as a privileged or an unprivileged process. It is recommended to install it as a privileged process because only in this mode, the agent can operate with full capabilities.

There are two methods to start the agent with root privileges:

1. Start the agent directly under the user root.

2. Define root as owner, assign the group where the start user has to be a member of, set the execute bit for the group and set the SetUID (s-bit) for the agent file owner.

   Example

   • chown root ucxjlx6
   • chgrp admin ucxjlx6
   • chmod 4550

--

This shouldn't allow the jobs themselves to run as root, however, unless you specify the root user/pw in a login object - the user in the Login Object is the user that should be executing the commands on the server the Agent resides on (generally one with much less permission/access than root).

In other words, as long as your user permissions are secure I don't think this should be a problem. They'll have whatever access they normally have when logging in with that user via login object/job in Automic.

------------------------------
[Sr. Systems Engineer]
[BECU]
------------------------------

[Dejan Hrubenja]

​Agree.
Agent has to run as root, in order to be able to substitute user (su on UNIX) using credentials from the LOGIN object.
For this reason, you have to check the configuration of agent(s) on UNIX/Windows and Client (Automic):

WINDOWS - INI file:
; logon: The settings for the execution of jobs / file transfers.
; See: Description of the settings ANONYMOUS_FT and ANONYMOUS_JOB in the variable UC_HOSTCHAR_DEFAULT.
; 0 - Jobs and/or file transfers and/or FileSystem Events start under the agent's OS user. The login data that is available in the Login object is not checked.
; 1 - The login data that is stored in the Login object is used.
;
logon=1 
UNIX - INI file:

; login_Check: Password check.
; Note that the agent must have root rights as otherwise, login_check=yes does not work. Use login_check=no and ANONYMOUS_JOB=yes in this case. See also UC_HOSTCHAR_DEFAULT.
; yes - login credentials are checked
; no - login credentials are not checked
;
login_Check=yes

UC_HOSTCHAR_DEFAULT is in Client 0 in HOST_VARIABLES

[Tim Quakulinsky]

Hi Brett,

there is also another hurdle before jobs can be executed as root users. The [USERID] section in the INI file of the agent specifies which Unix users may or may not start jobs. The following should be the default (I did not check it with a current version):

[USERID]
root=NO_START

This means that the agent must not execute anything via root.

As a result, a malicious user must have write access to the agent's INI file and restart the agent in addition to the ability to create or change a login object.

Best regards,
Tim

------------------------------
Automation Evangelist
Fiducia & GAD IT AG
---
Mitglied des deutschsprachigen Automic-Anwendervereins FOKUS e.V.
Member of the German speaking Automic user association FOKUS e.V.
------------------------------