Challenges with Root Access on Linux

As demonstrated in the example in use case 3, data is protected at two levels using two separate policies and GuardPoints. The data is encrypted at the device level through the policy on the device guarded as in-Place Data Transformation, and user access controls are enforced at the file system level through the policy on the mount point directory. Splitting the full protection through separate GuardPoints poses new challenges with respect to root privilege on Linux.

With the GuardPoint on the file system mount point enabled, the access rule(s) denying root access is enforced. However, when the GuardPoint on the file system mount point is disabled, root gains full access to the files in the file system. As shown below, the file holding secret information and protected against root is exposed as soon as the GuardPoint on file system mount point is disabled.

The next two sections describe the challenges with root access and solutions to overcome these challenges.

Challenge 1 - Deny root access to the files in mounted Linux file system

As the above example shows, the policy IDT_MOUNTED_FS_POLICY denies the root user access to the files associated with the resource set dir1. Enforcement of the rule become ineffective as soon as the GuardPoint on the file system mount point is disabled. Since data is in clear-text at the file system level, root would gain access to clear-text in the files associated with the resource set, which includes files with sensitive information.

The solution to this problem is to force the file system to unmount when the GuardPoint on the file system mount point is disabled. Basically, the file system is guarded/enabled immediately when the file system mounts, and the file system is unmounted as soon as the GuardPoint is disabled. To enforce this, the GuardPoint on the file system mount point directory must be guarded with Auto Mount option checked on the CipherTrust Manager. With this option, CTE immediately guards the mount point directory as soon as the file system mounts, and similarly, CTE disables the GuardPoint before unmounting the file system. The file system mount point is guarded with Auto Mount option checked.

This solution imposes one policy protecting the entire file system namespace. Enforcement of a single policy over entire file system namespace may seem restrictive if you wish to impose different sets of access rules to different directories within the file system name. Basically, your option of enforcing one policy with a set of specific access rules for guarding a specific directory within the mounted file system namespace is not possible with this solution. Instead, you have to create a resource set for each directory, which you would have guarded, and specify the desired access rules specific to the directory through association of the rule with the resource set. Let's see the effect of auto-mount on root user attempts to view files that root users are not allowed to read. As shown below, the GuardPoint /xfs is automatically mounted as soon as the file system mounts, and the file system unmounts as soon as the GuardPoint is disabled, hence there is no opportunity for root, or any other privileged user, to read the protected files.

As depicted above, the policy IDT_MOUNTED_FS_POLICY enforces a single rule to block root access to the files under the dir1 subdirectory under the mounted file system GuardPoint. You need to add another security rule to the policy to grant root user access to read the files under dir2 subdirectory in the guarded file system mount point. Note that dir1 and dir2 may have been guarded separately under different policies.

Challenge 2 - Deny root access to view sensitive data in protected Linux files

Another challenge with root user privilege is that root can still view sensitive information stored in the in-Place Data Transformation GuardPoint device. As explained, the policy IDT_MOUNTED_FS_POLICY denies root access to the read/writes files under /xfs/dir1. Although this policy enforces the rule on the Directory GuardPoint /xfs, the rule is not enforced if the root user dumps the content of the in-Place Data Transformation GuardPoint. As the example below shows, the root user can view sensitive information in the protected files under /xfs/dir1.

To block the root user from dumping context of the device, the policy on the in-Place Data Transformation GuardPoint must enforce a security rule that denies root access to the GuardPoint device. However, denying root access to GuardPoint devices is not feasible because file system utilities require root access for file system administration. Rather than enforcing complete denial of root access, you can impose a restriction that allows only a limited set of system utilities to access in-Place Data Transformation GuardPoints, such as mount, fsck, mkfs, dmsetup, etc., and deny access to other utilities, such as dd.

The solution is to restrict root to execute a limited set of utilities, which do not expose content of the file system devices, on in-Place Data Transformation Storage Devices. If the root user attempts to execute other utilities on the device, the root user will be denied access. You can impose this restriction by selecting the administrative utilities that root must execute on in-Place Data Transformation GuardPoints. The following contains the the list of utilities that root must be able to execute:

The following table includes recommendations on the system and file system specific utilities for inclusion in the signature set to allow or deny root execution.

To implement this solution, you can create a signature set on your CipherTrust Manager and add the system utilities that root is permitted to execute on in-Place Data Transformation GuardPoints. Those utilities can be added to the signature set for signing. After signing the binary files of those system utilities, you can add a security rule to the policy on the in-Place Data Transformation GuardPoint that grants root the right to execute the system utilities in the signature set to access the in-Place Data Transformation GuardPoint. In the above example, since dd is not in the signature set, the dd command is denied access to read the file system device guarded as an in-Place Data Transformation GuardPoint.

The resource set ESG_FS_ResourceSet consists of the binary files listed in the next screenshot. Following are the steps to add the security rule to limit root access:

1. Select the system utilities that must be granted access to in-Place Data Transformation Storage devices.

2. In the Policy Elements, click Signature Set > Create Signature Set to add a signature set.

3. On the Create Signature Sets page, enter the name of the signature set to create and then click Next.

4. Click Add Source to select the protected client where the file system utilities are located. Click Apply to display the available sources.

5. Click on a drive and Add Source to add each system utility from the selected client to the signature set. After adding the system utilities to the set, then click Add.

6. Click Next to review the system utilities added the signature set.

7. Click Save to sign the binary files on the selected protected Client.

At this point, you have created a signature set consisting of the system utilities that root is allowed to execute on in-Place Data Transformation storage devices. Next, create a process set from the signature set. The process set will be included in a security rule in the policy protecting the in-Place Data Transformation GuardPoint. The security rule will allow root, or other privileged users, to access the device only through the system utilities in the signature set. Continue with the following steps:

1. In the Policy Elements, click on Process Sets.

2. Click Create Process Set to add a process set.

3. Enter the name of the process set in the Name entry and then click Next.

4. Click Create Process.

5. Select the signature set that you just created and click Add and go back to Create Process to add the Signature Set to the Process set.

6. Click Add on the Add Process Set page.

7. Click Next and Save to create the process set associated with the selected signature set and the protected client.

8. Edit the policy protecting in-Place Data Transformation GuardPoints to add a security rule. In the following figure, the process set that you just created is included in the security rule. The rule allows only the processes listed in the process set to access the in-Place Data Transformation GuardPoints. This rule prevents any privileged user from reading or dumping the content of an in-Place Data Transformation GuardPoint.

After adding the security rule, the policy protecting in-Place Data Transformation GuardPoints will be the same policy as IDT_DEMO_POLICY_2.

After applying the revised policy over the in-Place Data Transformation GuardPoint, root can no longer dump the contents of the device.