Securing execution servers
This topic describes how to secure execution servers.
Execution server permissions
Currently, every installation of File-AID/EX includes the installation of execution servers. Often these execution servers are running under accounts with inappropriate permissions—either being too restrictive, which limits functionality, or too open leaving systems vulnerable.
A full installation of File-AID/EX contains a Local execution server, which runs under the account of the user ID who started it explicitly by selecting Start execution server from a menu or implicitly by launching a client application like ConverterPro.
An execution server Only installation on Windows installed by an administrative user ID, creates a Windows Service running under that user ID.
A UNIX/Linux-based execution server
By default, a Unix/Linux-based execution server runs under the account of the user ID that started it. When the execution server attempts to access local or network resources, such as files and databases, or to execute external programs or scripts, the local or network security checks access permissions for that user ID. In most cases, local execution servers are less of a security risk, as long as they are secured against remote access and different users, as explained later in this section. For remote execution servers, selection of a user account typically requires analysis and design of how it is to be used.
The recommended approach is to create a specialized domain account for each remote execution server, and to give this account appropriate access to all local and network resources that this execution server is expected to use.
Typically, one or more shared network locations are selected to contain any source or target files for ConverterPro, target directories for Related Extract, etc. These network locations are configured to be accessible to the domain accounts established for the execution servers.
A similar approach can be used for using trusted connections to databases. When trusted access is allowed for the domain user accounts associated with execution servers, the File-AID/EX specifications can use the Trusted Connection option when configuring database access rather than providing user IDs and passwords.
Launching execution servers under a domain account on Windows
When a File-AID/EX execution server is installed on Windows using the execution server Only installation option, it is automatically registered as a service running under the local system account.
To change the local system account to a domain account:
Open Windows Services, and select the BMC
File-AID/EX
execution server and its properties.
- Select the Log On tab and change the default Local System account to the domain account.
- Restart the execution server to apply the changes.
When a File-AID/EX execution server is installed as a Local execution server (which is part of the Full Installation mode), there are a few options for launching it under another user account.
The first option is to:
- Create the execution server service by launching InstallExpressAsService.cmd from the <Installation_Folder>\Dme directory (this requires administrative privileges).
- Follow the steps for the execution server Only installation. After the installation completes, a non-administrative user ID would be able to start and stop this service when needed.
The second option is to:
- Right-click on the fa_exsrvr.exe filename listed in the <Installation_Folder>\Dme directory.
- Select Run As Different User from the pop-up menu.
- Specify a user ID and password for the domain account designated to run the execution server.
The third option is to:
Launch the Local execution server from the command line or from a batch file by issuing the runas command, for example:
The password will be requested during the execution of this command.
Launching execution servers under a domain account on Linux/Unix
To launch execution server on Linux or Unix using a different user account, the su or sudo commands can be used. A typical example of such command:
Refer to Linux/UNIX documentation on adding Linux/Unix systems to a domain and on using the su and sudo commands with a domain account for particular Unix versions and type of shells.
Limiting access to execution servers
When the execution server is installed, the default configuration is to allow any user running any File-AID/EX client application to communicate with it—including submitting tasks for execution. This is primarily aimed at simplifying the initial installation and configuration process, and also make the execution server sharable with other users in a collaborative environment. It is recommended that as soon as the installation is complete, access to the execution server should be limited to only the users that need it. The list of users having access should be monitored and periodically reviewed by the administrators. Monitoring is even more important when the execution server runs under a domain account that allows access to databases and restricted network resources.
To configure which users are allowed to send requests to the execution server on a system with full installation of File-AID/EX.
- Open the Homebase application and select the Tools/execution server Security menu item.
- Specify the port number for the execution server (default is 4900). The execution server Security Settings dialog box appears.
- Press the Remove All button to remove the default ALL_USER entry from the list, and then use the Allow… button to add individual user IDs that should be allowed to submit requests to the execution server.
On systems with an execution server Only installation, locate the engineUser_<port_number>.properties file in the C:\<ProgramData>\BMC\FAEX\Security on Windows or <InstallDir>/security on UNIX/Linux directory and populate it with the user IDs allowed to access the execution server. Place one user ID per line, using the format <DomainName>\<NetworkID> format for domain accounts.
Limiting access to execution server configuration files
When the execution server is configured to be used under a specific domain user account, access to the configuration directories, such as c:\<ProgramData>\BMC\FAEX\Security and c:\<ProgramData>\BMC\FAEX\Cfg on Windows and <InstallDir>/security and <InstallDir>/cfg on UNIX/Linux should be secured, to prevent unauthorized users from accessing and possibly modifying the configuration files.
Typically, for the execution server Only installation, this access should be limited only to the user ID that the execution server runs under and any administrative user IDs that are going to perform system upgrades. For complete installations, such access should be allowed for user IDs launching File-AID/EX client applications. In cases when the local execution server is running under a special domain account using impersonation (as described previously), then access to the configuration directories needs to include that user ID as well.
Limiting access to execution of system commands
File-AID/EX ConverterPro application supports creation of specifications with expressions that can launch system commands during execution. While this is a powerful feature, which is sometimes utilized for copying files and performing other tasks that use the operating system facilities to prepare or transform data, a malicious user can take advantage of this capability by – for example - bringing harmful files to the environment or formatting the hard drive.
The default configuration of File-AID/EX has this capability disabled to prevent its malicious use. When a user needs to make it available, the execution server(s), which are supposed to execute specifications that require this capability, need to be configured to allow it.
To allow execution of system command, open the engine.properties file (located in the <ProgramData>\BMC\FAEX\Cfg directory on Windows) or <InstallDir>/cfg on UNIX/Linux). If this file has the AllowSystemCommands setting, set its value to true (or false, to suppress execution of system commands). If this setting is not present, add a new line with this setting, such as,
After modifying this file, save it and restart the execution server to apply the changes.