CTE Linux Authentication and Client Settings

CTE Linux client (also known as host) settings, which ensure CTE user access controls and systems protection, is a CipherTrust encryption feature that is often difficult to understand and configure. This section provides an updated description of CTE Linux 7.1.1 client settings, authentication, and different authenticators.

The intended audience of this information are CTE and CipherTrust Manager administrators. It is assumed that they are knowledgeable on Linux/Unix concepts, techniques, and security features. Additionally, it is assumed that they have read the CTE and CipherTrust Data Security Platform Service administration documents and are familiar with the CipherTrust Data Security Platform Service security policies and capabilities.

Root Privileges

Users with root privileges on Linux systems 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 Access Controls

Use CTE 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 GuardPoints.

Individual users (including root) accessing the CTE GuardPoint data can therefore be granted or denied access.

The CipherTrust Data Security Platform Service policies track and prevent privileged users (including setuid root programs) from reading, modifying, or executing files and directories residing in the GuardPoints owned by normal/unprivileged users.

For every running operating system process, CTE maintains a separate trusted ID distinct from each process’ real and effective UIDs. This trusted ID is used for making decisions based on user-related policy evaluations. One such example is CTE differentiating between:

• A user who logs in, and is therefore explicitly authorized, as root.

  AND

• A user who logs in, is authorized as a normal/unprivileged user, and subsequently runs a potentially malicious setuid program like su to gain root privileges.

System (and in some cases, certain classes of users) applications on the CTE client such as sshd, login, and su etc. authenticate a user’s identity by requesting user credentials, authorizing the user, and spawning child processes.

Therefore, for a process to access protected data, the user's identity must be established as authenticated and authorized by these special authenticator binaries. Processes (including their descendants) spawned by authenticators like sshd and login are treated as authorized and therefore trusted. The real (or in some cases, effective) UID of the progeny is recorded for granting access. Processes continue to be tracked and identified with the original trusted ID even though its operating system UID and effective user ID (EUID) may change without proper authorization. Invocation of a setuid root program to acquire root privileges or a root user issuing su to become another user are some examples of unauthorized (and possibly malicious) transitions.

For example, sshd runs as user root. When a user logs into a system using sshd, it forks off a child process, changes the UID of that process to the logged in user (say, alice), and then executes a process like bash. Because sshd is tagged with |authenticator|, CTE records the trusted user ID of the new process and of every process that it spawns with alice’s real UID. If alice tries to change its UID to root by running a setuid root program, it changes according to the operating system, but not according to CTE. From a policy evaluation standpoint, CTE still treats the setuid-escalated root process with user ID alice. If the GuardPoint policy prevents root accesses, CTE denies this root-escalated process from accessing the GuardPoint as an unauthorized operation. In this case, CTE terms the root user as a fake user and logs it as such.

By default, the CTE 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 Agent is to be instructed to trust the authenticator process progeny. For example, /usr/sbin/sshd is a process that can be trusted to authenticate the user to the system and to CTE.

CTE 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 client. The subsequent sections describe the client settings tags, their properties and behavior, and the equivalent binaries and best practices.

Enabling CTE Client Settings for Authenticator Programs on the CipherTrust Data Security Platform Service

Client settings can be enabled for individual clients or client groups with the CipherTrust Data Security Platform Service GUI or REST API. On the CipherTrust Data Security Platform Service GUI, the Client Settings tab of clients is used to configure client settings.

Refer to Client Settings for details.

The client settings provided by the default installation are examples. It is recommended to remove all unnecessary client settings, as these may pose security risks.

Adding, Removing, or Modifying Client Settings

When client settings are modified, it is recommended to verify the updated settings after some time (a few minutes later). This can be done by running secfsd -status auth. Also, before applying the new client settings, the dependent applications, if any, should be stopped.

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’s trusted UID. Therefore, CTE 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. This mode should be used sparingly.

authenticator_euid

The authenticator_euid keyword works similar to authenticator, but instead of the real UID, the CTE 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 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

Similarly, DB2’s db2start application binary should have the authenticator_euid tag.

su_root_no_auth

The su_root_no_auth keyword is applicable only to the /usr/bin/su binary and should be deployed with the sshd authenticator:

|authenticator| /usr/bin/sshd
|su_root_no_auth| /usr/bin/su

With su_root_no_auth, a non-root user is permitted to log in as another user through su. The new user is authorized after authentication, that is, after providing the new user’s password. However, root is prevented from being authorized as another user.

path_no_trust

The path_no_trust keyword instructs CTE to not trust, that is, not authorize a binary’s process and its progeny. Therefore, users associated with these processes are unauthorized and flagged as such when accessing CTE GuardPoint data.

For example, /usr/bin/ksh is tagged as path_no_trust while /usr/bin/su is tagged as authenticator. A user who runs /usr/bin/su from this non-trusted ksh is unauthorized even though /usr/bin/su is a valid authenticator.

The path_no_trust keyword can be used to disallow selected executables from a large pool, for example, to trust all client binaries except three specific ones. This is achieved as follows:

|trust|*
|path_no_trust| /usr/bin/su
|path_no_trust| /usr/bin/ksh
|path_no_trust| /usr/bin/login

These client settings allow all client binaries to be trusted except /usr/bin/su, /usr/bin/ksh, and /usr/bin/login.

It is important to note the path_no_trust authenticator overrides any previous authenticator tags placed on the same binary. For example, when tagging the /usr/bin/su binary, path_no_trust overrides any authenticator tags already set on /usr/bin/su.

The behavior described above is applicable to CTE 7.1.1 and higher versions. For older CTE versions, |trust|* overrides all other authenticator tags.

trust

The trust keyword is a carryover from older CTE versions and retained for legacy/backwards compatibility. The |trust|* authenticator allows users to be trusted regardless of the authentication method.

This mode, however, weakens against attacks by root users (that is, system administrators). Its use is strongly discouraged.

Conclusion

CTE access controls require correct specification of client setting authenticators for proper authorization. This document highlights various authenticators supported by CTE 7.1.1 and their use cases. Future releases of CTE will continue to expand access controls and authenticator capabilities.

References

1. Using Host Settings for Linux with VTE. Thales white paper. March 2017

2. CTE and CipherTrust Data Security Platform Service Documentation

3. Advanced Programming in Linux and Unix Environments. Stevens & Rago 3rd Edition

4. Linux man pages including su(1), login(1), sshd(8), setuid(2), the setuid(4), and seteuid(4) APIs etc.

Appendix 1: Deploying the Correct Authenticator

Here are the basic questions for determining what client setting authenticators to apply to the process.

• Does the process authenticate users, having them supplied credentials?

  YES:

  |authenticator|<path-to-binary>/<binary-name>
  

• Is the process started and run as a service account, specifically by the root account?

  YES:

  |authenticator_euid|<path-to-binary>/<binary-name>
  

• Does the process run with a specific user ID, and whether no other user IDs should be allowed?

  YES:

  |authenticator_euid|<path-to-binary>/<binary-name>
  

• Should root be prevented from becoming any other user to access data?

  YES:

  |authenticator|/usr/bin/sshd
  |su_root_no_auth|/bin/su
  

• How do I use authenticator keywords with Java applications?

  Java runtime binary file can be set as follows:

  |authenticator_euid|<path-to-binary>/java
  

  Contact Thales Customer Support for specifying arguments to Java programs.

Appendix 2: Related Non Authenticator Client Settings

protect

The |protect| keyword protects the system credential files from tracking and preventing malicious updates. Refer to the CTE Agent Advanced Configuration and Integration documentation for additional details on these client settings.

Appendix 3: Description of Common Audit Messages

User Not Authenticated

This message indicates CTE is unable to establish the user’s authorization status due to incomplete information from authenticator application processes.

2021-04-07 03:46:06.728 [CGP] [ERROR] [5206] [CGP2602E] [ALARM]  Policy[host-settings-policy] User[root,uid=0,euid=0 (User Not Authenticated) (bash[pid=5058,uid=0,euid=0] : sshd[pid=5035,uid=0,euid=0]:sshd[pid=4991,uid=0,euid=0] : systemd[pid=1,uid=0,euid=0])] Process[/usr/bin/cat]Action[read_file]Res[/home/bob/gp/testfile]Key[None] Effect[PERMITTED Code (1A,2U,3M)]

Possible reasons include:

• The user logging in even before CTE started.

• A misconfigured authenticator client setting (possibly due to incorrect paths).

Therefore, a policy restricting specific user accesses to GuardPoints fails evaluation.

User Impersonation

2021-04-07 04:10:24.714 [CGP] [ERROR] [7865] [CGP2602E] [ALARM]  Policy[host-settings policy] User[root,uid=0,euid=1004,gid=0\\root\\ (faked as(bob,1004)) (bash[pid=7819,uid=1004,euid=1004] : su[pid=7818,uid=0,euid=0] : bash[pid=7736,uid=0,euid=0] : sshd[pid=7724,uid=0,euid=0] : sshd[pid=7697,uid=0,euid=0])] Process[/usr/bin/cat] Action[read_file] Res[/home/bob/gp/testfile] Key[None] Effect[FAKED USER!! DENIED  Code (1A,2U,3M)]

A user (in this case, root) logs in and is authorized by an authenticator application. A descendant process subsequently runs an unauthorized (non-client setting authenticator) setuid binary to change to another user named bob without authentication. Therefore, the process is still authorized as root and not bob. Therefore, bob is termed a fake user.

Cron

Cron is started by the init process during system boot. It runs as a root process, processes the crontab jobs, and runs the requests as the designated user. A root user could cause a cron entry to be run as any other user without that user being authenticated or authorized. Cron-based authentication is not supported.