Time Sharing Option (TSO/E)

Configuring a Multilevel Secure System › Time Sharing Option (TSO/E)

Time Sharing Option (TSO/E)

In an MLS CA Top Secret system, all users must log on to the system and undergo identification and authentication checks. CA Top Secret creates a security environment for each TSO/E user. The security label that is used to logon to TSO/E is maintained in a user's security environment and is used to make access decisions until the user logs off. CA Top Secret ensures that a user cannot alter his security label in any way while logged onto the system. To change his security label, a user must log off and log on again to TSO/E with a new label.

Support for MLS TSO/E

The following is supported when MLS is active on an CA Top Secret system:

All users can be be identified and authenticated in the system with a acid and security label
All user logon attempts can be audited
All user messages can be protected
Sending and receiving data sets with the TRANSMIT and RECEIVE commands can be controlled based on security labels
Users can be restricted to using the CANCEL and OUTPUT commands only on jobs whose job names begin with their acids

Restrictions

The following restrictions apply when MLS is active on an CA Top Secret system:

Remove all user-written exits
Do not give any TSO/E user the OPERATOR privilege
Do not activate the Information Center Facility

Configuration Checklist

This checklist describes the software configuration requirements when MLS is active on an CA Top Secret system.

Requirement	Complete
Define an acid for the TSO started task	□
Define access rules for the TSO started task	□
Provide identification and authentication checks	□
Define a acid for each TSO/E user	□
Assign security labels to TSO/E users	□
Audit all logon attempts	□
Protect user messages	□
TSO/E SEND and LISTBC commands	□
Follow requirements for protecting message transmission	□
Modify IKJTSOxx member of SYS1.PARMLIB	□
Create resource rules for each user mail log	□
Label user mail logs SYSHIGH	□
Create an acid record for *LISTBC ID	□
Assign security label SYSLOW to SYSI1.BROADCAST
Control use of RECEIVE and TRANSMIT commands	□
Assign security labels to LOG.MISC data sets	□
Assign security labels to NAMES.TEXT data sets	□
Replace default IKJEFF53 exit	□
Provide an audit trail for SEND and LISTBC commands	□

Defining an Acid for the TSO Started Task

You must define a acid for the TSO started task. This acid must have the STC attribute. No other attributes need be specified.

Defining Access Rules for the TSO Started Task

When the TSO started task starts up, it reads initialization parameters from SYS1.PARMLIB. Because of this, it must be granted read access to the data set. Here is an example of a rule granting TSO read access to SYS1.PARMLIB:

$KEY(SYS1)
 PARMLIB UID(TSO) R(A)

Providing Identification and Authentication Checks

In an MLS system, all TSO/E users must undergo identification and authentication checks by CA Top Secret.

Defining a Logonid for Each TSO/E User

The security administrator must create a unique acid record for each TSO/E user. CA Top Secret stores the information in security file and retrieves it when a user attempts to log on to the system.

Assigning Security Labels to TSO/E Users

The security administrator should assign security labels to TSO/E users so that users can access the system and classified data and resources that they need to perform their work on the system.

In an MLS system, when a user logs on to a system, he may specify a security label. However, CA Top Secret will always default a security label for a user who does not supply a label. If a user does not specify a security label at logon on the full-screen panel, if there was a previous TSO/E session for the user, the security label from that session will be used. If there was no security label for the previous TSO/E session, CA Top Secret uses the security label from the terminal (an MLS resource record in the TERMINAL class), if there is one. If the terminal does not have a security label, CA Top Secret uses the default security label from the User's acid record, if one exists. If CA Top Secret cannot default a security label from any of these places, the user will be logged on with the SYSLOW security label.

Once CA Top Secret verifies that the user is authorized to use a security label, the security label is maintained in the user's address space and is used to make access decisions until the user logs off. CA Top Secret ensures that a user cannot alter his security label in any way while logged onto the system.

Important! If a user wants to change his security label, he must log off and log on using a different security label. This reduces the threat from Trojan horses and prevents inadvertent data disclosure.

The TSO/E LOGON command lets users provide a security label at logon by specifying the SECLABEL parameter. In addition, the TSO/E full-screen panel lets users provide a security label at logon. A new field, SECLABEL, has been added to the TSO/E Full-Screen. When MLS is active, a valid security label may be specified in this field. If an invalid security label is specified in this field, the user will repeatedly be prompted until a valid security label is specified or the field is left blank.

Important! When MLS is inactive on a system, the location of the new SECLABEL field may affect some “screen-scrapers”.

Audit Logon Attempts

In an MLS system, in addition to checking to see that a user provides a valid logonid and password, CA Top Secret checks to see that a user provides a security label that he is authorized to use. CA Top Secret creates a record for each unsuccessful logon attempt. These records are stored in the ATF/SMF data sets and can be viewed using the TSSUTIL report program.

Protecting User Messages

In an MLS system, when write-down is protected, all data created by a user receives the security label of the user. This means that a user logged on with a security label LABELA whose value is SECLEVEL(50) CATEGORY(AA BB) creates data labeled LABELA. This includes messages. To prevent inappropriate disclosure, a user cannot receive messages from another user whose security label dominates his. For example, a user whose security label has a value of SECLEVEL(25) CATEGORY(AA QQ) cannot receive messages from a user whose security label has a value of SECLEVEL(50) CATEGORY(AA BB). This places some restriction on where messages that cannot be immediately sent (those sent with the SAVE or LOGON options of the TSO/E SEND command) are stored. Traditionally, the SYS1.BRODCAST data set was where these messages were stored, along with broadcast messages intended for all users. In an MLS system, SYS1.BRODCAST is considered a public object, readable by any user. This makes it unsuitable for storing messages with security labels higher than SYSLOW.

Instead, an MLS system requires a separate data set, called a mail log, for each user. This log is labeled SYSHIGH, and contains all the saved messages for the user, regardless of his security label. The user cannot access the mail log as an ordinary data set, but only through the LISTBC command, a trusted command that will only show the user the messages that are dominated by his current session security label. The LISTBC command also displays any saved broadcast messages. These messages, which are intended for all users and are always labeled SYSLOW, are saved in the SYS1.BRODCAST data set.

The goal in separating messages sent to the SYS1.BRODCAST data set and those sent to individual user mailboxes is to prevent the disclosure of sensitive information. A user logged on with a high label should not be able to send messages to a user logged on at a lower label. This could allow sensitive information to be disclosed. Similarly, if a user who can log on with a high label is logged on with a low label, he should not be able to view messages sent to him at the high label while he is logged on at the low label.

Using TSO/E SEND and LISTBC Commands

TSO/E provides the capability for TSO/E users to communicate with each other, while logged on, through messages. By default, when a message is sent, the operating system attempts to display the message to the user or console, if active. However, the sender can specify that the message is to be saved, if it cannot be delivered immediately. In an MLS system, immediate delivery might not occur for one of several reasons:

The intended recipient is not logged on
The intended recipient is logged on, but is not receiving messages
The recipient's security label does not permit the message's display

When a message is saved for an individual TSO/E user, it is called “mail”, and is placed in a user's exclusive mail log. When an operator sends a message to all users, it becomes a “notice”, if it is saved in the SYS1.BRODCAST data set for later display to users who could not receive it interactively. If an operator-sent message is directed to an individual user, if it is to be retained, it is treated as mail, not as a notice, and it is stored in the user's mail log until the user logs on or asks to review his mail.

Messages can originate from sources other than user TSO/E address spaces and system consoles. JCL supports a NOTIFY parameter that lets a batch job notify the user identified by this parameter of a job's completion. JES2 implements this feature by issuing the OPERATOR SEND command, so that it's processing is identical to that of a console operator sending an individual TSO/E user message.

The TSO SEND command verifies the sender's authority to send a message to the designated recipient through a RACROUTE AUTH request for the SMESSAGE class that includes the user's acid. If the SEND program, running in the sender's TSO/E address space, must deliver the message, even if the recipient is not logged on or the intended recipient is not receiving messages, the message is written to the user's mail log or, in the case of a broadcast message, to SYS1.BRODCAST.

The following table summarizes some of the options that a sender has when sending a message using the TSO/E SEND and OPERATOR SEND commands:

Command	Options	Original Destination	Alternative Destination
SEND	NOW(default)	Recipient's Terminal	None
SEND	LOGON	Recipient's Terminal	Recipient's Mail Log
SEND	SAVE	Recipient's Mail Log	None
OPERATOR SEND	ALL or SAVE	Recipient's Terminal	SYS1.BROADCAST
OPERATOR SEND	USER and LOGON	Recipient's Terminal	Recipient's Mail Log

The retrieval of mail and notices is performed by LISTBC. The LISTBC command displays broadcast messages and messages saved in the TSO/E user's mail log. All broadcast messages are stored in the SYS1.BRODCAST data set, which should be labeled, SYSLOW, while LISTBC creates for each user a mail log labeled, SYSHIGH, the first time the command is invoked. To do this, the LISTBC command automatically issues a RACROUTE VERIFY request with an acid of *LISTBC, and TRUSTED='YES', when it is first called. CA Top Secret treats this call as a started task and saves the security label as, SYSHIGH. If the mail log does not exist, LISTBC proceeds to create it with its current security label of SYSHIGH.

Because LISTBC is trusted and, thus, labeled SYSHIGH, it is able to access a user's mail log, no matter what the security label is for the user's TSO/E session. Thus, on subsequent invocations, LISTBC is able to open the mail log and for each message record it finds, it issues a RACROUTE DIRAUTH request with the security label for the message record (returned by the RACROUTE SECLABEL parameter). CA Top Secret compares that security label to the security label of the user assigned to the current TSO/E address space. If the security label of the TSO/E address space dominates that of the message, then the message is allowed to be displayed. Otherwise, LISTBC deletes the message record from the mail log.

In an MLS system, when a user issues a TSO SEND command, CA Top Secret performs a MAC and DAC check. The MAC check processing works differently depending on whether the sending user specifies the NOW, LOGON, or SAVE parameters.

If the sending user specifies the NOW parameter, or if the sending user specifies the LOGON parameter and the receiving user is currently signed on, CA Top Secret checks to see if the security label of the target user dominates the security label of the sending user. If it does, the DAC check searches for the SMESSAGE resource rule to see if the user can send a message to the target user. If not, the user receives an error message. If so, the command executes and the message appears immediately on the target user's screen. However, if the security label of the sending user dominates the security label of the target user, the command fails and the sending user is notified.
If the sending user specifies the SAVE parameter, or if the sending user specifies the LOGON parameter and the receiving user is not currently logged on, the system stores the message in the target user's user log until he logs on or issues the LISTBC command. MAC label checking is done at that time.
In an MLS system, when a user issues the LISTBC command, the system sends any SYS1.BRODCAST messages and then any other messages whose security labels are dominated by the user's security label. The user can only view those messages in his user log if his security label dominates the security label of the user who sent the message. If there are other messages in the user's log, the system does the following:
If the security label of the message dominates the security label of the user issuing the LISTBC command, but the user can log on with a security label that dominates the security label of the message, the system displays the following message:
```
IKJ5G9621 YOUR USER LOG CONTAINS MESSAGES THAT CANNOT BE VIEWED AT YOUR CURRENT SECURITY LABEL
```
The user can then decide whether he wants to log off and log on with a higher security label to view the message.

Requirements for Protecting Message Transmission

The following are requirements for protecting message transmission:

Modify the IKJTSOxx member of SYS1.PARMLIB
Create resource rules for each user mail log
Label user mail logs SYSHIGH
Create acid record for *LISTBC
Assign a security label to the *LISTBC ID
Create an access rule for SYS1.BRODCAST
Assign security label SYSLOW to SYS1.BRODCAST

Modifying IKJTSOxx Member of SYS1.PARMLIB

The security administrator can configure the SEND parameter of IKJTSOxx member of SYS1.PARMLIB properly to protect individual user mail logs and restrict access to messages based on labels. The proper settings are as follows:

Set the CHKBROD operand to off. This prevents the LISTBC command from looking in SYS1.BRODCAST for user messages. Instead, it looks in the individual mail logs only.
Set the MSGPROTECT operand to ON. This setting turns on label validation for user mail logs. When a user issues the LISTBC command to view messages, CA Top Secret performs security label validation to ensure that the user's security label dominates the security label of any messages in the box. The user cannot view messages whose security labels dominate his security label.
Set the LOGNAME operand to specify the high-level qualifiers of the data set names to be used in user mail logs. The value specified will be suffixed with each user's acid. For example, if LOGNAME were set to MAIL.BOX, the user mail log for the acid USER01 would be named MAIL.BOX.USER01.
Set the USEBROD operand to OFF. This prevents messages for users who do not have individual user mail logs from being stored in SYS1.BRODCAST. Instead, the SEND command is rejected.

The security administrator should make these changes before IPLing the system. For more information about these changes, see the following:

IBM z/OS MVS Initialization and Tuning Reference for details on the IKJTSOxx member of SYS1.PARMLIB
IBM z/OS Customization for details on the use of user mail logs and the SEND PARMLIB parameter

The OPERSEND, USERSEND, SAVE, and OPERSEWAIT operands do not affect security and can be set however your site pleases.

Creating Resource Rules for Each User Mail Log

The security administrator must create a resource rule to protect user mail logs.

Labeling User Mail Logs SYSHIGH

Because messages with various labels can be sent to a user, the security administrator should label each user log SYSHIGH by creating an MLS resource record. This is necessary only for mail logs created before write-down is prohibited (NOMLWRITE is set in the MLSOPTS record). After that, mail logs are labeled automatically when they are created. For example, the following record labels all user logs with SYSHIGH:

Creating Acid Record for *LISTBC ID

The security administrator should create an acid record for the *LISTBC acid. This acid is used by the *LISTBC command when it allocates a new mail log for a user. The *LISTBC acid should have the RESTRICT attribute. It must not have the JOB or TSO attributes, as these attributes might allow it to be used as an ordinary acid without a password. The following is an example of defining the *LISTBC acid to CA Top Secret:

Assigning a Security Label to the *LISTBC ID

The security administrator can assign security label SYSHIGH to the *LISTBC acid. However, since the *LISTBC ID enters the system as trusted, the system will assign it the SYSHIGH security label, by default. The *LISTBC ID is used by the LISTBC command processing to update individual user mail logs. It runs as a trusted process.

Creating an Access Rule for SYSl.BRODCAST

The security administrator should create an access rule for the SYSl.BRODCAST data set, to allow all users to read it. For example:

$KEY(SYSl)
TSS PER(all) DSN(sys1.broadcast)
             ACCESS(read)

This rule permits all users to read SYSl.BRODCAST, but prevents them from sending individual users messages there.

Assigning Security Label SYSLOW to SYSl.BRODCAST

Because all users can view messages in SYSl.BRODCAST, the security administrator should label it SYSLOW. For example:

TSS ADD(mls) DSN(sys1.broadcast)
             SECLABEL(SYSLOW)

Controlling Use of TRANSMIT and RECEIVE Commands

When a user issues the TRANSMIT command to send a data set to another user, the security label of the data set is the security label of the user issuing the TRANSMIT command. When the target user tries to issue the RECEIVE command, his security label must dominate the security label of the data set. If the security label of the target user does not dominate the security label of the data set, he will not receive any notice that a data set was sent to him. If the target user cannot specify a label that dominates the label of the data set sent to him, the system creates an SMF record when he tries to receive it.

Assigning Security Labels to LOG.MISC Data Sets

The LOG.MISC data set for a user contains information on TRANSMIT and RECEIVE command processing. In an MLS system, users who are authorized to use more than one security label should have a LOG.MISC data set for each security label.

In practice, security administrators should assign to a user's LOG.MISC data set the security label he uses most often. If a user wants to receive or transmit messages at a different security label, he must use the LOGDATASET or LOGDSNAME parameters of the RECEIVE and TRANSMIT commands.

When write-down is protected, a user can also label his own LOG.MISC data set by logging on at the security label he wants the data set to have, allocating the data set, then performing a TRANSMIT or RECEIVE.

Assigning Security Labels to NAMES.TEXT Data Sets

The NAMES.TEXT data set contains data that the RECEIVE and TRANSMIT commands can view or update. The security administrator should assign to the NAMES.TEXT data set for a user the lowest security label that the user can specify at logon. This lets the RECEIVE and TRANSMIT commands have access to the NAMES.TEXT data set and the user can update the data set when logged on at that lowest label.

When write-down is protected, the user can also label his own NAMES.TEXT data set by logging on at the security label he wants the data set to have, allocating the data set, then editing it.

Replacing Default IKJEFF53 Exit

To restrict users to using the CANCEL and OUTPUT commands only on jobs whose job names begin with their acids, a security administrator must replace the default IKJEFF53 exit with the IKJEFF53 exit in SYS1.SAMPLIB. The version of IKJEFF53 in SYS1.SAMPLIB suppresses the restriction of the CANCEL command if the JESJOBS class is active, and of the OUTPUT command, if the JESSPOOL class is active. This allows the command restriction to be done based on resource rules, rather than job names.

Example

When IKJEFF53 exit is replaced with the IKJEFF53 exit in SYS1.SAMPLIB, a user with an acid of USER01 could CANCEL jobs named USER01A or USER01TST, but could not cancel a job named USER02X.