Implementation Differences Between Linux and Windows

Linux and Windows allow different types of access controls. The following topic summarizes the differences in how access controls behave on these two platforms.

Access Control Rule Types

Windows supports two types of access control rules. One determines who can access the files on the disk, and the other determines who can access the data blocks on the disk. Windows allows you to have one permission list for each rule type, so users who have filesystem-level access may not have block-level access and vice versa.

Linux only supports one type of access control rule, and that rule determines who can have access to the both the files and the data blocks on the disk.

For details, see Access Control Rule Types.

Remote Users and User Groups

For Windows, you can include remote users and groups from Active Directory (AD) as well as local users and groups defined on the Windows VM. Because you can include groups, Windows also allows you to specify to whom access should be denied as well as to whom it should be granted.

For example, you could allow access to the group development-all but deny access to the sub-group development-interns. Permission conflicts are resolved using the order of precedence defined in the rule. For details, see Windows Access Control Rule Processing and Windows Access Control Rule Recommendations and Considerations.

For Linux, you can only include local user accounts in the permissions list. Local groups or remote users and groups are not supported. Therefore, the permission list for an Access Control Policy is a simple whitelist of local user accounts that can access the files and data blocks on the associated disks.

Access Control Policy Application and Re-Verification

If a Windows Access Control Policy contains invalid local user accounts when the Policy Agent verifies the Access Control Policy, the Policy Agent raises an alert and does one of the following:

• If this is the first time a policy is being associated with the disk, or if the Windows VM has just rebooted, the Policy Agent does not apply any access controls to the disk.

  Note:

  During policy validation, the Policy Agent ignores non-existent Active Directory accounts. It only disables access controls if there are invalid local accounts.

• If the Policy Agent is verifying a new version of the policy that it received from KeyControl, the Policy Agent does not apply the new version. Instead, it continues to use the previous version of the policy until the VM reboots. On reboot, the application of the policy is always all-or-nothing. If the current version of the policy contains invalid local accounts on reboot, the Policy Agent always disables all access controls, even if a previous version of the policy exists.

If a Linux Access Control Policy contains invalid local user accounts when the Policy Agent verifies the Access Control Policy, the Policy Agent raises an alert. If this is the first time a policy is being associated with the disk, the Policy Agent does not apply any access controls to the disk. If a previous version of the policy has been successfully verified for the disk, the Policy Agent uses that version of the policy. The Policy Agent only verifies the permissions list when an Access Control Policy is first associated with the VM or when changes to the Access Control Policy are communicated to the VM from KeyControl. The Policy Agent does not re-verify the permissions list when the Linux VM reboots.

Associating Access Control Policies with Multiple Disks on a VM

Windows allows you to associate different Access Control Policies with different disks on the same VM. You can also remove an Access Control Policy from one disk without affecting any of the other disks on the VM.

Linux requires you to use the same Access Control Policy for all disks on the same VM. In addition, if you remove the Access Control Policy from one disk, the Policy Agent removes it from all disks on the VM.