Access

An access policy defines which user, group, and process can access protected content, their read/write permissions, and whether they can view ciphertext or plaintext. Users, groups, and processes are referred to as "entities" in this document. An access policy can be created for individual entities or combination of "user and process" and "group and process".

Specific entities can be allowed to read and write plaintext while others can only be allowed to read plaintext. For example, users responsible for creating backups can be allowed to read ciphertext only. Similarly, users responsible for creating and restoring backups can be allowed to read and write ciphertext only.

Access policies operate as additional control on top of operating system’s access permissions. CTE UserSpace’s access policies can only limit or control the "allow" permissions, not the "deny" permissions. For example, if User1 is granted the read and write access to File1, CTE UserSpace can limit the access to read only. Similarly, if User1 does not have any access to File2, CTE UserSpace cannot modify the user’s access permissions to this file.

Access Priority

CTE UserSpace enforces access policies in order of their priority in the access policy group, that is, from top to bottom.

An individual process takes higher priority than a user or a group. However, when a policy has a combination of user, group, and process, then the priority order is "user/group & process," process, and user/group.

Priority is automatically assigned to entities, as described below:

• User/Group and Process – When a policy has a combination of user, group, and process, then the priority order is "user/group and process," process, and user/group.

  For example, a policy for the combination of User A and Process A is granted the highest priority than individual priorities of Process A, User A, and Group A.

  Consider access policies for the following are added to an access policy group:

  • User A and Process A

  • User A

  • Process A

  In this case, the order of access priority is:

  1. User A and Process A – This access policy gets the highest priority.

  2. Process A – This access policy gets the second highest priority; lower than combination of User A and Process A but higher than individual User A (listed lower in priority order).

  3. User A – This access policy gets the third highest priority; lower than combination of User A and Process A and individual Process A.

  4. Default – This access policy is always the lowest in priority.

  Similarly, if access policies for the following are added to an access policy group:

  • Group A and Process A

  • Group A

  • Process A

  In this case, the order of access priority is:

  1. Group A and Process A – This access policy gets the highest priority.

  2. Process A – This access policy gets the second highest priority; lower than combination of Group A and Process A but higher than individual Group A (listed lower in access priority list).

  3. Group A – This access policy gets the third highest priority; lower than combination of Group A and Process A and individual Process A.

  4. Default – This access policy is always the lowest in priority.

• Processes – Individual processes take higher priority than individual users and processes in an access policy group. However, they take lower priority than a combination of "user/group and process." Therefore, they appear above users and groups, but below combination of "user/group and process" in an access policy group.

  In case of multiple processes, priority is granted in the order they are added to the access policy group. For example, if Process A is added to the access policy group before Process B, then Process A is granted higher priority than Process B, or vice-versa. Similarly, a child process can be granted higher or lower priority than its parent process, as appropriate.

  CTE UserSpace enforces access policy on a process (whether parent or its child) that is added first to the access policy group. Therefore, it is recommended to add access policies in the order of their priority according to security requirements.

  Note

  When a parent process is assigned higher priority than its child processes, the child processes inherit the access policy of the parent process. However, when a child process is assigned higher priority than its parent process, the access policy assigned to the child process takes priority. Refer to Process Inheritance for details.

  Note

  To access the link to a process, ensure that both the process and the link to it are in the access policy group. Accessing the process executable directly through its link is not supported. Therefore, paths to the link and the actual process executable must be added separately to the access policy group.

• Users/Groups – Users/groups take lower priority than processes and combination of "user/group and process." Access priority is granted to users/groups in the order they are added to the access policy group. For example, if User A is added before User B, then User A takes higher priority than User B, or vice-versa. Similarly, a user can be granted higher or lower priority than its group, or any other group, as appropriate.

  For example, to grant a group one type of access but allow one member (user) of the group a higher level of access, add access policy for the user individually before adding access policy for its group.

  CTE UserSpace enforces access policy on a user or group that is added first to the access policy group. Therefore, it is recommended to add access policies in the order of their priority according to security requirements.

Access Policy Group

An access policy group is a logical grouping of access policies of the same type. The access policy group is used when associating an encryption rule with a client to enforce access control.

A new access policy group has a default access setting. The default setting applies access permissions to entities that do not have specific permissions assigned. Access policies can be associated and removed from an access policy group.

Group Type

CTE UserSpace supports the Access Control & Encryption group type. This type of group can be associated with rules performing data encryption. Therefore, access policies having ReadWriteCipher and ReadWrite permissions can be part of this group. Refer to Permissions for Access Control & Encryption for details.

Permissions for Access Control & Encryption

Permissions for Access Control & Encryption are:

• NoAccess – Denies access to a protected file or directory. A Permission denied error message is returned when an entity tries to access the protected path. This is the highest security level.

  Note

  Setting Default Access to NoAccess provides the highest security. It assures that entities not specifically associated with the policy cannot access files and directories where the linked encryption rule is applied.

• ReadWrite – Grants permissions to read and write/modify an encrypted file and to create a new file in a protected directory.

• Read – Grants permissions to read but not to write/modify an encrypted file.

• ReadWriteCipher – Grants permissions to read and write the protected data in ciphertext only. No access is granted to the plaintext data. No encryption or decryption happens with this access permission. This access should be reserved for entities that create and restore backups of protected data.

  Note

  For tools that take backup from the volume/disk, for example, Acronis 11.5 and Symantec Backup Exec 2014, the restore must happen through the ReadWriteCipher entities only.

• ReadCipher – Grants permissions to read the protected data in ciphertext only. No access is granted to write/modify ciphertext. This access should be reserved for entities to take a backup of protected files, but not to restore a backup.

  Note

  Entities with ReadCipher or ReadWriteCipher permissions should only access the encrypted files using programs intended for creating and restoring encrypted server backups.

• Write – Grants permissions to write/modify an encrypted file and create a new file in a protected directory, but not to read that file.

Managing Access Policy Groups

CTE UserSpace provides options to create new, view existing access policy groups, view their details, update their names, and delete them when they are no longer required. Also, you can view the list of access policies linked to a group, link an access policy to a group, and remove an access policy from a group.

Creating an Access Policy Group

To create an access policy group:

1. Open the ProtectFile & Transparent Encryption UserSpace application.

2. In the left pane, click Access Policies.

3. Under the Access Policy Groups section, click New Access Policy Group. You might need to scroll down the page.

4. On the New Access Policy Group section, specify the following details:

   Parameter	Description
   Name	Name for the access policy group. This field is mandatory.
   OS Type	Applicable operating system. Specify Linux for CTE UserSpace. The default operating system is Windows.
   Group Type	Specify whether the access policy group will allow ciphertext permissions. The options are: • Access Control & Encryption: Allows ReadWriteCipher or ReadCipher access policies to be part of the group. This is the default setting. • Access Control Only: (Not applicable to CTE UserSpace) CTE UserSpace does not support the Access Control Only policy groups.
   Default Access	Default access permission for the access policy group. This access will be granted if an entity's access request does not match any access policy in the access policy group. The valid values are: • ReadWrite • Write • Read • ReadWriteCipher • ReadCipher • NoAccess Refer to Permissions for Access Control & Encryption for details.

5. Click Create.

The newly created access policy group is displayed in the list.

Viewing Access Policy Groups

View the list of existing access policies and their details on the Access Policy Groups section. Filter access policy groups based on characters in name, OS type, and group type ("Access Control & Encryption" or "Access Control Only").

To view existing access policy groups:

1. Open the ProtectFile & Transparent Encryption UserSpace application.

2. In the left pane, click Access Policies. The Access Policy Groups section displays the existing access policy groups. The following details are displayed:

   Parameter	Description
   Name	Name of the access policy group.
   OS Type	Applicable operating system, Linux for CTE UserSpace.
   Group Type	Access Control & Encryption is displayed for the group allows ciphertext permissions. CTE UserSpace does not support the Access Control Only policy groups.
   Default Access	Default access permission for the access policy group. This access will be granted if an entity's access request does not match any access policy in the access policy group. The default access can be: • ReadWrite • Write • Read • ReadWriteCipher • ReadCipher • NoAccess Refer to Permissions for Access Control & Encryption for details.

Modifying Access Policy Groups

After an access policy group is created, you can only modify the default access permission for the access policy group.

To modify an existing access policy group:

1. Open the ProtectFile & Transparent Encryption UserSpace application.

2. In the left pane, click Access Policies.

3. Under the Access Policy Groups section, click the overflow icon () corresponding to the group you want to modify.

4. Click Edit.

5. Select the desired Default Access. The default access can be:

   • ReadWrite

   • Write

   • Read

   • ReadWriteCipher

   • ReadCipher

   • NoAccess

   Refer to Permissions for Access Control & Encryption for details.

6. Click Save.

The access policy group is changed. You can link additional access policies to the group later (refer to Linking an Access Policy to a Group for details.)

Access Policy and Group Association

Access policies for individual entities on a particular path can be created and associated to an access policy group. This access policy group is used when creating a client-rule association to provide required access control.

CTE UserSpace provides options to view the list of access policies linked to a group, link an access policy to a group, and remove an access policy from a group.

Linking an Access Policy to a Group

To associate an access policy to a group:

1. Open the ProtectFile & Transparent Encryption UserSpace application.

2. In the left pane, click Access Policies.

3. In the Access Policy Groups section, click the Name link of the desired group. The "Access Policy Groups > <access-policy-group>" section is displayed. The existing access permission and policies (if any) are displayed.

4. Under the Access Policies section, click the overflow icon () corresponding to the policy to link to the group.

   If no access policy exists, create a new access policy by clicking New Access Policy. Refer to Creating an Access Policy for details.

5. Click Add to Group.

The selected access policy is now associated with the access policy group. The "Access Policy Groups > <access-policy-group>" section now shows the newly associated access policy.

Removing an Access Policy from a Group

To remove an access policy from a group:

1. Open the ProtectFile & Transparent Encryption UserSpace application.

2. In the left pane, click Access Policies.

3. In the Access Policy Groups section, click the Name link of the desired group. The "Access Policy Groups > <access-policy-group>" section is displayed. The existing access permission and policies (if any) are displayed.

4. In the "Access Policy Groups > <access-policy-group>" section, click the overflow icon () corresponding to the access policy you want to remove from the group.

   Note

   The default access policy cannot be removed.

5. Click Delete. A dialog box is displayed prompting you to confirm the action. Deletion of an access policy is permanent and cannot be undone.

6. Click Delete. To cancel the deletion, click Cancel.

The selected access policy is removed from the access policy group.

Deleting Access Policy Groups

To delete an existing access policy group:

1. Open the ProtectFile & Transparent Encryption UserSpace application.

2. In the left pane, click Access Policies.

3. Under the Access Policy Groups section, click the overflow icon () corresponding to the group you want to delete.

4. Click Delete. A dialog box is displayed prompting you to confirm the action. Deletion of an access policy group is permanent and cannot be undone.

5. Click Delete. To cancel the deletion, click Cancel.

The deleted access policy group is removed from the list.

Managing Access Policies

CTE UserSpace provides options to create new access policies, view exiting policies, view their details, and modify and delete them when they are no longer required.

Creating an Access Policy

An access policy is used to manage entities' access to a protected path. At least one entity or a valid combination of entities (for example, "user/group and process") is required to create an access policy.

After an access policy is created, you can link it to an access policy group.

To create an access policy:

1. Open the ProtectFile & Transparent Encryption UserSpace application.

2. In the left pane, click Access Policies.

3. Under the Access Policies section, click New Access Policy. You might need to scroll down the page.

4. On the New Access Policy section, specify the following details:

   Parameter	Description
   Access	Access permission for the policy. This access permission will be granted to individual entities (or their combination) added to this policy. The valid values are: • ReadWrite • Write • Read • ReadWriteCipher • ReadCipher • NoAccess The default access is NoAccess. Refer to Permissions for Access Control & Encryption for details.
   Name	Name for the access policy. If not specified, the policy will be automatically named as "Access-Policy-XXXX", where XXXX is a random string of 19 characters.
   User Name	Name of the user to add to the policy. If the user is a domain user, specify domain name with the user name; for example, user@domain.com.
   Group Name	Name of the group of users to add to the policy. If group is a domain group, specify domain name with the group name; for example, group@domain.com.
   Process Name	Name of the process to add to the policy. For example, /path/to/process.

   Note

   Either User Name or Group Name can be specified, not both at once.

5. Click Create.

The newly created access policy appears in the list.

Viewing Access Policies

View the list of existing access policies and their details on the Access Policies section. Filter access policy groups based on characters in access, user name, and group name.

To view existing access policies:

1. Open the ProtectFile & Transparent Encryption UserSpace application.

2. In the left pane, click Access Policies. Scroll down the page. The Access Policies section displays the existing access policies. The following details are displayed:

   Parameter	Description
   Name	Name of the access policy.
   Access	Access permission for the policy. This access permission will be granted to individual entities (or their combination) added to this policy. The valid values are: • ReadWrite • Write • Read • ReadWriteCipher • ReadCipher • NoAccess The default access is NoAccess. Refer to Permissions for Access Control & Encryption for details.
   User Name	Name of the user added to the policy.
   Group Name	Name of the group of users added to the policy.
   Process Name	Name of the process added to the policy. Refer to Access Policies for Processes for details.

Modifying Access Policies

After an access policy is created, you can edit the name of the user/group and process and change the access permission for the access policy.

To modify an existing access policy:

1. Open the ProtectFile & Transparent Encryption UserSpace application.

2. In the left pane, click Access Policies.

3. Under the Access Policies section, click the overflow icon () corresponding to the policy you want to modify.

4. Click Edit.

5. Edit the required details, as appropriate.

   • Access: Select the desired access. The access can be:

     • ReadWrite

     • Write

     • Read

     • ReadWriteCipher

     • ReadCipher

     • NoAccess

     Refer to Permissions for Access Control & Encryption for details.

   • User Name: Name of the user to add to the policy. If the user is a domain user, specify domain name with the user name; for example, user@domain.com. When editing a user name, the Group Name field is not displayed.

   • Group Name: Name of the group of users to add to the policy. If the group is a domain group, specify domain name with the group name; for example, group@domain.com. When editing a group name, the User Name field is not displayed.

   • Process Name: Name of the process to add to the policy. For example, /path/to/process.

6. Click Save.

The access policy is modified.

Access Policies for Processes

Access permissions can be granted to processes irrespective of the users running them. It ensures that unnecessary access permission is not granted to any user and the targeted access can be provided to a process. The process can access the protected path according to its access permissions even if the user running it does not have such permissions.

Process Inheritance

Access permissions for child processes are inherited from the access policies of their parent processes. Access policies can be defined for parent/child processes in the following scenarios:

• Only Parent Process is Assigned Policy

• Parent Process is Assigned Higher Priority

• Child Process is Assigned Higher Priority

Only Parent Process is Assigned Policy

Access policy is assigned for the parent process only.

For example, the process PostgreSQL startup script (/etc/init.d/postgresql) uses commands/processes such as chown, touch, and cat. Here, the script /etc/init.d/postgresql the parent process and chown, touch, and cat are its child processes.

The /etc/init.d/postgresql script is assigned the ReadWrite access on a protected path. All the commands/processes invoked by this script will gain the ReadWrite access on the protected path. When invoked from outside the /etc/init.d/postgresql script, these commands/processes would not gain the same access to the path.

Similarly, if the /etc/init.d/postgresql script is assigned the NoAccess on a path, then the commands/processes invoked by the script cannot access the protected path.

Parent Process is Assigned Higher Priority

Access policy is defined individually for a parent process and its child processes. The parent process is assigned higher priority than its child processes.

CTE UserSpace enforces policies in the order of their priority (from top to bottom) in the list of access policies. So in this case, the access policy of the parent process will be enforced on its child processes.

For example, the parent process, /opt/abc.h, is assigned the highest priority with ReadWrite access. Its child processes, /bin/ls and bin/cat, are individually assigned the NoAccess.

In this example, although the child processes are assigned individual access policies, they will inherit access policies of their parent process. The ReadWrite access will be enforced to them.

Child Process is Assigned Higher Priority

Access policy is defined individually for a parent process and its child processes. A child process is assigned higher priority than its parent process.

CTE UserSpace enforces policies in the order of their priority (from top to bottom) in the list of access policies. So in this case, the child process will be enforced its own access policy; it will not inherit access policy from its parent process.

For example, the child process, /bin/ls, is assigned the highest priority with NoAccess. Its parent process, opt/abc.h, is assigned the ReadWrite access. And another child process, /bin/cat, is assigned the NoAccess.

In this example, the child process, /bin/ls, having the highest priority, will be enforced its own access policy, NoAccess. It will not inherit its parent’s ReadWrite access. However, the other child process, /bin/cat, despite having assigned the NoAccess, will inherit its parent’s ReadWrite access.