Use Case 4: Using CTE-IDT with LVM
Security rules for access control enforcement on I/O operations are based on the context of real users and/or processes requesting the I/O operations. For IDT devices, security rules are checked and enforced at the CTE secvm layer. If the context of the real user or process that requested the I/O operation is not available at the secvm layer, then the enforcement of access rules is invalid and may have unpredictable results and potentially cause system failures.
The previous use cases have described environments where CTE can get the context of the real users or processes requesting I/O operations at the secvm layer and can properly enforce the access rules in those environments. For example, as described in Use Case 3: Directory-Level GuardPoints, CTE can detect when an IDT device is mounted with a file system and it can apply the access rules in the policy on the IDT device without enforcing the rules on I/O operations from the file system layer.
However, there are other environments where CTE cannot determine how the IDT device is actually used and whether a real user or process context is available at the secvm layer. In these environments, CTE cannot properly enforce the access control rules on the IDT device. An example of such an environment is Linux LVM (Logical Volume Manager). A physical device under LVM control is a shared storage resource that can be fully or partially allocated to a logical volume. Adding an IDT device as a physical device to LVM is fully supported for data encryption but not for access control enforcement. In this case, access rules cannot be enforced because when the logical volume with file system is mounted, the mount operation is on the logical volume, not the IDT device. Consequently, CTE cannot determine that the IDT device is part of mounted file system, and therefore, it cannot get the real user or process context for applying access rules.
In order to use CTE in an environment like LVM, the CTE system administrator needs to explicitly tell CTE whether or not it should enforce the access rules for I/O operations on the device when they initialize the device using the voradmin idt config command. As described in Initialize a New Linux Device, this initialization must be done before the device is guarded as an in-Place Data Transformation GuardPoint for the first time.
In addition, for LVM specifically, the device must be a new device with no existing data. Existing LVM disks cannot be used with CTE unless CTE can get the proper context at the secvm layer.
When you initialize the new device, use the voradmin idt config –noacc new [-c <n>] <device-name> command where:
-
-noacc(required) tells CTE to disable access control rules on this device at thesecvmlayer level. -
new(required) indicates that the device contains no data (it is a new disk). -
<device-name>(required). Specifies the device name. For example,/dev/sdh.
For example, if you want to initialize a new LVM Linux disk named /dev/sdh, type:
Caution
When you use -noacc, CTE will not perform any access checks on read/write operations to the specified device, even if the policy for guarding the device includes security rules enforcing read and/or write access checks. Before you use this option, make sure that your environment requires it. You should always use the options described in the first three use cases if at all possible, so that CTE can apply access controls to all I/O operations and therefore perform all required read/write access checks.
The following example shows the steps for initializing and guarding the device /dev/sdb, then adding or using the guarded device under LVM to create a file system.
-
Initialize the device using the
-noaccoption: -
Guard the device as described in Guard the Linux Device with an in-Place Data Transformation GuardPoint.
-
Create and mount the file system.
