search cancel

PAMSC - ssh with personal id gets set as root ( sewhoami -a ) with etrust / seos running


Article ID: 255350


Updated On:


CA Privileged Identity Management Endpoint (PIM)


We have a case when logging into server via ssh with personal id (etrust running) getting a root access(context)

For example I login with my id user320 and right away I issue sewhoami -a command and it shows 

[email protected]:/export/home/user320$ sewhoami -a
ACEE Contents
  User's Name             : root
  ACEE's Handle           : 2
  Group Connections Table:
    Group Name              Connection Mode
            ====================    =================================
    adm                     Regular
    bin                     Regular
    daemon                  Regular
    eacadmin                Regular
    eacaudit                Regular
    lp                      Regular
    mail                    Regular
    nuucp                   Regular
    other                   Regular
    root                    Regular
    sys                     Regular
    sysadmin                Regular
    tty                     Regular
    uucp                    Regular
Categories              : <None>
Profile Group           : <None>
Security Label          : <None>
User's Audit Mode       : Failure LoginSuccess LoginFailure
User's Security Level   : 0
Source Terminal         : <Unknown>
Process Count for ACEE  : 6183
User's Mode             : Admin Auditor
ACEE's Creation Time    : Fri Nov 18 09:14:53 2022



Release : 12.8, 14.x


The reason this occurs is because seos was not able to accurately evaluate the username for the user so it defaults to the root user.

This does not provide root rights on the OS but seos will apply any seos rules that also apply to the root user. 


In this case secifically the seos ruleset was missing the LOGINAPPL specifically for tectia ssh so adding the LOGINAPPL rule resolved the issue

[email protected]:/export/home/user320$ ps -ef| grep tectia
    root  2231  2228   0   Nov 22 ?         417:43 /opt/tectia/libexec/ssh-servant-g3 --slave --start-service
    root  2232  2228   0   Nov 22 ?         417:42 /opt/tectia/libexec/ssh-servant-g3 --slave --start-service
    root  2230  2228   0   Nov 22 ?         416:39 /opt/tectia/libexec/ssh-servant-g3 --slave --start-service
    root  2228     1   0   Nov 22 ?         363:58 /opt/tectia/libexec/ssh-server-g3 --start-service
    root  2229  2228   0   Nov 22 ?         416:42 /opt/tectia/libexec/ssh-servant-g3 --slave --start-service
    root  2233  2228   0   Nov 22 ?         417:47 /opt/tectia/libexec/ssh-servant-g3 --slave --start-service
    user320 22704 22433   0 10:36:50 pts/1       0:00 grep tectia
[email protected]:/export/home/user320$ selang
AC> editres LOGINAPPL ('SSH6') audit(ALL) defaccess(EXECUTE) owner('etrust') loginflags(NONE) loginmethod(NORMAL) loginseq(SGRP SUID) loginpath(/opt/tectia/libexec/ssh-user-exec)
Successfully created LOGINAPPL SSH6


Note: If you login as root and sesu to a user then the PIM user is still root. That is by design. If you login as user320 and sesu to root the PIM user (sewhoami) is still user320 ...The reason for this is to maintain the rules set for the "original" user.