Configuring a Multilevel Secure System › Using Security Labels › Configuring an HFS File System

Configuring an HFS File System

Security labels are supported in both zFS file systems and HFS file systems (mounted in read-only mode). When MLS is active and no other MLS options have been set, MLS security label checking is performed only on files and directories and objects that are labeled. If an object is not labeled, it is considered unclassified, and access to it is allowed, as long as permissions and ACLs allow the access.

Assigning a Security Label to an HFS File System Data Set

A security administrator can assign a security label to the HFS file system data set on a z/OS V1R5 or later system by creating a CA Top Secret MLS resource record for it. The following illustrates how to assign a security label to an HFS file system data set named HLQ.FILESYS.NAME.

Example

TSS ADD(mls) DSN(hlq.filesys.name)
             SECLABEL(sysmulti)

Assigning a Security Label to a Root Directory in an HFS File System

When an HFS file system data set is created in an MLS system:

• If the option to require security labels for files and directories is activated (MLFSOBJ(YES)), CA Top Secret assigns the user's session security label to the root of the file system.
• If the option to require security labels for files and directories is not activated (MLFSOBJ(NO)), CA Top Secret assigns the security label from an MLS resource record for the file system data set, if one exists, to the root of the file system.
• If an MLS resource record for the file system data set does not exist and the option to require security labels for files and directories is not activated, (MLFSOBJ(NO)), CA Top Secret does not assign a security label to the root of the file system, unless the MLS option to protect write-down (MLWRITE(NO)) has been set, in which case, CA Top Secret assigns the user's session security label to the root of the file system.

Note: If MLS is inactive on an CA Top Secret system, system labeling of files and directories is not supported.

Defaulting a Security Label for an HFS File System

UNIX defaults a security label for an HFS file system at the time it is mounted by using the same security label for it that is in the MLS resource record that protects the file system data set. Because defaulted security labels can change at mount based on the value in the MLS resource record for the aggregate, they are not the same as security labels that are assigned to file systems (and are stored in FSPs), which, once assigned, can never be changed.

USS defaults a security label for an HFS file system at the time it is mounted only if all of the following requirements are met:

• A security label has been assigned to the HFS file system data set. The system will assign this security label for the HFS file system.
• The MLS option to require security labels for files and directories has been activated before the file system is mounted
• The HFS file system is mounted in read-only mode
• The root directory of the file system does not already have a security label assigned to it

Once the file system is unmounted, it no longer will have a security label. If the file system is reclassified with a new security label by changing the MLS resource record for the file system data set and then remounted, the file system will be assigned the new security label.

Assigning a Security Label to a Subdirectory

When the UNIX mkdir command is issued in an CA Top Secret MLS system:

• If the security label of the owning directory is not SYSMULTI, CA Top Secret assigns the owning directory's security label to the FSP (subdirectory)
• If the security label from the owning directory is SYSMULTI, and a security label is not passed in the system CRED, CA Top Secret assigns the security label of the requesting user's address space to the FSP (subdirectory)
• If the security label from the owning directory is SYSMULTI, and a security label is passed in the system CRED, CA Top Secret assigns the security label from the CRED to the FSP (subdirectory)