In an MLS system, after defining and creating security levels, categories, and security labels, activating them, and assigning them to data and resources (classification), the security administrator must ensure that all users and work entering the system, including started tasks, batch jobs, processes, UNIX daemons, etc., are identified. Each user must be assigned a unique acid. In addition, all users entering the system are required to have security labels. A security administrator can assign security labels to users to give them the clearance they need to perform their work in the system.
The SECLABEL field of the USER acid record is used to assign security labels to users in an MLS environment. Depending on how you implement MLS at your site, you do not have to define a Seclabel for each system user. If MLS will impact only certain departments, or certain types of data, then most users can logon to CA Top Secret without specifying a security label and perform their jobs without any knowledge of MLS. The system will default a security label for the user.
TSS add(user01) seclabel(labela)
dfltslbl(labela)
TSS ADD(user01) SECLABEL(labela,labelb,labelaaa,syslow)
DFLTSLBL(syslow)
Note: If a security label is not specified by a user at signon and cannot be defaulted by the system from an existing acid record, SYSLOW will be assigned for the user.
The following table lists the default security labels that are recommended for special users in an MLS system.
|
User |
Default Security Label |
Reason for Security Label |
|---|---|---|
|
CA Top Secret Started Task |
SYSMULTI |
|
|
Console |
SYSHIGH |
|
|
JES2 or JES3 Started Task |
SYSMULTI |
|
|
OMVS Started Task |
SYSMULTI |
|
|
Security Administrator |
SYSHIGH |
At least one SCA acid with the MLSADMIN attribute should be assigned the SYSHIGH security label. |
|
Copyright © 2010 CA Technologies.
All rights reserved.
|
|