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?
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:
Start the agent directly under the user root.
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.
; 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.
; 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
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_STARTThis 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