CTE-U Linux Authentication and Client Settings
CTE UserSpace client (also known as host) settings, ensures CTE UserSpace user access controls and systems protection. This section provides a description of the client settings, authentication, and the two authenticators available with CTE UserSpace.
Root Privileges
Users with root privileges have unrestrained capabilities to override all file access and execution permissions imposed by the system. setuid
programs running with root permissions and privileges can create, remove, or modify any files in the system. By exploiting the ability to escalate privileges, adversaries can subvert system controls and access and steal confidential data.
CTE UserSpace Access Controls
Use CTE UserSpace client access controls to:
-
Curtail privileges of root users and
setuid
programs. -
Specify policies to restrict "who" (the client system users or groups) and "what" (the application processes or binaries) access to protected data within CTE UserSpace GuardPoints.
By default, the CTE UserSpace Agent does NOT trust any process as authenticated. Any attempt to access a resource by any process is therefore flagged with a User Not Authenticated
notification. Therefore, the CTE UserSpace Agent must be instructed to trust the authenticator process progeny.
CTE UserSpace client settings are the means by which an administrator configures user authorization. Client settings are tags or keywords with pipe (|
) delimiters specifying full-system binary paths to trusted programs (referred to as authenticators) on the CTE UserSpace client. The subsequent sections describe the client settings tags, their properties and behavior, and the equivalent binaries and best practices.
Enabling CTE UserSpace Client Settings for Authenticator Programs on the CipherTrust Manager
Client settings can be enabled for individual clients or client groups with the CipherTrust Manager GUI or REST API. On the CipherTrust Manager GUI, the Client Settings tab of clients is used to configure client settings.
Note
The client settings provided by the default installation are examples. Remove all unnecessary client settings, as they may pose security risks.
Adding, Removing, or Modifying Client Settings
When client settings are modified, verify the updated settings after a few minutes by running secfsd -status auth
. Also, before applying new client settings, stop any dependent applications.
Description of Authenticators
authenticator
The authenticator
keyword is used to specify the full path of the authenticator program authorizing the real UID of the process progeny. The real UID of the process, and its descendants, are used to set CTE UserSpace’s trusted UID. Therefore, CTE UserSpace follows and authorizes the real UID of the user authenticator process and its descendants. In general, programs that use user name and password pairs (for example, sshd
and login
) are candidates for being authenticators.
Example of client settings:
`|authenticator|/usr/sbin/sshd`
`|authenticator|/usr/sbin/in.rlogind`
`|authenticator|/bin/login`
`|authenticator|/usr/bin/gdm-binary`
`|authenticator|/usr/bin/kdm`
Programs that do not authenticate users should not be tagged as authenticators. Examples of such programs include su
invoking setuid
/seteuid
or setgid
/setegid
system calls. Tagging /usr/bin/su
with the authenticator
keyword authorizes a root user to become a non-privileged user even without authentication. Therefore, /usr/bin/su
should not be set as an authenticator.
/usr/bin/su
can be set as an authenticator in cases where a root administrator legitimately uses su
to temporarily switch privileges. Use this mode sparingly.
authenticator_euid
The authenticator_euid
keyword works similar to authenticator
, but instead of the real UID, the CTE UserSpace access control uses EUID for granting access. Specifically for Oracle, the database process (oracle
) is started by the root process and then a setuid
system call forces the service account user ID of either oracle
or orauser
. For such processes, CTE UserSpace should rely on the EUID of the process for authentication.
The |authenticator_euid|
keyword is applied as follows:
`|authenticator_euid|/u01/app/oracle/dbhome_1/bin/oracle`
`|authenticator_euid|/u01/app/grid/bin/grid`
Deploying the Correct Authenticator
To authenticate users after they supplied credentials
`|authenticator|<path-to-binary>/<binary-name>`
Start the process and run as a service account as root
`|authenticator_euid|<path-to-binary>/<binary-name>`
Run with a specific user ID or no user ID
`|authenticator_euid|<path-to-binary>/<binary-name>`
Prevent root from becoming any other user to access data
`|authenticator|/usr/bin/sshd`
`|su_root_no_auth|/bin/su`