File and Object Storage

 View Only

Benefits and implementation of IBM Spectrum Scale™ sudo wrapper

By Nils Haustein posted Thu December 17, 2020 10:16 AM

  

Thanks to Felipe Knop and team for the valuable input.

Updated on July 26, 2022

In this blog article I want to share my experience configuring IBM Spectrum Scale™ with sudo wrapper. I start with a short introduction of sudo and explain the objective of sudo wrapper in the context of a IBM Spectrum Scale cluster. Afterwards I disclose an approach to implement the four-eye principle, which relies on two distinct users controlling each other for secure administration. At the end I demonstrate how to configure and use sudo wrapper in a IBM Spectrum Scale cluster. I assume that you are familiar with the administration of an IBM Spectrum Scale cluster.

 In IBM Spectrum Scale version 5.1 a major security improvement has been implemented regarding sudo wrapper. It is no longer required to allow remote copy commands and the echo-command in the sudo-configuration. These changes have been adopted in this blog article (see section Configure sudo wrapper).

                                                     

What is sudo

Sudo is a program that allows computer users to run programs with the security privileges of another user, by default the superuser (commonly the root user). The name “sudo” originally stood for "superuser do", but sudo is no longer limited to running commands with the privileges of root. It can also run commands with privileges of other (restricted) users.

 The commands a user can run with the security privileges of another user are configured in the sudo configuration file /etc/sudoers (also called sudoer-file). It is recommended to use the command visudo to edit this file because it does a syntax check after saving and closing it. The sudoer-file allows to configure privileges for running commands, including enabling commands only from the invoking terminal; requiring a password per user or group; requiring re-entry of a password every time or never requiring a password at all for a particular command line. It can also be configured to permit passing arguments or multiple commands.

 A simple explanation of the syntax to configure privileges of a user is shown in the following clause:

%user host=(as-user) PASSWD: passwd-cmds NOPASSWD: nopasswd-cmds

Here is a brief explanation of this clause:

  • The user is the name of the user or group configured in the operating system for these privileges.
  • The host is the host name this clause applies for. When the host name is set to ALL, then the clause applies to all hosts.
  • The as-user names another user whose privileges are used by the user to run commands. This means the user named at the beginning of the line can execute commands as another user. When this is set to ALL the user can run commands for all other users configured in the operating system of the server.
  • The token PASSWD indicates that the following commands (passwd-cmds) can be executed by the user (as the other user) whereby the user must enter the password. The commands (passwd-cmds) is a comma separated list of the commands the user is allowed to execute with password. The commands shall include the path and file name (e.g. /usr/bin/visudo).
  • The token NOPASSWD indicates that the following commands (nopasswd-cmds) can be executed by the user whereby the user does NOT need to enter the password. Likewise, the nopasswd-cmds is a comma separated list of the commands the user is allowed to execute without password. The commands shall include the path and file name.

 

In the following example the user admin is allowed to run the all mm-commands with password and the command mmremote without password.

%admin ALL=(ALL) PASSWD: /usr/lpp/mmfs/bin/mm*, NOPASSWD: /usr/lpp/mmfs/bin/mmremote

It is also possible to disallow commands by adding a “!” in front of the command. In the following example the user admin is not allowed to run the command mmfsadm:

%admin ALL=(ALL) !/usr/lpp/mmfs/bin/mmfsadm

Instead of spelling out every command that is allowed or forbidden in the clause, so called command aliases can be created. The following example shows a command alias for some networking commands:

## Networking
Cmnd_Alias NET = /sbin/route, /sbin/ifconfig, /bin/ping, …

This alias can now be embedded into a clause defining user privileges. In the example below the user is allowed to run the above networking commands requiring the user password:

%admin ALL=(ALL) PASSWD: NET

In general, the sudoer-file can include multiple clauses for a given user. Be aware, however, that the file is interpreted from top to bottom. If there is a clause that allows a command and later on there is a clause that disallows a command for given user, the latter one becomes effective.

Another important feature in sudo are the logging capabilities. Sudo can be configured to log all commands that a given named user runs in the sudo context. In the following example all commands (input and output) the user admin runs with sudo are logged to the directory /var/log/sudo-io/admin:

%admin ALL=(root) PASSWD: LOG_INPUT: LOG_OUTPUT: cmds
Defaults iolog_dir=/var/log/sudo-io/%{user}

Alternatively, the clauses Defaults logdir=directory or Defaults syslog=auth can be used to enforce logging.

For more information about the features and syntax in sudo refer to the sudo man pages:

https://www.sudo.ws/man/sudoers.man.html#EXAMPLES  

 

What are IBM Spectrum Scale sudo wrapper

IBM Spectrum Scale does not have its own user management for administrative users using the command line interface (CLI). CLI users are authenticated by the operating system and have privileges to perform commands according to user configuration in the operating system. By default, the IBM Spectrum Scale cluster requires root privileges for administration.

To eliminate the need for direct root access IBM Spectrum Scale allows to configure and enable so-called sudo wrapper. With sudo wrapper commands are executed under the named user with root privileges but no longer as root user itself. Sudo wrapper relies on a sudo configuration that allows the named user to run certain commands with root privileges.

The key advantages of IBM Spectrum Scale sudo wrapper are:

  • Eliminates the need for the root user to allow password-less ssh-access to other nodes. 
  • Allow the use of named users to administer the cluster. Thereby privileges of an administrative user can be limited to a defined set of commands by leveraging sudo definitions.
  • Allows to permanently disable the root login via ssh (PermitRootLogin No).
  • The authorized key file of the root (/root/.ssh/authorized_keys) user is no longer required for IBM Spectrum Scale cluster nodes.
  • Allow logging of all commands executed by a user in the sudo context using the sudo logging features.

In contrast, sudo wrapper does not prevent entirely that a named user can elevate its privileges. Therefore, additional operational processes are required to assure that that the sudo definitions cannot be changed without permission and without being audited. In addition, sudo in general does not allow managing access permissions to files, only for commands. File access permission needs to be regulated using file system permissions and Access Control Lists (ACL).

With the current implementation (IBM Spectrum Scale version 5.1) sudo wrapper does not support the following IBM Spectrum Scale functions:

  • Installation toolkit (command: spectrumscale)
  • Clusters with Windows nodes
  • Clusters providing clustered NFS (cNFS) access

 

Configuration and Operations guidance

Users administering an IBM Spectrum Scale cluster should not be able to tamper with any data stored in the file system. Therefore, it might be appropriate to allow only commands (on an IBM Spectrum Scale software or operating system level) that are required for normal operations executed by administrative users. In special cases the privileges of these users can be temporarily increased by another user. This calls for the implementation of the four-eye principle where the administrative user requires the authorization of another user (security administrator) to perform a special task. 

For the implementation of the four-eye principle create two user groups and assign named users to each of these groups in the operating system. In this example one group is named gpfsadmin and another group is named secadmin. The following principles should apply:

  • Users in the group gpfsadmin should be able to administer IBM Spectrum Scale and Spectrum Archive during normal operations.
  • Users in the group secadmin should be able to manage the privileges of the users in the group gpfsadmin, for example to temporarily allow additional commands in case of problems. For this purpose, the user in the group secadmin is allowed to change the sudo-configuration.

The four-eye principle allows users of the group gpfsadmin to execute a limited set of commands that are required for normal operations. If a user of the group gpfsadmin requires more privileges (e.g. due to a problem), then the user can contact a user of the group secadmin. The user of the group secadmin can now grant the user of the group gpfsadmin further privileges temporary by changing the sudo definitions.

Configure IBM Spectrum Scale sudo wrapper according to instructions the below. Allow users in group gpfsadmin to run commands that are required to administer the IBM Spectrum Scale cluster. Allow users in group secadmin to change and distribute the sudo configuration. Find an example of the sudo configuration in section Configure sudo wrapper. In general, consider the following guidance:

  • Users in the group gpfsadmin should not be able to run all commands; instead limit this to the IBM Spectrum Scale commands that are required.
  • Users in the group gpfsadmin should not be able to obtain full root permission without being authorized by a user of the group secadmin.
  • Users in the group gpfsadmin should not be able to manage sudo configuration.
  • Users in the group gpfsadmin should not be able to change the time or time related configurations in the operating system.
  • Do not alter the set of commands for the group gpfsadmin in the sudo definitions that have to run without password.
  • Allow users in the group secadmin to change the sudo configuration (visudo or the like). This allows the user of the secadmin group to temporarily allow certain commands to the user in the gpfsadmin group.
  • Further allow the user in group secadmin to copy the sudo-configuration to the other (admin) nodes.
  • Configure logging of all commands run by all user groups in the sudo context (e.g. by configuring the sudo parameters logfile and / or iolog_dir in the sudoer-file). These logs shall be immediately sent to a remote log server and kept for the retention period of the files.

 Users in group secadmin can easily elevate their privileges because they control sudo. Persons with this privilege must be trusted. In addition, operational processes can be established that audit the involvement of these users and their activities on the system. Consider implementing a process that only allows users of the secadmin group to access a cluster node when approved by a user of the gpfsadmin group.

The IBM Spectrum Scale GUI has a separate user management. It is recommended to use the same user-names in the GUI and the CLI for the same user. In addition, the roles of the user in GUI should match the roles the user has in CLI.

Configuring sudo wrapper with four eye principle

Now I show how to implement sudo wrapper in a IBM Spectrum Scale cluster. The commands shown below are prefixed with the user name that performs the command, just to avoid confusion, because you must switch between user of the gpfsadmin group and root user.

In this example we have three cluster nodes named g1_node1, g1_node2 and g1_node3 running Red Hat Enterprise Linux. All cluster nodes are administrative nodes which means that IBM Spectrum Scale commands can be executed on any of these nodes.

This is intended as a high-level guidance. I cannot guarantee that this works for any environment. 

Configure user and groups

We create a group gpfsadmin and add user admin to this. This user - and all other users that might be added to this group - are IBM Spectrum Scale administrators, able to run all mm-commands (with some exceptions). In addition, we configure a group secadmin and add user secco to this. This user can change the sudo configuration and temporarily grant additional privileges to the admin user using the visudo command.

Note: Many of these steps must be executed on all cluster nodes and still require direct root login.

Create group gpfsadmin and user admin on all nodes (as root user). The group and user ID (1001) are arbitrarily chosen; you can use different IDs. Just make sure that these IDs are not used by other users and groups (file /etc/passwd). Creating users and groups may require root privileges:

[root]# groupadd -g 1001 gpfsadmin
[root]# useradd -c 'gpfs admin' -g gpfsadmin -m -u 1001 admin

Set password for user admin on all nodes (as root user):

[root]# passwd admin

 Now the user admin can log on to any cluster node using the user credentials.

 

Create group secadmin and user secco as member of this group on all nodes:

[root]# groupadd -g 1002 secadmin
[root]# useradd -c 'security admin' -g secadmin -m -u 1002 secco

Set password for user secco on all nodes for new user (as root user):

[root]# passwd secco

Now the user secco can log on to any cluster node using the user credentials.

 

Establish password-less ssh-communication allowing the root user to establish ssh-sessions as user admin on all nodes. This requires generating an ssh-key pair for the root user on all admin nodes and copying the public key to the authorized_keys file of the user admin on all other nodes. Perform the following steps as root user:

  1. If not already done, generate the ssh-key pair for the root user on all cluster nodes. To generate a ssh-key pair perform the following command, and do not enter a passphrase when asked; press enter instead a couple of times (as root user):
    [root]# ssh-keygen -m PEM

  1. Copy the public key of root user to the authorized_keys file of the admin This must be done from all admin nodes to all other nodes, including the source node itself. In our example all three nodes are admin nodes, so we must perform the following steps on all nodes (as root user):
    [root]# ssh-copy-id admin@g1_node1
    [root]# ssh-copy-id admin@g1_node2
    [root]# ssh-copy-id admin@g1_node3

 

  1. Test password-less ssh-communication for the root user as user admin from the admin nodes to all other nodes, including the source node itself (as root user):
    [root]# ssh admin@g1_node1
    [root]# ssh admin@g1_node2
    [root]# ssh admin@g1_node3

Password-less ssh-communication allowing the root user to establish ssh-sessions must be configured for all users in group gpfsadmin. Hence, if there are more users in group gpfsadmin, then the steps above must be performed for these users as well. These steps must not be performed for users in group secadmin because these users may not perform cluster administration.

 

Optionally, add the IBM Spectrum Scale command path (/usr/lpp/mmfs/bin) to the login profile of user admin on all admin nodes:

[root]# su - admin
(admin)$ vi .bash_profile
  export PATH=$PATH:/usr/lpp/mmfs/bin

 

Optionally, you can create a key pair for the admin user on all cluster nodes and copy it to the authorized_key file of all other nodes (including the source node itself). This enables password-less ssh-communication of the user admin between the cluster nodes. Perform the following steps on all nodes as admin user:

  1. Login as admin user and create the ssh-key pair; do not enter a passphrase, but instead press enter a couple of times:
    (admin)$ ssh-keygen -m PEM

  2. Copy the public ssh key of the admin user to all other nodes including the node itself
    (admin)$ ssh-copy-id <node-name>

  3. Test the ssh-connection to be password less with all other nodes including the node itself:
    (admin)$ ssh <node-name>

If you have multiple users in group gpfsadmin, perform the steps above for all users in group gpfsadmin.

 

You have now prepared the users and groups for the sudo configuration. Continue to the next section.

 

Configure sudo

IBM Spectrum Scale provides an example of the sudoer-file that can be used as template to implement sudo-wrapper. This file is located on a IBM Spectrum Scale cluster node in /usr/lpp/mmfs/samples/sudoers.sample. Save the current sudoer-file and copy the sudoers.sample file to /etc/sudoers on all nodes (as root user):

[root]# mv /etc/sudoers /etc/sudoers.backup
[root]# cp /usr/lpp/mmfs/samples/sudoers.sample  /etc/sudoers

If the current sudoer-file (/etc/sudoers.backup) was configured already then re-add the definitions to the new sudoer-file (/etc/sudoers).

Make the necessary adjustments to the sudoer-file on all nodes (as root user). In the example below users in the group gpfsadmin can run all mm-commands, with some exceptions. The users in group secadmin can run the command visudo and scp. In addition, we configure logging for all commands issued from users in the sudo context. To edit the sudoer-file run this command and it will open your default editor (vi):

[root]# visudo

Find below different section that should be added or updated in the sudoer-file:

Ensure that the environment variables associated with IBM Spectrum Scale are preserved:

#### Preserve GPFS env vars
Defaults    env_keep += "MMMODE environmentType GPFS_rshPath GPFS_rcpPath mmScriptTrace GPFSCMDPORTRANGE GPFS_CIM_MSG_FORMAT"

 

Ensure that the GPFS command path is part of the secure_path. If not then add the GFPS command path (/usr/lpp/mmfs/bin) to the secure_path.  This allows the user admin to run IBM Spectrum Scale commands without specifying the full path

#### add the GPFS command path to the secure path
Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin:/usr/lpp/mmfs/bin

 

Ensure that the option requiretty is deactivated:

# Disable "ssh hostname sudo <cmd>", because it will show the password

# Defaults    requiretty

If the option requiretty cannot be deactivated, then disable this option for the group gpfsadmin by adding the clause below the requiretty option shown above:

# Disable requiretty for gpfsadmin group

Defaults:%gpfsadmin    !requiretty

 

Add a rule to allow members of the group gpfsadmin to run all mm-commands after providing the password:

#### Allow members of gpfsadmin to run all mm-commands commands requiring the user password
%gpfsadmin ALL=(ALL) PASSWD: LOG_INPUT: LOG_OUTPUT: /usr/lpp/mmfs/bin/mm*, NOPASSWD: LOG_INPUT: LOG_OUTPUT: /usr/lpp/mmfs/bin/mmremote

With this sudo-rule the members in group gpfsadmin can run all mm-commands after entering the password. Note that the command /usr/lpp/mmfs/bin/mmremote must be allowed to run without password (IBM Spectrum Scale version 5.1 and above)

There are some mm- commands that have the potential to allow malicious members in the group gpfsadmin to elevate their privileges. Special attention should be given to the following mm-commands:

  • Operational commands: mmfsadm, mmaddcallback, mmapplypolicy
  • Commands manipulating the cluster: mmaddnode, mmcrcluster, mmchnode. mmccr, mmchconfig, mmdelnode, mmrestrictedctl1
  • Commands manipulating disk and file system configuration: mmcrnsd, mmadddisk, mmdeldisk, mmdelfs, mmdelfileset
  • All commands matching the pattern /usr/lpp/mmfs/bin/ts*

1 This command may be present in the future.

The commands shown above should be disallowed for users in the group gpfsadmin using the following sudo-rule. This sudo-rule must be placed underneath the sudo-rule allowing all GPFS mm-commands. The disallowed commands are listed line by line in the example below, to make it better readable. This requires a backslash (\) at the end of each line:

#### disallow certain mm-commands for members of the gpfsadmin group
%gpfsadmin ALL=(ALL) LOG_INPUT: LOG_OUTPUT: \
!/usr/lpp/mmfs/bin/mmfsadm, \
!/usr/lpp/mmfs/bin/mmaddcallback, \
!/usr/lpp/mmfs/bin/mmapplypolicy, \
!/usr/lpp/mmfs/bin/mmaddnode, \
!/usr/lpp/mmfs/bin/mmcrcluster, \
!/usr/lpp/mmfs/bin/mmchnode, \
!/usr/lpp/mmfs/bin/mmccr, \
!/usr/lpp/mmfs/bin/mmchconfig, \
!/usr/lpp/mmfs/bin/mmdelnode, \
!/usr/lpp/mmfs/bin/mmrestrictedctl, \
!/usr/lpp/mmfs/bin/mmcrnsd, \
!/usr/lpp/mmfs/bin/mmadddisk, \
!/usr/lpp/mmfs/bin/mmdeldisk, \
!/usr/lpp/mmfs/bin/mmdelfs, \
!/usr/lpp/mmfs/bin/mmdelfileset, \
!/usr/lpp/mmfs/bin/ts*

In case the user in the group gpfsadmin must execute a disallowed command, then the user must contact a user in group secadmin who has the privileges to change the sudo-rules (four eye-principle). I will further explain this process in section Operations with sudo wrapper.

Note: The list of commands allowing users to escalate their privileges is not meant to be complete. It is meant to provide some basic guidance for configuring sudo-rules. The attack vectors also depend on the functions used with IBM Spectrum Scale. This blog article focuses on the base functionality of an IBM Spectrum Scale cluster.

 

Now add a rule to allow members of the group secadmin to change the sudo configuration and to perform the secure copy command (scp):

#### Allow members of the secadmin group to run visudo
%secadmin ALL=(ALL) PASSWD: LOG_INPUT: LOG_OUTPUT: /usr/sbin/visudo, /usr/bin/scp

Allowing users in the group secadmin to use the secure copy command (scp) with root privileges allows users in this group to copy the sudoer-file to all other nodes.

 

Finally, enter the path for the logs where all activities from users are recorded:

#### Add logging
Defaults iolog_dir=/var/log/sudo-io/%{user}

Save and close the sudo-configuration file.

 

After the sudoer-file was updated, distribute all the changes to the other nodes. This can be done using ssh (requires root permissions). For example, if the adjustments have been done on g1_node1, you can copy the sudoer-file to nodes 2 and 3 as shown below:

[root]# scp /etc/sudoers g1_node2:/etc/sudoers
[root]# scp /etc/sudoers g1_node3:/etc/sudoers

 

On each cluster node that is an admin node run the sudo wrapper test as user admin. These tests must be run without errors

[root]# su - admin
(admin)$ sudo /usr/lpp/mmfs/bin/mmcommon test sshwrap g1_node1
(admin)$ sudo /usr/lpp/mmfs/bin/mmcommon test sshwrap g1_node2
(admin)$ sudo /usr/lpp/mmfs/bin/mmcommon test sshwrap g1_node3

(admin)$ sudo /usr/lpp/mmfs/bin/mmcommon test scpwrap g1_node1
(admin)$ sudo /usr/lpp/mmfs/bin/mmcommon test scpwrap g1_node2
(admin)$ sudo /usr/lpp/mmfs/bin/mmcommon test scpwrap g1_node3

 If the sudo wrapper test fails, then adjust the sudoer-file accordingly, distribute the adjusted sudoer-file to all other nodes and try the sudo wrapper tests again.

 

Enable and test sudo wrapper

If the above test completes without errors you can configure IBM Spectrum Scale to work with sudo wrapper as user admin.

(admin)$ sudo mmchcluster --use-sudo-wrapper
                          [--sudo-user memberOfAdminGroup]

The option --sudo-user is required for the IBM Spectrum Scale GUI. This option specifies the name of a user used by the GUI in the backend to perform mm-commands. The username specified with this option must be a user that is member in group gpfsadmin, for example user admin.

If the IBM Spectrum Scale GUI is installed and used, then restart the GUI after running the mmchcluster command above. This command requires root requires root privileges:

[root]# systemctl restart gpfsgui

 

Now perform some tests by logging on with the user admin and running mm-commands. You must run commands using the sudo prefix. Run some commands that are allowed and can cause changes to the cluster, for example:

(admin)$ sudo mmcrsnapshot

(admin)$ sudo mmcrfileset …


Run some commands that are disallowed, for example:

(admin)$ sudo mmapplypolicy …

Disallowed commands should fail and indicate that the user does not have privileges to perform disallowed commands.

 

Now test the privileges of the user secco in group secadmin. Log in with the user secco and invoke the sudo configuration:

(secco)$ sudo visudo

Changes may not be required at this point. However, if the user secco makes any changes to the sudo configuration, then the user secco must copy the sudoer-file to all other nodes. The example below assumes that the changes to the sudo configuration were done on g1_node1:

(secco)$ sudo scp /etc/sudoers g1_node2:/etc/sudoers
(secco)$ sudo scp /etc/sudoers g1_node3:/etc/sudoers

If changes were made to the sudo configuration, then these must be reset by the user secco after the user in group gpfsadmin has executed the required commands successfully.

Disable root login (optional)

You can disable direct root login on all cluster nodes.

Attention: Before you disable root login make sure that the members in the secadmin group can change the sudo configuration. Just in case root login must be re-enabled.

Disabling root login requires root privileges. Log on as root user or allow another user to become root and edit the following file:

[root]# vi /etc/ssh/sshd_config
PermitRootLogin No

Then restart the ssh-daemon:

[root]# systemctl restart ssh

 Perform this step on all cluster nodes. Afterwards, ensure that root login is d isabled.
 

Operations with sudo wrapper

During normal operations the user in the group gpfsadmin login with their named user credentials (e.g. admin) and perform commands using sudo as prefix

(admin)$ sudo mm-command

In case the user in the group gpfsadmin must execute a disallowed command, then the user must contact a user in group secadmin who has the privileges to change the sudo-rules. The user in group secadmin logs into a cluster node with the user credentials, invokes the sudo configuration (visudo), removes the required command from list of disallowed commands in the appropriate sudo-rule and copies the sudo configuration to all other nodes in the cluster. Alternatively, the user in group secadmin can just remove the exclamation mark (!) in front of the command that must be allowed:

(secco)$ sudo visudo

(Make changes)

(secco)$ sudo scp /etc/sudoers g1_node2:/etc/sudoers
(secco)$ sudo scp /etc/sudoers g1_node3:/etc/sudoers

Now, the user in group gpfsadmin can perform the required mm-command and when finished, the user in group secadmin adds back the removed command to the list of disallowed commands. Alternatively, the user in group secadmin adds the exclamation mark (!) in front of the command to be disabled.

The LOG_INPUT and LOG_OUTPUT parameters in the sudo-rule ensure that the activities of the user in group gpfsadmin are logged into a log file.

The process above implements the four-eye principle, because two sets of users are required to perform critical changes.

 

Summary

IBM Spectrum Scale sudo wrapper eliminates the need to allow password-less ssh-communication between the cluster nodes carried out by the root user. Furthermore, sudo wrapper allows enforcing named user login and tracing of their command activities in the sudo context. Thus, the root user login can be eliminated. However, sudo wrapper does not entirely prevent experienced users from escalating their privileges.

The setup of sudo wrapper requires a few steps and must be done with care. Especially, the testing of sudo wrapper must be done thoughtfully. After changing the sudo configuration file it must be distributed to all cluster nodes.

Security by design is one of the key design principles in the IBM Spectrum Scale development. Given the more than 20-year history of IBM Spectrum Scale additional work is in progress to improve security in the context of a IBM Spectrum Scale cluster.

 

Disclaimer

This document provides guidance for certain configuration and operational aspects in an IBM Spectrum Scale environment. While efforts were made to verify the completeness and accuracy of the information, it is provided “as is” without warranty of any kind, expressed or implied. IBM shall not be liable for any damages arising from configuration and operation steps outlined in this document.

IBM does not provide legal advice or represent or warrant that its services or products will ensure that the customer is in compliance with any law. IBM customers are responsible for ensuring their own compliance with legal requirements.

The software nature of the solution may allow malicious hackers to exploit the system and elevate privileges of users. The use of IBM Spectrum Scale sudo wrapper along with the list of IBM Spectrum Scale commands does not completely ensure that users escape the sudo environment and elevate their privileges.

1 comment
49 views

Permalink

Comments

Wed November 30, 2022 03:36 AM

Very useful article,  straight forward implementation