Root Lockdown Mode (RLM) is a security feature designed to disable and block access to the cluster’s root account. This new RLM functionality in OneFS 9.12 enforces role-based access controls (RBAC) for cluster administrators, thereby reducing the risk of a single privileged user bypassing security policies and performing potentially destructive operations on the cluster configuration or its data. Given that the root account has inherent, unaudited permissions to override security controls, restricting its access significantly strengthens the PowerScale’s security posture.
The basic process for enabling RLM is as follows:
Note that, in OneFS 9.12, RLM does not have a WebUI interface, and so is only configurable via the command line (CLI).
Several privileges are required to successfully deploy RLM. These include:
| Privilege | Description |
| ISI_PRIV_AUTH | for account configuration |
| ISI_PRIV_LICENSE | for license activation |
| ISI_PRIV_HARDENING | for applying and disabling RLM |
| ISI_PRIV_SYS_SHUTDOWN | for rebooting nodes or the cluster |
| ISI_PRIV_DEVICES | for adding new nodes to the cluster |
- The specific steps to activate RLM on a cluster are as follows:
- Once the cluster is running and committed to OneFS 9.12, create a dedicated user account to use in place of root (i.e. ‘RLM’, in the following example):
# isi auth users create RLM --enabled true --set-password passwowrd: xxxxxxxx confirm: xxxxxxxx
- Next, assign this new user (‘RLM’) the necessary RBAC roles, which include ‘SystemAdmin’ and ‘SecurityAdmin’.
# isi auth roles modify SystemAdmin --add-user RLM # isi auth roles modify SecurityAdmin --add-user RLM
- Configure the new user and ‘compadmin’ account with a valid shell, such as ZSH:
# isi auth users modify compadmin --shell /usr/local/bin/zsh # isi auth users modify RLM --shell /usr/local/bin/zsh
- The required licenses for OneFS Hardening must be activated. For example:
# isi license add --evaluation HARDENING
- Once the above prerequisites are met, the root-lockdown hardening profile can be applied via the OneFS Hardening Engine.
# isi hardening apply root-lockdown .Hardening operation complete.
- A full cluster reboot is then required to enforce the new configuration.
# isi cluster reboot -–lnn=all This command will reboot the cluster. Are you sure? (yes/[no]?): yes
- Once rebooted, the status of RLM can be verified as follows:
# isi_for_array isi auth cache flush --all # isi hardening list -az | grep -i lockdown root-lockdown Enable security settings that disable the root account. Applied # isi_for_array -s isi auth users view root | grep Enabled tme-1: Enabled: No tme-2: Enabled: No tme-3: Enabled: No
Additionally, the hardening report associated with the root-lockdown profile will provide a more detailed status. For example:
# isi hardening reports create # isi hardening reports view root-lockdown Name Location Status Setting -------------------------------------------------------------------------------- require_password_single_user_mode Node 1 Applied /etc/ttys check_disable_root_account Node 1 Applied /auth/users/root:enabled check_root_shell_nologin Node 1 Applied /auth/users/root:shell check_rlm_sysctls Node 1 Applied - require_password_single_user_mode Node 2 Applied /etc/ttys check_disable_root_account Node 2 Applied /auth/users/root:enabled check_root_shell_nologin Node 2 Applied /auth/users/root:shell check_rlm_sysctls Node 2 Applied - require_password_single_user_mode Node 3 Applied /etc/ttys check_disable_root_account Node 3 Applied /auth/users/root:enabled check_root_shell_nologin Node 3 Applied /auth/users/root:shell check_rlm_sysctls Node 3 Applied - set_rlm_cluster_wide Cluster Applied root-lockdown require_disabled_STIG_profile Cluster Applied – require_rlm_aclr_users Cluster Applied – require_rlm_cluster_state Cluster Applied – disable_kdb Cluster Applied /etc/mcp/templates/sysctl.conf disable_root_account Cluster Applied /auth/users/root:enabled root_shell_nologin Cluster Applied /auth/users/root:shell
In addition to RLM, the OneFS 9.12 release also introduced Multi-party Authorization, or MPA, functionality. MPA is an administrative approval mechanism that requires at least one additional trusted party to sign off on a requested change, for certain privileged actions within a PowerScale cluster. As such, MPA helps to reduce the likelihood of data loss or system configuration damage from critical actions, by mitigating the risk of accidental or malicious execution of consequential operations.
A recommended practice is to configure and enable RLM in combination with, and complimentary to, the MPA feature. This will mean that any requested change to the RLM state will require additional approval. The application or removal of RLM necessitates a full cluster reboot to ensure that all relevant system controls (sysctls) are properly enforced or cleared. Administrators should consult the hardening report to determine which nodes require rebooting during this process.