Special Cases for CTE Policies

This section describes some CTE-specific configuration tasks related to configuring policies in the key manager. It contains the following topics:

• Re-Enabling Automatic Signing for Host Settings

• Restricting Access Overrides from Unauthorized Identities

• Blocking ptrace system calls to prevent process injection attacks

• SystemD Protection

Re-Enabling Automatic Signing for Host Settings

Starting with VTE for Linux release 6.0.2, VTE blocks automatic re-signing of the host settings. Some users may have established procedures for updating system software that are based on the assumption that restarting the vmd will generate new signatures when signed software is updated. This is no longer true. However, you can re-enable automatic re-signing if your environment requires it.

Caution

Re-enabling the automatic regeneration of signatures exposes a potential security vulnerability for CTE Agents. When enabled, host setting binaries are re-signed when CTE receives a push from the associated key manager. If an attacker were to replace a binary with a Trojan, and then force a push from the key manager by, for example, restarting the CTE Agent, CTE could generate a signature for the malicious binary and pass it.

To re-enable automatic re-signing for host settings:

1. Change to the directory where the agent.conf file resides. For example, type:

   cd /opt/vormetric/DataSecurityExpert/agent/vmd/etc/

   Copy

2. Edit the agent.conf file.

3. Change or add the following line:

   AUTO_RESIGN_HOST_SETTINGS=TRUE

   

   Note

   Previously this setting was known as RE_SIGN_HOST_SETTINGS. Starting with VTE for Linux 6.1.3, the attribute name is AUTO_RESIGN_HOST_SETTINGS as shown above.

4. Save your changes and exit the file.

5. Restart the vmd to set the changes. Type:

   /etc/vormetric/secfs restart

   Copy

6. Type the following to verify that the host settings is set to true:

   vmsec vmdconfig

   Copy

Restricting Access Overrides from Unauthorized Identities

CipherTrust Transparent Encryption host/client settings are the means by which an administrator configures user authorization. Users with root privileges, on Linux or AIX systems, have the unfettered ability to override all file access and execution permissions imposed by the system.

CipherTrust Transparent Encryption access control allows you to restrict privileges of users, groups, application processes and binaries, including root users and setuid programs. By default, CipherTrust Transparent Encryption agent DOES NOT trust any process as authenticated. Any attempt to access a resource, by any process, will therefore be flagged with a “User Not Authenticated” notification. The CipherTrust Transparent Encryption agent must 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 CipherTrust Transparent Encryption.

In some setups, when editing a host, system administrators can use the host settings > |authenticator| feature with su to change identities and gain access to restricted data. You can instruct CipherTrust Transparent Encryption to not trust any authentication attempt performed by certain identities by assigning restricted users to a user shell that CipherTrust Transparent Encryption can block from authenticating other processes.

Any executable path that is marked with a |path_no_trust| host setting marks the process, and all child processes, as not trusted. Non-trusted processes are treated as "User Not Authenticated" to prevent access on user-based policies.

CipherTrust Transparent Encryption prevents overrides from other host settings authenticators, using the |path_no_trust| status. If a user runs the su command from a non-trusted shell, that new shell is still marked as |path_no_trust|, even if |authenticator|/usr/bin/su is specified in the host-settings. The |path_no_trust| feature overrides any and all authenticators under host settings.

Note

Using |trust|* before a |path_no_trust| host setting no longer disables the |path_no_trust| host setting.

For example, the following host setting denies authentication for users accessing through sshd:

|trust|*
|path_no_trust|/usr/sbin/sshd

To restrict access overrides:

1. In the CipherTrust Manager products page, click Transparent Encryption > Clients.

2. Click on an existing Client name to edit the host.

3. Click Client Settings tab.

4. Add the following to the settings:

   |path_no_trust|<path of the binary>

   Copy

   Example:

   |path_no_trust|/bin/ksh

   Copy

   The above example indicates that no process under the kshell executable will be authenticated.

5. Click Apply.

Blocking ptrace system calls to prevent process injection attacks

To prevent a process injection attack, which could lead to access to encrypted data by a tampered process, Thales implemented a global blocking for the ptrace system call. The purpose of this feature is to provide configurable options for disabling the ptrace system call based on user need. CTE provides toggle options on CipherTrust Manager based on the dynamic parameter which allows a security administrator to select which binaries are protected from ptrace attachment.

Note

This change can be very invasive and block legitimate uses of the ptrace system call.

Options

There are three new options:

Enabled_For_Authenticators

The CTE binaries and the binaries specified in the authenticator list are protected from the ptrace attachment. Other binaries are not protected from the ptrace attachment. (Default behavior)

Enabled_For_All

All of the installed binaries are protected from ptrace attachment. This protects from a tampered processes causing process injection attacks through the ptrace attach call.

Disabled_For_All

The CTE binaries are protected from ptrace attachment but the binaries specified in the authenticator list are allowed to attach to a ptrace system call. This solves the problem of a user trying to attach a ptrace system call to one of the binaries specified in the authenticator list for other use cases. Other binaries are not protected from the ptrace attachment.

Note

If you select Disabled for All, make sure that you set the log level on CipherTrust Manager to WARN or higher. If it is set to the default log level of ERROR, there will not be any messages related to ptrace logged in the vmd.log file.

Configuration

To configure blocking the ptrace system call:

1. Log on to CipherTrust Manager.

2. Click Transparent Encryption.

3. Click on the desired client name to open it.

4. In the Advanced Security Configuration, click View/Edit Settings link.

   

5. Select the appropriate option and click save.

SystemD Protection

In RedHat 7 and subsequent versions, a lot of system functionality has been moved to /etc/systemd/ which was previously not protected in CipherTrust Transparent Encryption. CipherTrust Transparent Encryption now gives you the option to protect it, meaning that no one can modify or delete files.

To protect the systemD directory:

1. Log on to CipherTrust Manager.

2. Click Transparent Encryption.

3. Click on the desired client name to open it.

4. In the Advanced Security Configuration, click View/Edit Settings link.

   

5. Select enabled or disabled and click save.

6. If you need to add a process to the directory:

   a. Disable protection.

   b. Add the file to the /etc/systemd/ directory.

   c. Re-enable protection.