Planning considerations for security labels

For details about implementing security labels for a multilevel-secure environment, see z/OS Planning for Multilevel Security and the Common Criteria.

Even though a single user can use more than one security label, it might be easier to assign each person a separate user ID for each security label used.

Also, some consideration should be taken before using resource profiles that, due to their naming structure, would either cause large numbers of resources to be protected by the same security label (for example: userid.*) or protect resources that need to be accessed when the user is logged on at different security labels (for example, a NAMES data set).

These types of resources can be grouped into several categories and following certain procedures can minimize the impact of their use. You might consider creating data set profiles with the following naming structure:

userid.security-label.*

For example, if SMITH needs to use security labels EAGLE and THRUSH, create profiles like:

SMITH.EAGLE.*  UACC(NONE) SECLABEL(EAGLE)
SMITH.THRUSH.* UACC(NONE) SECLABEL(THRUSH)

Some services create new data sets based on the user's user ID. If the SETROPTS MLS option is in effect, authorization failures occur whenever the user uses a security label that is different from the security label that was in use when the data set was created. Applications that create such data sets should consider using the REXX RACVAR function package to determine the current security label for inclusion in the names of such data sets.

Read-only
In general, these resources pose no problem if they are protected by a profile with the lowest security label that is used. By being protected in this manner, they can be accessed any time the user is logged on. For example, system resources that are read by all users should be protected with the SYSLOW security label.
Read mostly
These resources must also be protected by a profile at the lowest security label that is used. This allows the user to access them for read any time the user is logged on. If the resource needs to be updated (for example: new names being added to the nickname file userid.NAMES.TEXT), the user must log on at his or her lowest security label in order to update the file.
Read/write but able to be preallocated
Data sets such as the ISPF list and log data sets fall into this category. These data sets can be allocated from within a logon CLIST with a different data set used for each security label. It should be noted, however, that due to multiple data sets being used, updates to a data set at one security label would not cause updates to occur to a data set that is used for the same purpose at a different security label (for example, an SPF profile data set).
Data sets written to from multiple levels
An example of this type of data set is the SPF EDIT recovery data sets. The CLIST ISREDRTI that creates the ISPF edit recovery table sets the default data set names for the recovery data sets to:
```
'&ZUSER.&ZAPPLID&ZEROS&I.BACKUP'
```
or for user ID RALPH to
```
'RALPH.ISR0001.BACKUP'
```
RACF® has provided sample exits in SYS1.SAMPLIB that show how to solve the problem (data sets written to from multiple levels) for ISPF and PDF data sets.

A data set profile would cause a security label authorization failure when an attempt was made to write to the data set while logged on with a security label that was different from the one in the profile. Applications that create data sets in this manner can be used only if each user has access to only one security label.

When RACF checks a user's authority to use a terminal or console, or the authority of outbound work to use a JES writer, RACF uses "reverse MAC" (mandatory access checking). That is, the security label of the profile protecting the writer must be equal to or greater than the security label of the user or outbound work.