User can change to root but from root it cannot change to other users

Products

• CA Privileged Identity Management Endpoint (PIM)

Issue/Introduction

In certain systems where users can access root using the Privileged Access Manager rules, subsequently it is impossible to do su to a different user

For instance, let's imagine there is a SUDO record to access /bin/ksh as root

AC> sr sudo __ksh
(localhost)
Data for SUDO '__ksh'
-----------------------------------------------------------
Defaccess         : None
ACLs              :
    Accessor                Access
    user1      (USER   ) X
    user2      (USER   ) X
 Audit mode        : All
Owner             : adminusr        (USER   )
Create time       : 14-Jul-2021 23:32
Update time       : 15-Jul-2021 01:07
Updated by        : abc      (USER   )
Comment           : /bin/ksh
Target User       : root          (USER   )

Running this command as user2:

/usr/seos/bin/sesudo __ksh

That will open a new ksh prompt.

We can see that the user has changed to root by running id in the new prompt

 id --> uid=0(root) gid=0(root) groups=0(root)

Even though, for PIM, running a sewhoami would indicate that the user which is still user2

Now let's imagine that from this ksh prompt it is necessary to access user1

su - user1

When this problem occurs, the process is killed

Killed

And in seos Audit there is the following 

19 Jul 2021 12:58:47 P SURROGATE    user2   Read     1059  3 USER.user1        /usr/bin/su          XXXX                  root
19 Jul 2021 12:58:47 D SURROGATE    uxert2   Read       69  2 USER.root            /usr/bin/su          lXXX                   user1

We can see that it tries to Surrogate to root before trying to become user1. Since user2 does not belong to the USER.root surrogate class, it gets access denied and the operation is aborted

Environment

CA ControlMinder 12.81, 12.9 and PIM/PAM SC 14.X, all versions

Cause

This is normal in certain systems, for instance in Redhat. Let's assume that user1 has a UID of 1050, and user2 has a UID of 1052. For root the UID is 0

The way /usr/bin/su works in these systems is as follows

• Changing from user2 to user1 (e.g. doing su - user1 from user2). In this case a SUID from 1052 to 1050 is done, followed by another one from 1050 to 1052. Next a new child process is created and a SUID from 1052 to 1050 is done, after which a new session is started successfully
• Changing from root to user1 (which is what happens if, first of all, a /usr/seos/bin/sesudo __ksh is launched prior to doing su to root. In this case there will be a SUID from 0 to 1050, and then it will try to do SUID from 1050 to 0, as is the case above. However, if the surrogate to root is not allowed (USER.root does not contain permissions for user2), this step will be denied and the process will fail

This method of operation occurs for some flavors of UNIX/Linux and for these cases there is a specific setting which may be used in seos.ini

Resolution

Edit seos.ini and set the following variable

bypass_suid_program = /usr/bin/su

As indicated in the documentation, this setting accounts for those platforms where there are multiple su commands and root is protected via a surrogate rule

Additional Information

https://techdocs.broadcom.com/us/en/symantec-security-software/identity-security/privileged-identity-manager/14-0/reference/configuration-files/the-seos-ini-initialization-file/seosd.html