Access Control Requirements and Considerations

Platform Requirements

Platform	Supported Versions
Linux	RHEL/CentOS 7 and above.
Windows	All Windows platforms supported by DataControl. For a complete list, see Supported Platforms.

General Requirements and Considerations

You can only associate an Access Control Policy with a data disk encrypted by HyTrust DataControl.

You cannot associate a policy with an unencrypted data disk, a data disk encrypted by some application other than DataControl, or with a boot disk (even if the boot disk is encrypted by DataControl).
If a disk is associated with an Access Control Policy, system administrators can still perform basic disk management functions such as creating mount points or adding, expanding, or shrinking partitions. They cannot, however, decrypt the disk until the Access Control Policy is removed.
If you want to protect a disk that is accessed by Application Services (such as a web server), make sure that all Application Services and Programs run under specific user accounts that can be added to the permissions list.

Linux-Only Requirements and Considerations

With Linux, you can only create one Access Control Rule per policy that provides a "whitelist" of local VM user accounts that can access both the files and blocks on the disk. There is no way to grant file accesses but deny block access to a particular user, nor is there a way to grant access to a domain-qualified user name.
If you want to use an Access Control Policy on a Linux VM, you need to install three SELinux packages and a HyTrust-supplied rpm package. For details, see Enabling Access Controls on a Linux VM.

Due to security concerns, you cannot enable an Access Control Policy on a VM if there are any custom SELinux configuration settings or modules. If the Policy Agent finds any such customizations, the policy association will fail.

Important:

After you associate an Access Control Policy with a Linux VM, make sure you do not customize any SELinux configuration settings or modules. If you do so, the interaction between the SELinux customizations and the access controls could cause data loss.

In addition, if the Policy Agent determines that any HyTrust SELinux policies have been removed or that SELinux has been disabled or tampered with in any way (as could be done with a custom SELinux policy), the Policy Agent prevents the disk from being attached and access to the data will be lost.

The hcld daemon must be run by the root user.
If you enable both an Access Control Policy and Online Encryption (using the HTCrypt Driver) on the same Linux VM, the online encryption will fail. Make sure that the HTCrypt Driver is not installed on the VM before you associate an Access Control Policy with the VM.

You can see the status of the HTCrypt Driver by entering the hcl status command on the VM. For more details about Online Encryption, see Linux Online Encryption Prerequisites and Considerations.
One of the supported Linux filesystems must already exist on the disk before you can associate it with an Access Control Policy. For a list of supported filesystems, see Supported Platforms.
You can associate one and only one Access Control Policy with one or more data disks on a specific VM. Linux does not support using different Access Control Policies for different disks on the same VM.
Once the Policy Agent has enabled access controls on a disk, users on that disk will be operating in a custom SELinux environment that restricts certain actions. For example, users cannot switch users (su), run sudo commands, or access some of the root files or directories, such as the logs in /var/log.

In addition, users with root privileges are blocked from performing operations such as file system checks or data backup for any access controlled disks on the VM.
If you apply an Access Control Policy for the first time while users are actively using the disk, all of the logged in users will immediately lose access to the disk even if they are included in the permissions list. Allowed users must log out and log back in before they can continue accessing the files and data blocks on the disk.

If you apply a valid update an existing Access Control Policy, the Policy Agent verifies that all active users are still included in the permissions list. If they are, those users can continue to access the disk as normal. If any currently-active users have been removed from the permissions list, the Policy Agent automatically logs them out as soon as it validates the new version of the Access Control Policy.

In either case, if the Access Control Policy contains invalid users, the Policy Agent does not apply that version and it does not do any validation on the currently-active users. This means that, if there is a currently-active user that you want to block from accessing the disk, the version of the Access Control Policy you apply must be valid before the Policy Agent will log off the now-unauthorzied user.
If you want to move a disk to another registered VM in the same Cloud VM Set, you must first remove the Access Control Policy from the Linux disk before you move it. Access Control Policies do not move with the Linux disk.
If you import a disk into a VM that is already associated with an Access Control Policy, the Access Control Policy is not automatically associated with the new disk. You must explicitly associate the Access Control Policy with the imported disk.
If the Linux VM has multiple disks protected by the Access Control Policy, you cannot remove the Access Control Policy from only one of those disks. Policy removal is an all-or-nothing operation, so if you remove the Access Control Policy from one disk, the Policy Agent removes it from all disks and reboots the VM. You must then re-associate the policy with the disks that you want to protect.
The VM must support the creation of local user accounts, as some access control functions require a temporary local user account created (and then deleted) by the Policy Agent on an as-needed basis.

Password-based SSH login must be enabled on the VM if you want to add, change, or remove an Access Control Policy because setting and enforcing SELinux policies requires SSH login as a HyTrust-admin. These activities cannot be performed by the superuser. After the policy has been successfully associated, you can choose to disable the password-based SSH login access until such time as you need to associate the policy with a different disk or you want to change or remove the existing policy.

If you attempt to add, change, or remove an Access Control Policy and password-based SSH login is not enabled, the attempt will fail and the following message will be displayed in the KeyControl Audit Log:

Error enforcing policy <policy name>, version <version no> on VM <vmname>. Check if password-based SSH login is enabled on the VM.

Note:

Password-based SSH login is enabled by default for most Linux systems, but it is disabled by default for VMs in an Amazon Web Services (AWS) or Microsoft Azure environment. For details about enabling it for those VMs, see your AWS or Azure documentation.

If you want to remove the VM from KeyControl, make sure that you first remove the Access Control Policy associated with VM by following the procedure described in Removing Access Controls from a Disk. This procedure also removes the HyTrust SELinux customizations from the VM. If you remove the VM from KeyControl without following this procedure, you may encounter issues accessing the data on the disk or with normal VM behavior because of these SELinux customizations. For this reason, the hcl unregister command will fail if there is an Access Control Policy associated with the disk.
If you want to back up your KeyControl configuration, you must first remove any Linux Access Control Policies applied to your Linux disks. If you create the backup with any Linux Access Control Policies still active, you may be unable to access those VMs when you restore your KeyControl configuration from the backup file.

Windows-Only Requirements and Considerations

With Windows, you can protect the disk at the folder level, the file level, the data block level, or any combination of the three. Each type of protection has a separate rule in the policy with a separate permissions list. Each permissions list can contain users and groups that are either local to the VM or defined in Active Directory (AD). You can grant access to some users or groups while denying access to others so that you can grant access to an entire group but then deny access to selected members within the group. For details, see Windows Access Control Rule Processing and Windows Access Control Rule Recommendations and Considerations.
Due to security issues that can arise when using local accounts, we recommend that you only add users and groups from Active Directory. If a System Administrator removes a local account that has been included in the permissions list for an Access Control Policy and reboots the VM, the Policy Agent disables access controls but leaves the encrypted disk attached. This cannot happen if all users and groups in the permissions list come from AD, because the Policy Agent ignores non-existent AD accounts during policy verification and applies the rest of the Access Control Policy to the disk.
Windows System Administrators can still use most Windows Disk Management Tools on access controlled disks to perform basic disk management functions such as managing partitions, creating shadow volumes, and monitoring disk performance. However, they cannot:
- Check for or fix the errors on a disk by any means other than chkdsk.exe. Error checking is blocked for the Windows Disk Manager and the Windows Explorer Tools UI.
- Format a volume with Windows Explorer. Instead, System Administrators need to format volumes with Windows Disk Manager, the diskpart CLI command, or format.com.

If the data on the Windows disk is accessed by Windows Services, you need to add the Windows Service Accounts or the SYSTEM account under which the Services are running to the Access Control Policy permissions list. If you add SYSTEM, be aware that System Administrators will be able to run programs under the SYSTEM account.

This is especially important for Active Directory disks, because AD will not boot if it cannot access the data through the SYSTEM account. For other applications, check the appropriate documentation to see if the program can run under a specific user account instead of using SYSTEM.

Note:

Most antivirus programs require that scheduled antivirus scans run under the SYSTEM account. This means that scheduled scans will be blocked on a disk protected by an Access Control Policy that dos not allow Chaccess to SYSTEM. However, when an authorized user accesses a file on the protected disk, the on-access antivirus scan will work for most antivirus software, as that scan does not run under SYSTEM.

An Access Control Policy is associated with a Windows disk, not a VM. You can associate different Access Control Policies with different disks on the same VM. If any of the disks are moved from one VM to another, the associated Access Control Policy goes with the disk.

The only caveat to this is if the disk was originally imported from another VM before the Access Control Policy was applied to it. In this case, if you move the disk back to the original VM after applying an Access Control Policy, the Access Control Policy does not move with the disk.
If an unauthorized user attempts to access a protected disk, the Policy Agent adds an entry to the KeyControl Audit Log. The log message specifies the file that the user tried to access, the login account associated with the request, the process name that made the request, and the name of the Access Control Rule that blocked the request.
When you apply a valid Access Control Policy version to a disk while users are actively using that disk, the access controls take effect immediately. Active users who have Allow permissions will be able to continue accessing the disk as normal. Active users who are not listed in the permissions list or who have Deny permissions will immediately lose access to the files and data blocks on the disk.