Automatic and Manual GuardPoints
The following table lists the type of GuardPoints depending on the platform and type of the policy type:
Type | Windows | Linux | Description |
---|---|---|---|
Auto Directory | Yes | Yes | Select for file system directories. |
Manual Directory | No | Yes | Select for file system directories to be guarded manually. |
Auto Raw or Block Device | Yes | Yes | Select for standard policies for raw (block) devices. |
Manual Raw or Block Device | No | Yes | Select for standard policies for raw (block) devices to be guarded manually. |
Auto Cloud Storage | No | Yes | Select for Cloud Storage policies. |
Manual Cloud Storage | No | Yes | Select for Cloud Storage policies to be guarded manually. |
A GuardPoint is usually applied immediately after it is configured on the CipherTrust Manager GUI; however, it can be applied later on the client system.
When would you want to apply the GuardPoint later? Consider the case of a 2-node cluster configured as active/passive in a cluster environment, such VCS, HACMP, or MSCS. There are two nodes, one which is currently active and the other that is currently inactive. Both nodes are locked.
Apply GuardPoint protection to active nodes only. You should never apply a GuardPoint to a passive node. If the active node develops a problem and tries to switch over to the inactive node, the cluster process fails to switch over because the mirror directory on the inactive node is currently mounted on the active node.
The solution is, for the cluster process to unmount (for example, unguard) the currently active node:
Place it in an inactive state.
Place the old inactive node in an active state.
Mount (for example, guard) the mirror directory on the newly active node.
Generally, when you get error messages, check that only active nodes are properly guarded.
When an auto GuardPoint is applied, regardless of whether it is a file system directory or a raw device, the change is pushed to the client system, and the GuardPoint is applied immediately.
Use the df
command to display secfs
mounts (for example, GuardPoints) or secfsd
to display the GuardPoints themselves. The secfsd
output shows a guard type of local for directories configured with Directory (Auto Guard).
Run:
df
Output:
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
40123784 11352236 26733380 30% /
/dev/sda1 101086 14590 81277 16% /boot
none 254492 0 254492 0% /dev/shm
/opt/vormetric/DataSecurityExpert/agent/secfs/.sec
40123784 11352236 26733380 30%
/opt/vormetric/DataSecurityExpert/agent/secfs/.sec
/opt/apps/apps1/tmp 40123784 11352236 26733380 30% /opt/apps/apps1/tmp
/opt/apps/apps1/lib 40123784 11352236 26733380 30% /opt/apps/apps1/lib
/opt/apps/apps1/doc 40123784 11352236 26733380 30% /opt/apps/apps1/doc
Run:
secfsd -status guard
Output:
GuardPoint Policy Type ConfigState Status Reason
---------- ------ ---- -------- ------ ---
/opt/apps/apps1/tmp allowAllOps_fs local guarded guarded N/A
/opt/apps/apps1/lib allowAllRootUsers_fs local guarded guarded N/A
/opt/apps/apps1/doc allowAllOps-winusers1_fs local guarded guarded N/A
When a manual GuardPoint is applied, regardless if it is a file system directory or a raw device, the change is pushed to the client system only. The client is aware of the GuardPoint but the client does not mount it. This is indicated in the Type
column of the secfsd -status guard
command output.
For example, the GuardPoint /opt/apps/apps2/bin
has been configured with Manual Directory, so the guard type is set to manual
.
secfsd -status guard
Output:
GuardPoint Policy Type ConfigState Status Reason
---------- ------ ---- -------- ------ ---
/opt/apps/apps1/tmp allowAllOps_fs local guarded guarded N/A
/opt/apps/apps1/lib allowAllRootUsers_fs local guarded guarded N/A
/opt/apps/apps1/doc allowAllOps-winusers1_fs local guarded guarded N/A
/opt/apps/apps2/bin HR_policy01 manual unguarded not guarded Inactive
Note the Type
value. A Type
of manual
indicates a manual GuardPoint. A Type
of local
indicates an automatic GuardPoint.
A manually applied GuardPoint remains Inactive until the GuardPoint is applied on the client. After the GuardPoint is applied on the client, and the client communicates the change to the server, the status changes to Active. It returns to the Inactive state when the GuardPoint is manually unguarded.
Use the secfsd
command to guard and unguard Manual GuardPoints. The secfsd
command syntax is:
To guard, run:
secfsd -guard path
To unguard, run:
secfsd -unguard path
Example
To manually guard and unguard a file system directory:
As CipherTrust Manager administrator, configure a GuardPoint with the type Manual Directory.
Log on to the client as an administrator with root permissions.
Wait until the configuration change is downloaded to the Agent system.
Run the status command until the manual GuardPoint is displayed.
Run:
secfsd -status guard
Output:
GuardPoint Policy Type ConfigState Status Reason ---------- ------ ---- ----------- ------ ------ /opt/apps/etc allowAllOps_fs manual unguarded not guarded N/A /opt/apps/lib/dx3 allowAllOps_fs local guarded guarded N/A
Enable the GuardPoint.
Run:
secfsd -guard /opt/apps/apps2/bin
Output:
secfsd: Guard initiated
The manual GuardPoint is active and the policy is enforced.
Disable the GuardPoint.
Run:
secfsd -unguard /opt/apps/apps2/bin
Output:
secfsd: Unguard initiated