Choosing a User Switching Security Mode
On UNIX platforms, it is common to have a separate user for an application. When you need to interact with these applications, commands often have the requirement that they need to be executed as a specific user.
There are several ways to switch users on UNIX systems, and the scheduler supports these. Choosing one is important, as it decides what functionality is available to the process definitions. It is also related to any potential security restrictions that may be in place in your installation.
note
In all scenarios we assume that the software is installed as user 'redwood'.
The installation script of the platform agent requires you to choose a security option from the following:
- Plain: Running processes only as a normal user.
- Root: Running processes as any user, the network agent running as root.
- Setuid: Running processes as any user, the network agent running as an unprivileged user, using setuid.
- Sudo: Running processes as any user, the network agent running as an unprivileged user, using sudo.
In the case that all your processes can run as the same UNIX account you can use the plain security mode. This has the least security implications as there is no user switching, and no elevated privileges are required.
If you want the scheduler to be able to run processes using a variety of user accounts you can choose between the root, setuid and sudo options. The root and setuid options work on all UNIX systems, and do not require additional software. The setuid method does require that the job-processor binary is installed with elevated privileges. For the setuid and root options the list of allowed users is configured in scheduler configuration files only. The sudo option allows the use of sudo to run processes under different users, and to perform other tasks that require elevated privileges. For the sudo option the configuration of the sudo command itself also plays a role in the decision as to what is allowed.
Redwood recommends that the setuid scenario is used as it does not require the installation of additional software (if sudo is not yet installed) and is less complicated.
The installation script will ask for the scenario you have chosen. It will store the requested user switching mode in a configuration file. The network-processor will then use the scenario defined there. To change this configuration setting afterwards, see Configuring Platform Agents.
The following sections describe the different scenarios in detail,
Plain: Running processes only as a normal user.
In this scenario, no user switching is done. All processes will run using the same UNIX account. Processes that specify that they need to run under a particular user account will fail (if this is not the same account).
No special action needs to be performed to prepare this scenario.
The startup script will switch to the user specified at installation time and run the network-processor under that account. All job-processor processes run using the same account.
Root: Running processes as any user, the platform agent running as root
In this scenario, user switching is done. You can run processes as any user. You can limit the UNIX accounts the processes run under by creating a blacklist or whitelist file in the agent configuration files.
The startup script will switch to the root user and run the network-processor under that account.
The advantage of this scenario is that it is fast (no overhead is spent changing file ownership) and has a low chance of having configuration problems where files or output cannot be read since the network-processor can access all files as root.
The disadvantage of this scenario is that the network-processor continuously runs as root, forming a larger attack target than the other scenarios.
Setuid: Running processes as any user, the platform agent running as an unprivileged user, using setuid
In this scenario, user switching is done. You can run processes as any user. UNIX level user switching is done using the setuid bit on the job-processor. Changing file ownership is also done using the setuid bit.
This scenario is relatively easy to set up, as it does not require the possible installation of sudo, and executes quickly. You can limit the UNIX accounts the processes run under by creating a blacklist or whitelist in the agent configuration files.
The startup script will switch to the non-root user specified at installation time (for example, redwood ) and run the network-processor under that account. When a process runs, the job-processor will change the ownership of the files to the correct account, run the process and then change the file ownership back to the scheduler user.
Sudo: Running processes as any user, the platform agent running as an unprivileged user, using sudo
In this scenario, user switching is done. You can run processes as any user. UNIX level user switching and changing file ownership is done using the sudo command.
This requires that you have sudo installed and configured.
This scenario allows you to limit the control of switch user accounts to the sudo control files (usually /etc/sudoers). The only thing that runs as root is the chown command for files that are under the control of the scheduler.
- The startup script will switch to the non-root user specified at installation time (for example,
redwood) and run thenetwork-processorunder that account. - When a process runs, first
sudo -S -u root chownwill be called to change the ownership of the files to the correct account. - The process is run via
sudo -S -u <user> job-processor. - When the job-processor has finished a final
sudo -S -u root chownwill change the ownership of the files back to the user running the network-processor.
This scenario does take a little more effort to configure, as you may have to install sudo or a comparable security system, and configure that security system so the platform agent can do what it needs to do. It can also be a little harder to analyze when problems occur and processes cannot be run under a particular account, as this can be caused by several configuration issues.
The installer script will configure /etc/sudoers (or prepare for it when not run as root). If you use a different solution than sudo, run the installer as follows:
$ VISUDO=your-visudo-equivalent $SHELL ./<installer>.bin
If your security solution does not provide a visudo compatible program, just substitute vi.
After the installation finishes, remove the sudo commands in the root.sh file and configure your solution manually. You may also need to override the SwitchUserCommand parameter on the process server.
note
The SwitchUserCommand process server parameter can be used to change the command used from sudo to something else, or to set a path to the sudo executable. Note that it is only used for sudo User Switch Mode and has no effect if you set it when a different mode is used.
Security Considerations
When you use sudo user-switching mode, a user who gained access to the Redwood Server user could access files owned by root because redwood needs to be granted the permission to change any file to any user. To avoid this, you can specify your own sudo command. Redwood Server ships with an example sudo.sh shell script which improves the security by sanity-checking the parameters. You may edit this file to match your security requirements. See Configuring Platform Agents for more information.