Hardening filesystem permissions

As a system for running production applications, Enterprise Server will inevitably have access to some sensitive data. However, it is still worthwhile limiting the ability of Enterprise Server components and applications running in an enterprise server region to read and write data and system files which are not required for proper operation, and to prevent executing inappropriate programs. This can be achieved with careful use of filesystem permissions.

Comprehensively configuring filesystem permissions for security is difficult because filesystems are large and complex. Also, the operating systems under which Enterprise Server runs administer filesystem permissions by individual file and/or hierarchically, so determining which permissions to set where, and ensuring they are set consistently, might require considerable effort. Setting proper permissions for even some portions of the filesystem will reduce the attack surface and potential for exploitation.

Micro Focus recommends the following approach to hardening filesystem permissions:

Run Enterprise Server programs under user accounts created specifically for that purpose. It is sometimes useful to have multiple user accounts so that privileges can be assigned differently for various components. For example, the Enterprise Server Common Web Administration (ESCWA) and MFDS components require additional access which is not appropriate for the processes running under an enterprise server region, so you may wish to create one user account for ESCWA and MFDS and another for regions.
This is somewhat more difficult on UNIX when POSIX (traditional UNIX) file permissions are used, as those only allow three sets of permissions: one for the owner, one for the group, and one for all other users. Also, on UNIX, MFDS normally is started as root, and shortly after startup it will change its effective account to the Enterprise Server system user account. For these reasons, it is common on UNIX to have a single system user account which is used by all Enterprise Server processes.
Determine which programs and data files Enterprise Server components require access to, and what level of access is required. For example, the MFDS repository files must be writable by MFDS, but can be read-only for enterprise server region.
Where possible, group program files used by regions in a single directory tree, and data files used by regions in another directory tree, to make setting and checking permissions simpler.
Grant the appropriate access to the filesystem objects identified in the previous steps to the user accounts created for use by Enterprise Server. See the topics listed below for more information.
Deny access to other filesystem objects to the Enterprise Server user accounts.

Some specific items to attend to:

The MFDS repository-export function takes a path specified by the user. It is important that MFDS has write access to only a limited set of directories to prevent the abuse of this feature.
Region processes must not have read access to sensitive system files. They also must not have write access to Enterprise Server configuration files. They do generally need write access to the region "system directory" (where the log files reside). For certain features, they might need write access to some other files. For example, the optional auto-registration mechanism of a CICS Web Interface needs to be able to write to files in the configured certificate-information directory.
In some cases, the primary security task is not to restrict Enterprise Server access to a file, but to restrict other accounts' access to it. For example, the key files used with TLS should only be readable by Enterprise Server and administrators. See Using and hardening TLS for more information. Typically, data files used by applications running under Enterprise Server should not be readable or writable by programs running under other user accounts.

Additional administrator user accounts

As noted above, there will generally be one or more Enterprise Server system user accounts which ESCWA, MFDS, and enterprise server region processes run under. When administrators use ESCWA to perform administrative tasks, those will also be performed under the system user account, so only that account needs additional, privileged access to Enterprise Server filesystem objects.

In some organizations, however, some administrators or automated processes may perform administrative actions under different accounts, for example by running command-line utilities such as casstop or esfadmin. Those accounts will need additional access, typically the same access granted to the ssytem account, as described in Filesystem permissions: Windows or Filesystem permissions: UNIX.

WINDOWS To achieve this:

Create an Enterprise Server administrators user group in Windows.
Add the system user account(s) and all other administrative accounts to it.
Use it, rather than the system account, when granting additional write access as described in Filesystem permissions: Windows.

UNIX POSIX file permissions limit the granularity of filesystem access. Here are some possible approaches to assigning filesystem permissions when there are multiple Enterprise Server administrative user accounts:

Have all administrators switch to the system account when performing Enterprise Server administration tasks, using a tool such as su.
Use Access Control Lists in addition to POSIX file permissions, to grant the additional access to a group which all administrators belong to. All the UNIX platforms currently supported by Enterprise Server support ACLs for the most commonly used filesystems, though the details vary among operating systems. Consult your OS documentatio nfor more information.
Create an Enterprise Server administrators group. Set the group ownership of files and directories to this group, rather than to an Enterprise Server users group as described in Filesystem permissions: UNIX. Follow the instructions in that topic but grant the elevated permissions to the group as well as the owner, and grant read-only access to "others" (all users) rather than to the group.