Restricting pgdba user Linux shell login privileges cause controldb service startup to fail

Products

VMware Smart Assurance

Issue/Introduction

Restricting the Linux shell login privileges of the NCM installer created pgdba user on the Linux host causes any attempt to start the NCM controldb service to fail.

Environment

NCM 10.X

Cause

The SCAP Security Guide for Red Hat Enterprise Linux (RHEL) as well as other industry recognized security standards recommend not allowing the PostgreSQL pgdba user that typically owns the database to have default Linux shell login privileges. The default shell access privileges created for the pgdba user by the NCM installer is as follows (Where {UID} and {GID} are the arbitrary user and group IDs assigned to the pgdba user by the NCM installer at time of install, and {NCM Home Path} is the path where NCM was installed - defaults to /opt/smarts-ncm/ ):

pgdba:x:{UID}:{GID}:PostgreSQL Database Admin:{NCM Home Path}/db/controldb:/bin/bash

This assignment of login privileges under the /bin/bash/ default shell to the pgdba user does not meet SCAP security recommendations. Because of this, Linux host administrators may try to change the default shell access privileges for the pgdba user to one of the following:

/sbin/nologin
/bin/false
/bin/true

The /sbin/nologin option is the preferred approach. It is associated with the util-linux project and should be available under any implementation of RHEL. It allows a custom message to be presented to users attempting to log in to a Linux shell when they do not have privileges to do so. The custom message is set in the /etc/nologin.txt file. The /bin/false and /bin/true options are a much older approach associated with the GNU project that provide no end user feedback and simply terminate the login attempt with an exit code of 1 (/bin/false indicating a non-zero, or error condition exit return value) or 0 (/bin/true indicating a zero, or normal condition exit return value to give even less information about why the shell login attempt was closed) because all they do is return the specified value and are not actually valid shells.

Unlike other NCM installer created users such as the tomcat, tomcatmsa, and transformer users that are designated to own other NCM services and are created on the Linux host by the NCM installer with the /sbin/nologin restriction already in place, the NCM controldb service start script relies on the default /bin/bash default shell access permission that was assigned to the pgdba user by the NCM installer. Because of this, if the shell access privileges for the pgdba user are suspended as described above, the NCM PostgreSQL Control Database (controldb) service can no longer be started.

Resolution

To successfully restrict the pgdba user Linux shell access privileges by setting the default shell assigned to the pgdba user in the /etc/passwd file to /sbin/nologin, do as follows:

1.  Declare an appropriate maintenance window for NCM in which service, as well as the controldb host OS can both be restarted, then complete the below steps during that maintenance window.
2.  Log into Linux shell session on the NCM Report Advisor (RA) host as well as the NCM Application Server host 'root'.
3.  Run the following command to set NCM related shell session variables in the Linux shell session on the RA and AS hosts:

    source /etc/voyence.conf

4. Stop the tomcat service on the RA host by running the following command to keep the RA from maintaining a live connection to the controldb during this process that could potentially prevent any controldb related changes from taking effect:

    service tomcat stop

5. Stop all NCM services on the AS host by running the following command to keep the AS from maintaining a live connection to the controldb during this process that could potentially prevent any controldb related changes from taking effect:

    service vcmaster stop

6. If the controldb is located on a dedicated database (DB) host, log into the DB host under a Linux shell as 'root', then set NCM related shell session variables and stop the controldb service by running the following commands:

    source /etc/voyence.conf
    service controldb stop

7. Run the following sequence of commands in the Linux shell on the host where the controldb resides (AS, DB, or Combination Server) to back up appropriate files, update the pgdba user shell permissions, and update the NCM controldb initialization script to allow correct controldb operation under a pdgba user with restricted shell privileges (you may need to move the /tmp/_[etc-init.d-]controldb.bak file backup of the /etc/init.d/controldb file and the /tmp/_[etc-]passwd.back file backup of the /etc/passwd file created by these commands to another location after this step to keep the backup secure if your organization clears the contents of the /tmp path on a regular basis):

    cp -p /etc/init.d/controldb /tmp/_[etc-init.d-]controldb.bak
    sed -i 's/su - pgdba -c/su - pgdba -s \/bin\/bash -c/g' /etc/init.d/controldb
    cp -p /etc/passwd /tmp/_[etc-]passwd.bak
    usermod -s /sbin/nologin pgdba
    reboot

8. After the host where the controldb resides has been successfully rebooted, log into a Linux shell on the DB host again as 'root'.
Run the following commands to determine the state of NCM controldb service:

Dedicated DB host:

    source /etc/voyence.conf
    service controldb status

Combined AS+DB or CS+DB host:

    source /etc/voyence.conf
    service vcmaster status

9. If any NCM services on the host where the controldb resides are not running, start them using the following command:

Dedicated DB host:

    service controldb start

Combined AS+DB or CS+DB host (It is normal for service stop on some services to show as [FAILED] if they were not previously running but all service starts should show as [ OK ] ):

    service vcmaster restart

Additional Information

After completing these steps, any attempt to open a manual database shell from a command line on the Application Server host will require you to explicitly specify the shell you intend to use. This can be accomplished via the '-s' option to the Linux 'su' command. For example:

su - pgdba -s /bin/bash -c 'psql voyencedb voyence'

Also, if any services fail to start after making the changes listed in the above steps, there may be an irregular configuration of the Linux host, possibly due to external management of users and permissions on the host by a third party system. If so, it will be necessary to revert all of the above changes, then contact the Linux host management team to have them review and replicate this process in their host administration systems. To revert back to the previous condition, substitute new Step 7 below in place of Step 7 above, then repeat the process described above.

7. Verify that the /tmp/_[etc-init.d-]controldb.bak file backup of the default /etc/init.d/controldb service initialization script file resides in the /tmp path, placing a copy there if needed, then run the following sequence of commands in the Linux shell on the host where the controldb resides (AS, DB, or Combination Server) to restore default content to the /etc/init.d/controldb file and to restore default Linux default shell login privileges to the pgdba user.

    cat /tmp/_[etc-init.d-]controldb.bak > /etc/init.d/controldb
    usermod -s /bin/bash pgdba
    reboot