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 Efficient Storage, 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 ESG_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. As shown below, 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 ESG_MOUNTED_FS_POLICY enforces a single rule to block root access to the files under the dir1 subdirectory under the mounted file system GuardPoint. We need to add another security rule to the policy to grant root user access to read the files under dir2 subdirectory under 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 ES GuardPoint device. As explained, the policy ESG_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 ES 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 ES 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 ES 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 Efficient 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 ES GuardPoints. See Linux System Utilities for Signing for the list of utilities that root must be able to execute.

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 ES 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 ES GuardPoint that grants root the right to execute the system utilities in the signature set to access the ES 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 ES GuardPoint.

The resource set ESG_FS_ResourceSet consists of the binary files listed in the next screenshot. Let's walk through the steps to add the security rule to limit root access:

1. Select the system utilities that must be granted access to Efficient Storage devices.

2. Click Add to add a signature set.

3. On the Add Signature Sets page, enter the name of the signature set to create and then click on OK. This creates an empty signature set with the name you have selected for the signature set. The name appears on the Signature Sets page.

4. On the Signature Sets page, click on the name of the signature set to get to the Edit Signature Set page to edit your signature set.

5. On the Edit Signature Set page, click on the Source tab to select the protected host where the file system utilities are located. Click Select to select the protected host.

6. Click Add to add each system utility from the selected host to the signature set. After adding the system utilities to the set, then click Sign to sign the binary files on the selected protected host.

At this point, you have created a signature set consisting of the system utilities that root is allowed to execute on Efficient 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 ES 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. For Policies in the top menu bar, then click on Manage Policies, and then click on Process Sets to get to Process Sets page.

2. Click Add to get to Add Process Set page to add a process set.

3. Enter the name of the process set in the Name entry and then click Add to get to Add Process page.

4. Click Select next to the Signature Set entry to select a signature set. Select the signature set that you just created.

   After clicking Select, you will be on the Select Signature Reference page, and you will see the signature set you just created, for example, the ESG_FS_Utilities signature set. Click on the Select button to the left of the signature set and then click on Select Signature Reference. You will go back to Add Process page with the selected signature set name entered in Signature Set box.

5. Click Select next to the Host entry to select the protected host the process set. On the Select a Host to Continue page, select the protected host and then click on Select.

6. On the Add Process Set page, click OK to create the process set associated with the selected signature set and the protected host.

7. You have selected the signature set and the protected host. Skip Directory and File entries, and then click OK to go back to Add Process Set.

8. Edit the policy protecting ES 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 ES GuardPoints. This rule prevents any privileged user from reading or dumping the content of an ES GuardPoint.

After adding the security rule, the policy protecting ES GuardPoints will be the same policy as ESG_DEMO_POLICY_2.

After applying the revised policy over the ES GuardPoint, root can no longer dump the contents of the device.