z/OS MVS uses the IBM System Authorization Facility (SAF) as an interface to all external security products such as CA Top Secret. SAF uses the MVS router to process the security calls. CA Top Secret uses the information stored in its database to make a recommendation to the program making the security call. The program must act on the recommendation of CA Top Secret.
The following is supported when MLS is active on an CA Top Secret system:
The following restrictions apply when MLS is active on an CA Top Secret system:
This checklist describes the software configuration requirements when MLS is active on an CA Top Secret for z/OS MVS system.
|
Requirement |
Complete |
|---|---|
|
Force console operators to log on before issuing commands |
□ |
|
Modify the CONSOLxx member of SYS1.PARMLIB |
□ |
|
Create acid records for all operators |
□ |
|
Assign security labels to console operators |
□ |
|
Define console source controls (optional) |
□ |
|
Write resource rules to control console access |
□ |
|
Write resource rules for operator commands |
□ |
|
Configure SCHEDxx for data set protection |
□ |
|
Specify SMF controls |
□ |
|
Provide an audit trail for accesses to protected objects using operator commands |
□ |
|
Protect critical data sets |
□ |
|
Write access rules |
□ |
|
Assign security labels to critical data sets |
□ |
|
Protect UNIX files and directories |
□ |
|
Assign security labels to UNIX files and directories |
□ |
|
Protect resources |
□ |
|
Identify and classify users on the system |
□ |
|
Create acids for users |
□ |
|
Assign security labels to users |
□ |
|
Establish JCL standards |
□ |
|
Define acids for MVS started tasks |
□ |
|
Define resource rules for LLA started task |
□ |
|
Define access rules for BLSJPRMI started task |
□ |
|
Make sure SMS is active in IEFSSNxx |
□ |
|
Move forbidden modules out of system libraries |
□ |
Console operators are considered trusted users. It is assumed that anyone with physical access to operator consoles is cleared to the label of all data on the system. However, the actions of console operators must be audited so that a specific action can be traced to a specific console operator. In order to ensure accountability, operators must sign on to operator consoles and undergo identification and authentication. Before signing on, they are able to view message traffic on the consoles, but they can issue no commands.
To force operators to sign on before issuing commands, you must do the following:
You must specify LOGON(REQUIRED) on the DEFAULT statement in the CONSOLxx member of SYS1.PARMLIB. This forces users to undergo identification and authentication checks before entering commands through an operator console. The following exceptions apply:
After CA Top Secret is active, operators must log on to all system consoles.
Each console operator must have a unique acid record. In addition to the usual fields that must be set, you may want to specify an entry source for each operator to define the consoles that they can access the system.
In an MLS system, you should assign the system-defined security label SYSHIGH to console operators. To authorize an operator to use the SYSHIGH security label at console logon, an MLS administrator must add the SYSHIGH seclabel to the operator's acid record. Operators need this high-level clearance. Their unrestricted authority to view console message traffic prevents the situation where a critical system error message is issued, and no operator is signed on with a high enough label to see it.
It is possible to restrict the use of particular consoles to specific users. For example, printer operators might be allowed only to use consoles in the printer room, while master operators could use any console, and ordinary users could not use any consoles.
To meet the requirements of an MLS system, the system must be able to audit all operator commands. These commands include all MVS operator commands and all operator commands for other products or subsystems, such as JES2 or CA Top Secret. The information in the audit records lets a security administrator or auditor determine the following:
It is also necessary to control the use of operator commands issued through the JCL of batch jobs. These commands are controlled the same way as commands issued through an operator console; a user who is authorized to issue commands from a console can also issue commands in batch JCL.
In an MLS system, CA Top Secret assigns security labels to UNIX files and directories at the time they are created. However, if MLS is not active on the system at the time UNIX files and directories are created, but is later turned on, these objects will not have security labels. As a result, the security administrator must provide security labels for any UNIX files and directories that do no have security labels by issuing the UNIX chlabel shell command; otherwise, all accesses to these files and directories may be denied by CA Top Secret.
See the Assigning Security Labels to UNIX Files and Directories section in the “Implementing and Administering a Multilevel-Secure System” chapter for a list of security labels that are recommended for UNIX files and directories to which the system did not assign security labels. In addition, see the z/OS Unix System Services (UNIX) section for a complete discussion of how to configure UNIX in an CA Top Secret MLS system.
The PPT statement in the SCHEDxx member of SYS1.PARMLIB specifies attributes for programs. The PASS|NOPASS option, which originally specified whether data set protection by passwords should be honored, also determines whether RACROUTE calls are issued at data set open. NOPASS suppresses the RACROUTE calls. PASS, the default, enables the RACROUTE calls, and must be specified for all programs in the SCHEDxx member.
The SCHED00 member of SYS1.SAMPLIB contains a sample SCHEDxx member.
In an MLS system, you should protect the data sets managed by library lookaside (LLA), as well as all system data sets. LLA is an MVS service that caches information about production libraries in order to provide faster access to them. The list of production libraries includes all link list data sets (all data sets specified in the LNKLSTxx member of SYS1.PARMLIB) and all data sets specified in the CSVLLAxx members of SYS1.PARMLIB.
To protect these data sets, do the following:
Use the TSS command to create access rules for the high-level qualifiers of the data sets specified in the CSVLLAxx and LNKLSTxx members of SYS1.PARMLIB. You must allow console operators write access to these data sets. This is necessary because when a console operator issues a MODIFY LLA, REFRESH command (to make it recognize updated members in it libraries), MVS validated this as if the operator were actually writing to each of the libraries.
In an MLS system, when the option to protect write-down of data has been activated, a security administrator should provide security labels for any system data sets that are not labeled, in addition to writing DAC access rules. See the Labeling Catalogs and Critical Data Sets section in the “Implementing and Administering a Multilevel-Secure System” chapter for a list of security labels that are recommended for critical data sets.
The security administrator must ensure that all resources that are considered “classified”, have been assigned security labels. When MLS is active in MLS mode, CA Top Secret will fail any attempt to access a classified resource that violates MAC label dominance checking rules.
All users must be identified and authenticated in an CA Top Secret environment. In addition, all users entering the system should have a security label.
In an MLS system, each user entering the system must be assigned a unique acid.
In an MLS system, security labels should be assigned to all users who require them before MLS or any other MLS options have been activated on the system.
In an MLS system, all jobs must be submitted by users identified to CA Top Secret or be associated with an CA Top Secret user. If a subject submits a job from TSO (using the SUBMIT command, for example), the job ordinarily inherits the subject's acid. However, if the subject wants a job to run under a different acid, the JCL must identify that acid and its password.
An acid and password can also be specified through the USER= or PASSWORD= keywords on the JCL JOB statement. The password is not printed in the JCL listing.
Note: Good security practice dictates that users should not submit jobs under other people's acids. Using another's acid would require knowing that person's password, which would cause loss of accountability. However, it is acceptable for a person who is assigned more than one acid to sign on with one of those acids and submit jobs under it.
In an MLS system, a user can also specify a security label for a job in the SECLABEL= keyword on the JCL JOB statement. If a security label is specified, the user must be authorized to specify the seclabel. The job will then be assigned that security label.
//USERAX JOB (40100000),'TEST',MSGCLASS=A,MSGLEVEL=(1,1), // NOTIFY=USERA,SECLABEL=SYSHIGH
A security administrator must define acids for several z/OS MVS started tasks before IPLing the system. The following table lists which started tasks require acids. All of these acids have an STC attribute. No other attribute need be specified.
|
Started Task |
Description |
|---|---|
|
IOSAS |
I/O system address space |
|
XCFAS |
Cross-coupling facility address space |
|
LLA |
Linklist Lookaside started task |
|
BLSJPRMI |
IPCS initialization task |
|
VLF |
Virtual Lookaside Facility address space |
|
INIT |
z/OS MVS initiator |
|
DEALLOC |
Deallocation started task |
|
IEEVMPCR |
MOUNT command |
When the LLA started task starts up, and whenever an F LLA,REFRESH operator command is issued, LLA validates its access to the linklist data sets. It does this by means of RACROUTE REQUEST=AUTH calls with a class of FACILITY and an entity name of CSVLLA.dsname where dsname is the data set name.
A security administrator must write resource rules of the FAC type (the FACILITY class is mapped into FAC resource rules) for all data sets listed in the LNKLSTxx or CSVLLAxx members of SYS1.PARMLIB.
The BLSJPRMI started task performs initialization of IPCS using parameters read from SYS1.PARMLIB. Because of this, a security administrator must write an access rule giving BLSJPRMI read access to SYS1.PARMLIB.
SMS should be active on an MLS system. This does not mean that all, or any, volumes, on the system must be SMS-managed, merely that SMS must be active. This is necessary because having SMS active changes the code path for many allocation functions.
To activate SMS, the following line must be present in the IEFSSNxx member of SYS1.PARMLIB:
SMS,IGDSSIIN,'ID=00,PROMPT=DISPLAY'
The xx in IEFSSNxx represents the suffix specified in the keyword of the IEASYS00 member of SYS1.PARMLIB. If no line beginning with “SMS” is present in the IEFSSNxx member, this line should be added after the last line. If an SMS entry is present, but does not specify IGDSSIIN, it should be changed to do so. The ID=00 and PROMPT=DISPLAY keywords can be changed as needed. See SMS documentation for details on these parameters.
Some modules shipped with z/OS MVS and resident in link list or LPA libraries, implement features that should not be allowed in an MLS system. These modules should be moved to other, non-APF authorized libraries or deleted in order to disable these features:
|
Copyright © 2010 CA Technologies.
All rights reserved.
|
|