The MLS implementation team must revise the security policy to include MAC, which requires that all selected resources (objects) and users (subjects) be labeled. These security labels are used to determine access. In general, MLS (fully implemented, with all options activated) states that subjects can only read data at their security label or below and they can only write to data with a security label that equals theirs.
The CA Top Secret MLS control options determine the MLS environment. The MLS administrator is responsible for maintaining the security options that control the MLS environment and security labeling. After these options are set, the system enforces them and creates loggings when an MLS administrator attempts to change them. The following sections describe the options that can be set to establish and activate an MLS environment.
Multilevel Security can only be activated if MLSBLOCKS have been allocated within the Security File and Backup Security File. If you have not allocated MLSBLOCKS, allocate a new security file, formatted with TSSMAINS. Copy your existing security file using TSSXTEND. The Backup Security File must be formatted with TSSMAINB.
The MLS environment is defined by specifying the MLS control options or by accepting the default values. The following control options are supported: MLACTIVE, MLMODE, MLFSOBJ, MLIPCOBJ, MLWRITE, MLNAME.
Specifies whether MLS is active on the system.
Default: NO
Specifies whether security labels are required for UNIX directories and files.
Default: NO
Specifies whether security labels are required for UNIX IPC objects.
Default: NO
Specifies whether security labels can be restricted for use on specific systems as specified in the SYSID field of theMLS SECLABEL data record.
Default: NO
Note: The system-defined security labels, SYSLOW, SYSHIGH, SYSMULTI, and SYSNONE, are always available on all systems regardless of whether this option is on or off.
Specifies whether writing data from a higher security label to a lower security label is allowed or prohibited in the system. When MLWRITE(NO) is set, write-down is prevented and new data is labeled automatically and internally by the system at the time it is created with the session security label of the user who first created the data. In addition, when MLWRITE(NO) is set, there may be some situations where a user may need to write-down. In these cases, a security administrator can authorize a user for “controlled write-down”. Controlled write-down lets a user enter the system with the ability to write‑down by default (UPDATE access to the IRR.WRITEDOWN.BYUSER resource in the FACILITY class) or issue the TSS MLWRITE subcommand to set, reset or query write-down privilege (READ access to the IRR.WRITEDOWN.BYUSER resource in the FACILITY class). Controlled write-down is also available in a UNIX System Services environment through the UNIX writedown command.
Default: YES
Before enabling MLWRITE(NO), CA recommends that you successfully test the system in MLS WARN mode before implementing FAIL mode. There may be some system performance degradation when NOMLWRITE is set.
Defines a mode for MLS security, independent of the MODE for standard permissions. MLMODE determines how security reacts to an MLS validation rule violation. Permissions with ACTION(WARN|FAIL) have no effect on the interpretation or reaction of security to MLS validation rules. Valid modes are:
(Default) Validates security labels only at system entry. Logging is done for violations. No messages are returned to the console or to the user.
Permits MLS accesses to classified data sets and resources that normally would violate MLS validation rules and sends a warning message to the user (or the system log). Violations are logged.
Prevents MLS accesses to classified data sets and resources based on MLS validation rules and sends an error message to the user (or the system log). Violations are logged.
To view the MLS Control Options, enter:
TSS MODIFY(STATUS(MLS))
To change the MLS control options use the TSS modify command from the console or the TSS TSO MODIFY command.
TSS MODIFY(MLACTIVE(YES)
The MLFSOBJ option specifies whether security labels are required for UNIX directories and files in an MLS system. The default is MLFSOBJ(NO), security labels are not required for UNIX directories and files. This option should be turned on if you want to use MAC protection and security labels for UNIX files and directories.
The MLIPCOBJ option specifies whether security labels are required for UNIX IPC objects, such as semaphores. The default is MLIPCOBJ(NO), security labels are not required for UNIX IPC objects. This option should be turned on if you want to use MAC protection and security labels for UNIX IPC objects.
The MLWRITE(NO) option in the control options is used to prevent declassification of data in an CA Top Secret MLS system. This is known as the “confinement property” or “*-property”. When this option is specified, writing data from a higher to a lower security label is not allowed. In addition, CA Top Secret will assign to data, at the time it is created, the session security label of the user who created the data. The security label assigned is stored in the MLS record. Once data has been labeled in this way, to reclassify it by assigning it a different security label, a security administrator must create an MLS resource record for the data set with the changed security label.
The following examples illustrate use of the MLWRITE subcommand:
To display your controlled write-down setting, enter:
TSS MLWRITE(status)
To activate controlled write-down for yourself, enter:
TSS MLWRITE(enable)
To deactivate controlled write-down for yourself, enter:
TSS MLWRITE(disable)
If MLS is not active on the system and the user issues the MLWRITE command, an error message will be displayed.
TSS MLWRITE(status)
If MLS is active on the system, but the control option is MLWRITE(YES) , (global write-down is allowed), and the user issues the MLWRITE command, an error message will be displayed.
TSS MLWRITE(status)
Because catalog entries can be read by a job with any security label, users must be careful how they name their data sets. People tend to create data set names that help them to remember the contents of their data sets. This can also reveal more information than was intended. For example, a data set named PAYROLL.LAYOFF.PLANS listed in a catalog could fuel rumors and hurt employee morale, even if its contents could not be read. Users should be cautioned to choose their data set names carefully. If sensitive data set or file names must be protected, a security administrator can hide the names of data sets and files.
When MLS is active on a system, the MLWRITE subcommand can be issued by an authorized user to override global write-down protection by setting, resetting or querying the setting of the write-down mode for the user's address space. When MLWRITE(NO) has been set as a control option to globally prevent writing data from a higher to a lower security label, and a user has READ access to the IRR.WRITEDOWN.BYUSER resource in the FACILITY class (using a resource rule), the user is authorized to issue the MLWRITE subcommand to:
However, if a user enters the system and has UPDATE access to the IRR.WRITEDOWN.BYUSER resource, CA Top Secret will, by default, allow the user to write-down without issuing the MLWRITE subcommand during their session, although the user can issue the command if they also have READ access to the IRR.WRITEDOWN.BYUSER resource. When the RESET operand on the MLWRITE subcommand is specified, CA Top Secret will reset the user write-down mode to the default value that was set at the time the user entered the system.
Note: A user who has the SECURITY privilege in their acid has READ and UPDATE access to the IRR.WRITEDOWN.BYUSER resource in the FACILITY class and is, therefore, authorized to write-down after successful system entry as well as issue the MLWRITE subcommand. However, it is recommended that security administrators disable “controlled write-down” for themselves after system entry to protect against unintentional declassification of data, unless the administrator needs to exercise this privilege.
The MLWRITE command has the following syntax:
MLWRITE [STATUS | ENABLE | DISABLE ]
Displays the status of the write-down mode during the user's current session. This is the default when no parameters are specified with the MLWRITE command.
Specifies that a user's write-down mode be turned on and displays the status of the user's ability to write-down during the current session as 'ENABLED'.
Specifies that a user's write-down mode be turned off and displays the status of the user's ability to write-down during the current session as 'DISABLED'.
To allow a user to control write-down for himself by issuing the MLWRITE subcommand, a security administrator should do the following:
TSS PER(mluser1) IBMFAC(irr.writedown.byuser access(read) TSS PER(mluser2) IBMFAC(irr.writedown.byuser access(update)
When MLS is active, it is possible to separate work in a SYSPLEX based on security labels. This may be useful if you want to run all work with one security label (LABELA) on one system while running all work with another security label (LABELB) on another system in a sysplex while sharing the CA Top Secret database. The MLSECBYS(YES|NO) control option determines whether seclabels are restricted for use on specific systems as specified in the SYSID field of MLS seclabel records.
To restrict the use of a security label to one or more systems, you must do the following:
TSS ADD(mls) SECLABEL(labela)
SECLEVEL(50)
CATEGORY(development)
SYSID(sysa)
If a user tries to signon to an MLS system other than SYSA with security label, LABELB, the access will be denied. Likewise, if a user is signed onto a system other than SYSA and tries to access a resource classified with LABELB, the access will be denied, if MLMODE(FAIL) is set as the global MLS mode. Finally, JES2 will ensure that any jobs with LABELA are submitted and executed on the correct system, SYSA.
Note: The system-defined security labels, SYSLOW, SYSHIGH, SYSMULTI, and SYSNONE, are always available on all systems regardless of whether the MLSECBYS option is turned on or off.
Important! JES3 does not support system-specific security labels. In addition, JES2 also does not support system-specific security labels for systems that do NJE and OFFLOAD processing.
The MLMODE control option lets you change the MLS component mode without IPLing the system.
After setting up your MLS environment, including defining options, security levels, categories (if used) and security labels, and assigning security labels to those users and resources that require classifications, you are ready to activate MLS on your system in DORM mode to begin phasing in and testing MLS before fully activating it in MLS mode.
To activate MLS in DORM mode, issue the following commands:
F TSS,MLMODE(dorm)
F TSS,MLACTIVE(yes)
If the MLS environment is set in QUIET mode at the time MLS is activated, security labels will only be checked at system entry to allow or deny access to the system. If access to the system is denied, logging occurs and DAC validation is not performed. If MLS allows access to the system, DAC validation is performed and will either allow or deny the access.
Starting your implementation in DORM mode provides you time to set up your MLS environment and train users on how to use the security labels that you create and assign to them.
You can test User Seclabels and system entry validation by having users log off the system and logon again using the security labels they are authorized to use. CA Top Secret permits or denies system access based on the security label provided or defaulted at logon.
After you are satisfied that users can access the system using labels, you must test whether users can access the data sets that they must to perform their jobs. After you have tested system access in DORM mode, you can migrate to WARN mode. To migrate to WARN mode, use the following procedure.
To activate MLS in WARN mode, enter:
TSS MODIFY(mlmode(warn))
If the MLS environment is set in WARN mode at the time MLS is activated, security labels will be checked at system entry as well as when access to any classified resource is requested. The system will log and permit MLS accesses to classified resources that would normally violate MLS validation rules and issue a warning message to the user, and DAC validation will then be performed to allow or deny the access.
After your MLS system is running in WARN mode, you should test data set and resource accesses by doing the following:
After your MLS system has been running in WARN mode, you may need to make adjustments to the settings in the various MLS records. For example, you can decide to test your security policy by implementing MLS for a select group of data sets. You might decide to relabel some data sets or resources that are incorrectly labeled.
Follow the same procedure you used to migrate to WARN mode.
If the MLS environment is set in FAIL mode at the time MLS is activated, security labels will be checked at system entry as well as when access to any classified resource is requested. The system will log and prevent MLS accesses to classified resources that violate MLS validation rules and DAC validation will not performed if MLS access was denied.
After establishing an MLS environment, if you need to deactivate MLS for any reason, you must be sure that doing so will not compromise any protected data and resources in the system.
MLS may be deactivated from the console or from TSO with the following commands
F TSS,MLACTIVE(no)
TSS MODIFY(mlactive(no))
|
Copyright © 2010 CA Technologies.
All rights reserved.
|
|