Implementing PS_CFG_HOME Security

The steps in this section describe techniques for applying more stringent access to a PeopleTools environment by restricting access to PS_CFG_HOME. If you intend to secure PS_CFG_HOME, it is assumed that you have also secured PS_HOME. Securing PS_CFG_HOME enables you to prevent malicious access to content and configuration files located in PS_CFG_HOME and in domain directories.

These steps describe a security implementation where you configure a user account(s) that can create and configure domains, and user account(s) for domain administrators, who can start and stop domains.

It is possible to limit the permissions to PS_CFG_HOME, such that the domain administrator account can:

  • Create files and sub-directories in PS_SERVDIR.

    This is necessary for creating log files and temporary files. Tuxedo also requires read-write access to the domain directory.

  • Read (but not change or delete) any existing configuration or template files in PS_SERVDIR.

    These files include .cfg, .ubb, .ubx, .val files, and so on.

Note: To apply these permissions, you must do so after the domain has been configured but before it has been started.

Note: Once these permissions have been implemented, only a user account with the appropriate privileges can reconfigure the domain.

You have these approaches when implementing a secure PS_CFG_HOME on UNIX:

Security Approach

Description

Use a root account, or use super user do (sudo), instead, to perform root-level operations with a non-root account:

This technique involves locking a user account’s access to a file from the root account.

Use two administrator user accounts:

The two administrator accounts approach involves using two user accounts that are members of the same group.

This approach permits all users in the account in the group read access to the domain configuration.

This approach works best if the number of users in the group is kept to a minimum.

Because there are multiple users involved, it is necessary to override the default PS_CFG_HOME environment variable such that both users will see the same domains.

To set up a secure PS_CFG_HOME using sudo:

  1. Create and configure the domain.

    For this procedure, assume the user who does this is DomainAdmin.

  2. Use sudo to restrict write access to the sensitive configuration files.

    For example, with the sudo command include:

    chmod 555 <filename>

    In this case, only sudo can change the configuration files or restore write access to DomainAdmin.

  3. Log in as DomainAdmin, and verify that none of the restricted files can be changed or deleted by the DomainAdmin session.

  4. Start the domain as DomainAdmin.

To set up a secure PS_CFG_HOME using two administrator accounts:

  1. Create and configure a domain.

    For this procedure, assume the user who does this is DomainAdmin.

  2. As the DomainAdmin user, change the permissions on the domain configuration to allow write access to only those files and directories needing to be written to by the user starting the domain.

  3. Signon as the DomainBootAdmin user, start PSADMIN, navigate to the Domain Administration menu, and re-configure the domain without making any changes.

    This results in only the TUXCONFIG file being updated.

  4. Star the domain as the DomainBootAdmin user.

To secure PS_CFG_HOME on Windows:

  1. Ensure that your PS_CFG_HOME is created in a location that is accessible to the user account that needs to start the domain.

    By default, the PS_CFG_HOME location will not be visible to the user account starting the domain because it is created in the user home of the user account creating the domain. Use one of these options to make the PS_CFG_HOME visible to the user account that needs to start the domain:

    • Override the default location for PS_CFG_HOME, by manually setting the PS_CFG_HOME environment variable to a custom value.

    • Enable the restricted user to view the PS_CFG_HOME in the domain creator’s user home. Set the PS_CFG_HOME as a system-level environment variable so that the restricted user will be able to see it when logged on.

  2. While signed in as the domain administrator, create and configure your new application server or Process Scheduler server domain.

  3. While signed on as the domain administrator, apply the necessary read-write restrictions.

    It is recommended to apply read-only privileges to the entire directory path to the domain.

    1. Using Windows Explorer select the domain directory and open the Properties dialog.

    2. Select the Security tab. If the restricted user is not displayed, click Add to append the user to the list.

    3. Once added, highlight the restricted user ID and ensure that the following actions are checked in the Allow column: Read & Execute, List Folder Contents, Read, and Write.

  4. Apply read-only privileges to the sensitive domain files that should be protected from read-write at runtime.

    This typically includes the Tuxedo binary configuration (PSTUXCFG and PSBDMCFG), ASCII configuration files and templates (*.cfg, *.ubb, *.env, *.ubx, *.lst).

    Using Windows Explorer, select each of these files in the domain directory and open the Properties dialog.

    Note: At a minimum, it must be possible for the user starting the domain to write to the .adm and LOGS directory within PS_SERVDIR. Additionally, this user must be permitted to create new files in the domain directory.

  5. Sign in as the restricted user, boot the domain, and verify that it is not possible to delete or modify any of the restricted domain files.

    Note: Sign in using the same user account as the one entered in the Oracle ProcMGR service.

    Note: If subsequent configuration changes are required it is necessary to configure the domain while signed in as the administrator account that created and configured the domain.