Managing world writable permissions of files and directories in TrueSight Server Automation


Ensuring the proper permissions of files and directories is a critical aspect of maintaining the security and integrity of any system. when files and directories are created and accessed by various components and users, managing world writable permissions becomes crucial.

Starting 23.4, umask is enforced in all the service startup scripts and a new RSCD agent installer option is introduced to better manage the world writable permissions of files and directories in TrueSight Server Automation.

Umask enforcement in service startup scripts

To ensure consistent and controlled permissions for the artifacts created by TrueSight Server Automation, the umask value of 0022 is enforced in all the service startup scripts. This approach addresses the issue of unintended permissions that may arise due to a misconfigured umask on the system.

Enhancing Security with the rootonly option in the RSCD agent

The RSCD Agent installer now includes a new option called rootonly. TrueSight Server Automation administrators are advised to carefully analyze the user mappings of the RSCD Agent within their environment and enable this option selectively, limiting it to situations where mapping all role:user pairs to the root user account is intended. Enabling this option on servers ensures that common directories are protected from being writable by all users, while also preventing the SUID (Set User ID) bit from being set on certain executables.

Important

When you enable the rootonly option, it does not impose the root mapping; instead, all mappings continue to be influenced by the exports/users/users.local configuration file. What it does is inform the installer and the RSCD Agent that TSSA Admin will exclusively map all role:user pairs to the root user. This decision is made for two important reasons:

  • Preventing the creation of common directories with world writable permissions.
  • Avoiding the setting of the SUID bit on select executables.

Default Permissions and SUID Bit: Understanding the Need for Change

  • In TrueSight Server Automation, files and directories are created within the RSCD agent installation directory to store various types of information, such as locks for shared memory communication, temporary data for jobs, logging, and rollback data. These directories are shared among different local user accounts.
    When TrueSight Server Automation role:user is mapped to a different local user account, to ensure that these mapped users can write data to the shared directories, these directories are configured to be world writable and have the sticky bit set on them. For more information about these directories, see Why do certain RSCD Agent directories have world-writable (777) permissions?.

    However, if all the TrueSight Server Automation role:user are mapped only to the root user account, there is no need to configure the shared directories as world writable or set the sticky bit on them.
  • To facilitate efficient gathering of system information by mapped non-root users, specific TrueSight Server Automation executables are configured with the SUID (Set User ID) bit.

    However, if all the TrueSight Server Automation role:user that are responsible for gathering this system information are mapped only to the root user account, the SUID bit is not necessary on these executables.

Effect of enabling the rootonly option

Enabling this option will have several effects.

  • World writable permissions on IPC, log, snapshot, tmp and Transactions directories will be removed, enhancing the security of the system.
  • SUID (Set User ID) bit on the nativetool/bin/.mcsiwrapper and ./bin/lsof executables will be removed, ensuring that they do not inherit elevated privileges when executed. This helps maintain the principle of least privilege and reduces the risk of misuse.
  • tx_config.cfg file will be configured with a specific umask value. This umask value controls the default permissions assigned to newly created files within the Transactions directory. By setting the umask appropriately, the system ensures that world writable files are not inadvertently created, preventing potential security vulnerabilities.
  • If the Application Server finds rootonly configuration enabled on the Repeater server, the permissions of the specified <repeater_staging_directory> will be modified from the default value of 1777 to 770.

    Note

    The check for rootonly configuration involves examining the presence of the /etc/rsc/rootonly file, which should have the root user as the owner and 600 permissions.

How to enable the rootonly option?

The rootonly option can be enabled in various ways, providing flexibility based on your preferred installation or upgrade method.

You can choose any of the following mechanisms to enable the rootonly option:

  • Interactive shell installation

    During the interactive installation process, specifically when installing only the RSCD agent on the host computer, you will encounter a prompt asking whether you want to enable the rootonly option.
    The following message is displayed:

    Do you want to enablerootonlyconfiguration? (y/n) ?

    For more information on interactive installation, see Installing only the RSCD agent (Linux and UNIX).

  • Silent installation

    For automated installations or upgrades of the RSCD agent in silent mode, you have the option to set the ROOTONLY variable in the nsh-install-defaults file located in the /tmp directory. The following code sample provides an example:

    ROOTONLY=1
    export ROOTONLY

    For more information on silent installation, see Using silent mode to install TrueSight Server Automation components (Linux or UNIX).

  • Pre-upgrade

    If you are upgrading an existing installation, you can enable the rootonly option before starting the upgrade process using the following code:

    touch /etc/rsc/rootonly
    chown root /etc/rsc/rootonly
    chmod 600 /etc/rsc/rootonly

    Please note that the rootonly configuration will take effect only after the RSCD agent is upgraded.

  • Post upgrade

    Alternatively, you can enable the rootonly option after completing the upgrade process using the following code:

    touch /etc/rsc/rootonly
    chown root /etc/rsc/rootonly
    chmod 600 /etc/rsc/rootonly

    After enabling the rootonly option, it is necessary to restart the RSCD Agent service for the changes to take effect.

By offering multiple mechanisms to enable the rootonly option, you can choose the most suitable method based on your installation or upgrade scenario. Whether it's an interactive installation, silent installation, pre-upgrade, or post-upgrade, you have the flexibility to enable the rootonly option seamlessly.

How to disable the rootonly configuration?

To disable the rootonly configuration, you can follow these steps:

  1. Remove the /etc/rsc/rootonly file.
  2. Restart the RSCD agent service for the changes to take effect.

Upon starting the RSCD Agent service after removing the /etc/rsc/rootonly file, permissions of various directories and files will be restored to their default values.


 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*