Client Settings
Applications such as su
, sshd
, and login
authenticate users' identity by requesting user credentials (user name and password). These are signed applications that identify and authenticate before a child process is executed.
GuardPoints can have an associated policy that restricts access to the data stored in them. For a process to access the data, the user's associated identity must be authorized. This authorization can be done by adding an entry to the Settings field on the Client Settings tab. This entry specifies a program, such as mentioned above, with a keyword that indicates the type of authorization that is applied.
Client settings configured on the CipherTrust Manager are pushed to the clients periodically.
Any changes to the client settings are not automatically signed. Signatures of the newly added processes are compared against the signatures in the existing settings. If they differ, an error message is generated. Refer to Re-Sign Settings for steps to configure this setting. Refer to the CTE Agent Advanced Configuration and Integration Guide specific to your platform for details about this feature.
Client settings can also be configured at the client group level, refer to Inheritance of Client Group Settings for details.
Note
Refer to CTE Linux Authentication and Client Settings for detailed and additional information on authentication and client settings.
Client Settings for Linux
Specify the authentication mechanisms in place for certain binaries on the client machine.
Default Settings for Linux
|authenticator|/usr/sbin/sshd
|authenticator|/usr/sbin/in.rlogind
|authenticator|/bin/login
|authenticator|/usr/bin/gdm-binary
|authenticator|/usr/bin/kdm
|authenticator_euid|/usr/sbin/vsftpd
Add, edit, or modify authentication settings as appropriate.
Additional Settings for HDFS (Linux Clients)
Depending on the Hadoop security authentication mode, additional settings are needed for CTE clients in an HDFS cluster. Add the following settings as appropriate.
/usr/jdk64/jdk1.8.0_40/bin/java
is the Java executable used to launch the HDFS services. Change the
Note
Java jdk path to reflect your end-user environment.
Sample setup when
hadoop.security.authentication
mode is simple.|authenticator+arg=+class=org.apache.hadoop.hdfs.server.namenode.NameNode|/usr/jdk64/jdk1.8.0_40/bin/java |authenticator+arg=+class=org.apache.hadoop.hdfs.server.datanode.DataNode|/usr/jdk64/jdk1.8.0_40/bin/java
Sample setup when
hadoop.security.authentication
mode is Kerberos.|authenticator+arg=+class=org.apache.hadoop.hdfs.server.namenode.NameNode|/usr/jdk64/jdk1.8.0_40/bin/java |authenticator+arg=+class=org.apache.hadoop.hdfs.server.datanode.SecureDataNodeStarter|/usr/lib/bigtop-utils/jsvc
Authentication Settings for Signature Sets (Linux Clients)
The CipherTrust Manager provides an option to configure authentication of CTE client binaries. If a binary, whose path matches a client setting entry, is executed on the CTE client, the operation is validated using the binary signature stored in a signature set on the CipherTrust Manager. Based on the authenticity of the binary, the operation is validated as "User Authenticated" or "User Not Authenticated" as appropriate.
The format to specify authentication settings for a signature set is:
|privilege+sig=<signature-set-name>|/path/to/binary
For example, to specify authentication settings for a signature set test-sign-set
for a binary stored at /home/test/run-test
, add the entry:
|authenticator+sig=test-sign-set|/home/test/run-test
The wildcard character asterisk (*
) can also be used to specify paths in client settings as:
|keyword+sig=<signature-set name>|/path/to/binary/*`
For example, to specify authentication settings for all binaries under /home/test/
, add the entry:
|authenticator+sig=test-sign-set|/home/test/*
Note
The wildcard character *
is supported for Linux clients only.
Specify Authentication Settings
To specify authentication settings for the client:
Open the Transparent Encryption application.
Under Client Name, click the desired client.
Click the Client Settings tab. The Settings text box contains the authentication settings.
Each line has the format:
|privilege|/path/to/binary
The format to specify authentication settings for a signature set is:
|privilege+sig=<signature-set-name>|/path/to/binary
Refer to Client Settings Keywords for keywords.
In the Settings box, specify the authentication mechanism.
Note
To delete the settings, delete the content and click Apply.
To edit the settings, modify the content and click Apply. When editing the setting strings, follow the format
|privilege|binary
.To cancel any changes, click Cancel.
Click Apply.
Client Settings for Windows
For applications running under WOW64
that require some form of user authentication, create entries on the Client Settings tab. The syswow64
paths are created by default when the CTE Agent is installed. \Windows
is for Windows XP and Windows Itanium operating systems.
In WOW64
, all file access to C:\Windows\System32
is redirected to C:\Windows\syswow64
, and is implemented using the File System. Redirected syswow64
paths are effective only for 64-bit Windows file agents. This is the path where programs compiled for 32-bits are stored to run on a 64-bit system.
Before proceeding, verify that the volume letter and the path for the Windows system are correct. When the CTE Agent is installed, the volume letter defaults to C:
It is possible that the executables on the Client Settings tab are on a different volume or in a different folder. If the volume or path information is incorrect, the CipherTrust Manager cannot sign the applications, and it cannot apply Agent Lock and System Lock.
Default Settings for Windows
||C:\WINDOWS\system32\winlogon.exe
|lock|C:\WINDOWS\system32\msiexec.exe
|lock|C:\WINDOWS\system32\wuauclt.exe
|lock|C:\WINDOWS\system32\wupdmgr.exe
|lock|C:\Program Files\Vormetric\DataSecurityExpert\Agent\Secfs\sec\bin\vminstall.exe
|exempt|C:\WINDOWS\explorer.exe
|exempt|C:\WINDOWS\regedit.exe
|exempt|C:\WINDOWS\system32\regedt32.exe
|exempt|C:\WINDOWS\system32\svchost.exe
|exempt|C:\WINDOWS\system32\services.exe
|exempt|C:\WINDOWS\system32\smss.exe
Add, edit, or modify authentication settings as appropriate.
Specify Authentication Settings
To specify authentication settings for the client:
Open the Transparent Encryption application.
Click Clients > Clients.
Under Client Name, click the desired client.
Click the Client Settings tab. The Settings text box contains the authentication settings.
Each line has the format:
|privilege|/path/to/binary
Refer to Client Settings Keywords for keywords.
In the Settings box, specify the authentication mechanism.
Note
• To delete the settings, delete the content and click Apply.
• To edit the settings, modify the content and click Apply. When editing the setting strings, follow the format|privilege|binary
.
• To cancel any changes, click Cancel.Click Apply.
Oracle Database in a Guarded NFS Mount on AIX
To locate your Oracle database in a guarded NFS mount:
Open the Transparent Encryption application.
Under Client Name, click the desired client.
Click the Client Settings tab. The Settings text box contains the authentication settings. Each line has the format:
|privilege|/path/to/binary
In the Settings text box, add the following entries:
|vfsnumber|<path to>/oracle |vfsnumber|<path to>/dbca
Example:
|vfsnumber|/u01/app/oracle/dbhome_1/bin/oracle |vfsnumber|/u01/app/oracle/dbhome_1/bin/dbca
Click Apply.
Client Settings Keywords
The following table lists the keywords that you can enter on the Client Settings tab. These keywords override different authentication requirements:
Keyword | Description |
---|---|
|authenticator| | (UNIX only) Authenticates based upon the real user ID (ruid) credentials of a process. The indicates that the given binary is trusted to authenticate users. For example, the sshd process on UNIX is a good |authenticator| . It takes incoming network connections and authenticates the user that attempts to log on to the system. All child processes from this session are trusted as the original user. |
|authenticator_euid| | (UNIX only) Authenticates based upon the effective user ID (euid ) credentials of a process. The keyword is used to authenticate the credentials of a setuid process with the euid value rather than the ruid value. |
|vfsnumber| | (AIX [all supported]/Oracle 10gR2) Use when Oracle RMAN backups fail on NFS as a result of not receiving underlying file system identifiers. Apply |vfsnumber| to the Oracle binaries directory. |
|realfsid| | (AIX [All supported]) Use if the cp operation fails while copying files with extent attributes on guarded Veritas file systems. The failure occurs because the underlying file system identifier is not received. |
|lock| | (Windows only) Specifies an application that cannot be executed on the client. An application defined with lock does not go through an internal policy check. The application is not allowed to run at all. A default set of applications is locked on Windows clients to prevent their execution and potential failure during bootup. The same effect can be achieved by configuring the resource and process security rule attributes in a policy. However, certain default applications are automatically locked on the Client Settings tab as a precautionary measure. Those applications must be included in the policy. Sometimes, problems such as installation failure or application lockup occur when installing software on a locked client. In such cases, identify the locked processes, unlock them, and retry installation. The failure goes away. For example: |lock|c:\winnt\system32\msiexec.exe |
|exempt| | (Windows only) When processes or applications are started, the internal policy and regular policies are checked locally or by the CipherTrust Manager. When a policy check is performed and exempt is applied to the process, a six second timeout is imposed on the check. Without exempt, an application can wait indefinitely for a policy access check to complete, as when the CipherTrust Manager is required but is inaccessible. If the check times out because the CipherTrust Manager is unavailable for any reason, access is denied. Exempt client processes are also "exempt" from popup messages that describe the occurrence of access violations. An example of what causes such popup messages is an application that tries to memory map a file for which it does not have encryption permission (for instance, memory map with no view ability key on Windows). The only reasons to include exempt in the configuration are shorter wait periods and blocked popup messages. |
|su_root_no_auth| | (UNIX only) Assigned only to the su process for tracking root users issuing unauthenticated su logins. The |su_root_no_auth|/usr/bin/su host setting in conjunction with |authenticator|/usr/lib/ssh/sshd prevents root from being authorized as another user. Non-root users using su to log on as another user after authentication, that is, after providing a password are not affected. |
|path_no_trust| | (UNIX only) Any executable path that is marked with a |path_no_trust| client 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.CTE prevents overrides from other client 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 client settings. The |path_no_trust| feature overrides any and all authenticators under client settings. |
|protect| | When a file is marked as protected in the client host settings, that file is protected from being modified or deleted, (even from a root process). It is not guarded and the file can be external to a GuardPoint. If the file marked as |protect| does not exist, then CipherTrust Transparent Encryption creates a 0-length file in its place. This provides an efficient means to identify and implement file protection. When the agent is stopped or uninstalled, these 0-length files are deleted and then re-created if the agent is restarted. Additionally, an audit record is generated when a file operation is denied.The |protect| status is displayed using the command secfsd -status auth. |
The following table shows different results you get when using authenticator
or authenticator_euid
to verify user identities.
Product | Application | Client Setting | User |
---|---|---|---|
Oracle | oracle | authenticator_euid | "oracle" |
Oracle | oracle | authenticator | * |
*
indicates the real uid of the user who starts the application. This means that if the policy is configured to check the user ID, a security rule must be generated for every possible user.
Note
Apply the |authenticator_euid|
keyword to the oracle binary on the Client Settings tab to authenticate the oracle
user because regardless of who starts the oracle process, the EUID
is always oracle
.
Configuring Application Authentication Credentials
To configure application authentication credentials:
Open the Transparent Encryption application.
Click Clients > Clients.
Under Client Name, click the desired client.
Click the Client Settings tab. The Settings box displays the default set of system applications that may require authentication entries.
In the Settings box, add, modify, or delete entries to control their access permissions. When you add more processes, you must include the entire path.
Note
A keyword such as
|authenticator|
must be used in front of a process, otherwise, the entry is ignored by the CipherTrust Manager GUI.Click Apply.
Client users currently logged on to the client must log off and log on again to refresh their user authentication credentials. They can verify the change by logging on to the client, accessing a GuardPoint, and checking the user information in the message logs.
Inheriting Client Settings from a Client Group
To inherit client settings from a client group:
Open the Transparent Encryption application.
Under Client Name, click the desired client.
Click the Client Settings tab.
Select the desired client group from the Inherit Client Setting From drop-down list. This drop-down shows the list of client groups the client is a member of. The drop-down is not available for standalone clients.
Click Apply.
The client now inherits client settings from the selected client group. Refer to Inheritance of Client Group Settings for details on inheritance.
Note
An unregistered client cannot inherit client settings from its client groups.
Re-Sign Settings
If you add another process to the set of trusted applications on the Client Settings tab, enable the Re-sign Settings toggle. This ensures that the new process is signed and authenticated by the client.
Subsequently, when the client settings are pushed to the CTE Agent, the updated settings are re-signed. The Re-sign Settings toggle is turned off (or reset).
To ensure that new processes are signed and authenticated by the client:
Open the Transparent Encryption application.
Click Clients > Clients.
Under Client Name, click the desired client.
Click the Client Settings tab.
In the Settings box, update settings as appropriate.
Turn on the Re-sign Settings toggle.
Click Apply.
Enabling the Re-sign Settings toggle forces a signature update. On subsequent push of the client settings to the CTE Agent, the updated settings are re-signed and the Re-sign Settings toggle is turned off (or reset). If you do not turn on this toggle after adding a new process, the client ignores the newly added process.
Modifying Client Configuration
To modify the client configuration:
Open the Transparent Encryption application.
Click Clients > Clients.
Under Client Name, click the desired client.
Alternatively, click the expand icon () to the left of the desired client in the clients list.
Linux Client
Windows Client
Modify the following, as appropriate:
Live Data Transformation: Enabled or disabled based on the feature selection during registration. By default, LDT performs rekey operations on the LDT protected GuardPoints as soon as GuardPoints are enabled. To pause LDT rekey operations, click the Suspend Live Data Transformation icon (). The icon changes to Resume Live Data Transformation ().
After LDT has been enabled, it cannot be disabled. To remove the feature, you must migrate existing data protected under LDT policies, unregister the client, and delete the client. Then, you can reregister the client without enabling the feature. This allows you reclaim the license for use on another client.
Efficient Storage: Enabled or disabled based on the feature selection during registration.
After efficient storage has been enabled, it cannot be disabled. To remove the feature, you must migrate existing data protected with efficient storage GuardPoints, unregister the client, and delete the client. Then, you can reregister the client without enabling the feature.
Encryption Key Protection: Enable or disable protection of encryption keys stored in the cache memory on the CTE client. The field is available to registered clients only.
When enabled, keys are removed from the cache after three minutes of inactivity and memory is overwritten with random data any time after a key is used.
When keys are cached in memory, they are encrypted in the cache and only decrypted when used. This adds a small overhead but extra security. The in-memory key cache is held in the operating system kernel and is not accessible to any user-space applications. Furthermore, Thales recommends that CTE only be run on operating systems that have been patched to prevent Meltdown and Spectre attacks. Subsequent releases will prevent the CTE agent from running if patches are not in place.
If a kernel crash dump is initiated, any clear-text key information (used to derive keys from encrypted cached key counterparts) is erased from memory before the crash dump is taken.
Cloud Object Storage: (Non-editable, Linux only) Enabled or disabled based on the feature selection during registration. From the GUI, you can neither disable nor enable the Cloud Object Storage feature. To enable or disable it, register the client again and opt or opt out of the Cloud Object Storage feature. Refer to the CTE Agent for Linux Quick Start Guide for details.
File Header Supported (FHS): (Non-editable, Windows only) Enabled or disabled based on the feature selection during Agent installation. When this feature is enabled, you can apply GuardPoints to SMB shares.
After FHS has been enabled, it cannot be disabled from the CipherTrust Manager. To turn off the feature, you must migrate existing data protected under LDT policies, unregister the client, and delete the client. Then, you can reinstall the client with the LDT on CIFS (File Header Support, FHS) capability turned off, and register with the CipherTrust Manager.
Secure Start: (Non-editable, Windows only) Enabled or disabled based on the installed Agent capability. If the Agent supports the Secure Start feature, then this option is enabled, otherwise, the option is disabled.
Multifactor Authentication (MFA): (Windows only) Available based on the installed Agent capability.
If the Agent supports MFA, you can enable or disable the feature. By default, the feature is disabled. To enable MFA on the client, select the Multifactor Authentication check box. To disable, clear the check box.
When enabled, access to the requested data is granted only after the requester satisfies configured authentication criteria. Refer to Multifactor Authentication for details.
If the Agent does not support MFA, the option is disabled and cannot be modified.
In-place Data Transformation - Device: (Non-editable, Linux only) Enabled or disabled based on the installed Agent capability. If the Agent supports the feature, then this option is enabled, otherwise, the option is disabled.
Domain Sharing: Allow or deny sharing the client resources across domains. Refer to Sharing Resources Across Domains for details.
Unlock: Unlock Agent Lock and System Lock.
Agent Lock: Lock the contents of the CTE Agent directories on the client.
System Lock: Apply an internal policy to the client to lock client system directories, like
/var
,/bin
,/etc
. Enabling System Lock automatically enables Agent Lock.Communication Enabled: Whether to enable the client's communication with the CipherTrust Manager. Select to enable, clear to disable communication. By default, the communication is enabled. For manually added unregistered clients, this option is editable if Registration Allowed is selected.
Registration Allowed: (Manually added unregistered clients) Whether to allow client's registration with the CipherTrust Manager. Select to allow, clear to deny registration. By default, the registration is not allowed.
Password Creation Method: Set the password creation method—Manual or Generate. Refer to Changing Client Password for details.
Client Profile: Select a profile for the client. The default profile is DefaultClientProfile. If you did not specify a profile during registration, the client is linked with default profile. To change the client profile, refer to Changing the Profile for details.
Advanced Security Configuration: View or edit the client's security configuration parameters. Refer to Changing Security Configuration Parameters for details.
Details (Read-only): Shows the versions of the platform and kernel installed on the client, for example, RHEL7.8 - 3.10.0-1127.el7.x86_64. For unregistered or manually added clients, a hyphen (
-
) is displayed. For Windows clients, the field is empty.Upgrade On Reboot (Read-only): Displays when the next upgrade of the CTE Agent is scheduled. None is displayed if the upgrade is not scheduled. For unregistered clients, the field remains blank.
Agent Information: Collect and download the Agent information (
agentinfo
) from the CTE Agent.Collect: Informs the CTE client to collect the Agent information and send it back to the CipherTrust Manager. This is the default link.
After the Agent information is successfully received, the link changes to Recollect and Download.
Recollect: Collects the latest Agent information from the CTE Agent.
Download: Downloads the Agent information from the CipherTrust Manager in a tar file. After the download, the Agent information is removed from the CipherTrust Manager. In a CipherTrust Manager cluster, the information will be downloaded from the node where the Agent information is requested.
Refer to Collecting Agent Information for details.
Click Apply.
Changing the Profile
To change the client profile:
Open the Transparent Encryption application.
Under Client Name, click the desired client.
Next to Client Profile, click the profile link (for example,
DefaultClientProfile
). The Select Profile dialog box shows the current client profile and Rekey Option, Rekey Rate, and Schedule of the selected profile.From the Profile drop-down list, select the desired profile.
Click OK. The selected profile is linked successfully.
Changing Security Configuration Parameters
The CipherTrust Manager provides options to modify certain security configuration parameters configured on the CTE client. The list of editable configuration parameters can vary based on the capabilities supported by the CTE Agent installed on the client. Refer to the CTE Agent documentation for compatible versions and dynamic parameters.
To view or change the security configuration parameters:
Open the Transparent Encryption application.
Under Client Name, click the desired client.
Next to Advanced Security Configuration, click the View/Edit Settings link. The Advanced Security Configuration dialog box lists the security configuration parameters that can be updated after the CTE client is registered with the CipherTrust Manager. Every parameter has the fixed set of values.
Note
The PTRACE_PROECTION feature is not applicable to CTE for Windows Agents.
Change the security configuration, as appropriate.
Click Save. The security configuration is changed successfully.