Your suggested change has been received. Thank you.

close

Suggest A Change

https://thales.na.market.dpondemand.io/docs/dpod/services/kmo….

Thales Logo
back

Administrating LDT over CIFS/NFS with CipherTrust Manager

LDT Metadata Management Over NFS/CIFS Shares

search

Please Note:

LDT Metadata Management Over NFS/CIFS Shares

CTE manages LDT metadata as extended attributes in local file systems for each file and GuardPoint directory. Because the NFS/CIFS protocol does not support extended attributes, CTE embeds LDT metadata into each file to be encrypted inside the GuardPoint, over NFS/CIFS shares, during the initial data transformation. The size of the LDT metadata is 4096 bytes, so the size of each file in the NFS/CIFS share is increased by 4096 bytes. The presence of LDT metadata and larger file sizes is not visible to users and applications as long as the GuardPoint remains enabled. The same file stored in a CTE-LDT protected GuardPoint, over NFS/CIFS and a non-protected directory, is identical to other users and applications despite the presence of the embedded LDT attribute and the additional 4096 bytes.

As the Linux example below illustrates, the presence of the attributes embedded during the initial transformation of the file is invisible to users and applications. Note that the size of the file after transformation appears unchanged until the GuardPoint is disabled.

 ls /nfs-oxf-fs1/gp1

 cp /etc/hosts /nfs-oxf-fs1/gp2

 ls -l /nfs-oxf-fs1/gp2/hosts
-rw-r--r--. 1 root root 241 Jan  3 16:14 hosts

 secfsd -guard /nfs-oxf-fs1/gp2
secfsd: Guard point initialization in progress

 voradmin ldt attr get /nfs-oxf-fs1/gp2/hosts
LDT attributes: rekeyed_size=0, rekey_status=none
        Key:    clear_key


 ls -l /nfs-oxf-fs1/gp2/hosts
-rw-r--r--. 1 root root 241 Jan  3 16:15 /nfs-oxf-fs1/gp2/hosts

 secfsd -unguard /nfs-oxf-fs1/gp2
secfsd: Path is not guarded

 ls -l /nfs-oxf-fs1/gp2/hosts
-rw-r--r--. 1 root root 4337 Jan  3 16:15 /nfs-oxf-fs1/gp2/hosts

 voradmin ldt attr get /nfs-oxf-fs1/gp2/hosts
LDT attributes: rekeyed_size=4096, rekey_status=none
        Key:    name=LDTNFS_KEY_1, version=1482

As noted, CTE also manages the LDT attribute for each GuardPoint directory as an extended attribute. For GuardPoints over NFS/CIFS shares, CTE-LDT stores the LDT metadata for each GuardPoint in the LDT Attribute File associated with the directory. In general, there are multiple metadata files that CTE-LDT manages for GuardPoints over NFS. Those metadata files are stored in the LDT Private Space Directory inside each GuardPoint directory. The directory name of LDT Private Space is vorm_ldtprivspace. The directory is created inside the GuardPoint directory at the time of initial transformation. The LDT metadata file for a GuardPoint is also created in the vorm_ldtprivspace directory of the GuardPoint at the time of initial transformation. The name of the file is ::vorm:ldtxattr::, similar to the MDS file which is also protected against user modification or deletion. The size of the LDT metadata file is 4096 bytes. For example:

 ls -l /nfs-oxf-fs1/gp1/vorm_ldtprivspace/
total 4
-rwxr-xr-x. 1 root root 4096 Jan  4 12:13 ::vorm:ldtxattr::

The LDT Attribute file is protected, and it can only be manually removed using voradmin ldt rmldt delete. For details, see Deleting CTE-LDT Metadata (Linux).

On this page