Most users use a security label when they log on to the an MLS system. The rest of the time, security labels are read assigned an MLS system. Depending on what MLS options have been set by the security administrator, CA Top Secret will assign security labels to UNIX objects at the time they are created. A security administrator can also assign security labels to existing UNIX files and directories that do not have them. The following topics are discussed in detail:
When a user attempts to enter UNIX, CA Top Secret validates the user before initializing the shell, including validating the user associated with a program attempting to access resources and verifying that the user has specified a valid security label and is authorized to use it.
If the user is entering the system from a remote IP address and no security label has been specified at login, CA Top Secret will attempt to default a security label for the user from the user's port of entry (SERVAUTH class), if one exists. The user must have authorization to use the label that is defaulted by the system.
The su command can be issued to change the user ID associated with a session. It creates a new shell and allows the user who issued the command to operate in the shell with the privileges of a superuser or another specified user. In an CA Top Secret MLS system, the shell that is started by a user who issues the su command, inherits the security label of the user who issued the command, if the user has a security label. The security administrator must authorize the new user to the inherited security label, if the user has not already been authorized to it. For example:
|
User |
Security Label |
|---|---|
|
USERA |
SYSHIGH |
|
USERB |
SYSLOW |
USERA, whose session security label is SYSHIGH, issues the su command and specifies userid USERB on the command. The child shell that is started will then inherit SYSHIGH as its session security label. However, USERB has only been authorized to security label SYSLOW. Therefore, the security administrator must also give USERB authorization to security label SYSHIGH, as follows:
TSS ADD(userb) SECLABEL(syslow,syshigh)
DFLTSLBL(syslow)
UNIX controls access to files and directories based on their security labels as well as POSIX permissions and access control lists (ACLs). In addition, a user cannot access a classified file or directory if his security label does not permit the access according to MAC label dominance checking rules. Security labels are assigned to files and directories by the system at the time they are created and stored in the File Security Packet (FSP). Once a security label is assigned to a file or directory, it can never be changed. However, files and directories which were created in a zFS file system before MLS was activated, and therefore are not labeled, can be assigned security labels by a security administrator with the UNIX chlabel command.
If the MLS option to require security labels for UNIX files and directories is active (MLFSOBJ), all files and directories must have security labels; otherwise, all accesses to these objects will be denied by CA Top Secret.
UNIX allows connection between interprocess communication (IPC) objects only if their security labels are equivalent, according to MAC label dominance checking rules. Security labels are assigned to IPC objects by the system at the time they are created and stored in the ISP.
Note: The security label assigned to an IPC object is the security label of the process that created the connection.
Once a security label is assigned to an IPC object, it can never be changed.
If the MLS option to require security labels for UNIX IPC objects has been activated (MLIPCOBJ), all UNIX IPC objects must have security labels; otherwise, all requests to connect to an unlabeled process will be denied by CA Top Secret.
In an MLS system, all users and work entering the system (including started tasks, batch jobs, processes, UNIX daemons, etc.) must be identified. Each user must be assigned a unique acid. In addition, all users are assigned security labels by the security administrator or by CA Top Secret.
When the signal service sigqueue( ) is used, the security label of the signaling process must be equivalent to the security label of the target process, according to MAC label dominance checking rules.
When the ptrace service is used, the security label of the process that initiated ptrace must be equivalent to the security label of the target process, according to MAC label dominance checking rules.
To display the security label for his current address space, a user can issue the following UNIX command:
id -M
To display the security label of a UNIX file or directory, an authorized user can issue the following UNIX command:
ls -M filename
To display the security label of an IPC object, an authorized user can issue the following UNIX command:
ipcs -M
Once a UNIX user has been defined to CA Top Secret, the security administrator should assign security labels to each user, which will allow users access to the system and any classified resources they may need.
The security administrator should assign the OMVS started task the security label, SYSMULTI.
If a zFS file system will be used in the UNIX environment, the security administrator should assign the zFS started task the security label, SYSMULTI.
Users can logon to an MLS system with any one of multiple security labels that they have been authorized to use. As a result, a security administrator can allow a user to have a different home directory and shell program for each of their assigned security labels at logon by using the special symbolic links, $SYSSECA/ (absolute directory name) and $SYSSECR/ (relative directory name). Since a “symbolic link” is a file that contains the pathname for another file, whenever the symbolic link $SYSSECA/ or $SYSSECR/ is found in a pathname, the user's session security label is substituted by the system in place of that symbolic link in the pathname, either as an absolute directory name or as a relative directory name, depending on the symbolic link used ($SYSSECA/ or $SYSSECR/).
The following examples illustrate how security label substitution for special symbolic links works.
USERA has the following OMVS segment defined:
TSS ADD(userb) HOME(/u/symlnka/usera) OMVSPGM(/bin/sh) UID(0)
USERA's home directory (/u/users/secdev/usera) contains the symbolic link, $SYSSECA/, which was created with the following UNIX command:
Lin -s $SYSSECA /u/symlnka
Therefore, when USERA logs on with security label, LABELA, that label will be substituted into the following resolved home directory pathname as an absolute directory name:
/LABELA/usera
USERB has the following OMVS segment defined:
TSS ADD(userb) HOME(/u/symlnkb/userb) omvspgm(/bin/sh) UID(0)
USERB's home directory (/u/symlnkb/userb) contains the symbolic link, $SYSSECR/, which was created with the following UNIX command:
Ln -s $SYSSECR /u/symlnkb
Therefore, when USERB logs on with security label, LABELB, that label will be substituted into the following home directory pathname as a relative directory name:
/u/LABELB/userb
If a user logs on without a security label, a dot (.) will be substituted in place of the symbolic link ($SYSSECA/ or $SYSSECR/), and the pathname will be resolved either from the root or the current pathname, depending on the symbolic link used ($SYSSECA/ or $SYSSECR/).
USERC has the following OMVS segment defined and logs on without a security label:
TSS ADD(userc) HOME(/u/symlnka/userc) OMVSPGM(/bin/sh) UID(0)
USERC's home directory (/u/symlnkr/userc) contains the symbolic link, $SYSSECA/. Therefore, the following will be the resolved home directory pathname:
/./usera
If USERC's home directory (/u/users/secdev/userc), instead, contains the symbolic link, $SYSSECR/, the following will be the resolved home directory pathname:
/u/./usera
When MLS is not active, security label substitution is not performed and the symbolic links ($SYSSECA/ or $SYSSECR/) are left in the pathname as relative directory names.
Note: Security label substitution can also be used with automount.
WARNING! HFS only supports security label substitution when mounted in read-only mode; however, a zFS file system supports security label substitution in any mode.
|
Copyright © 2010 CA Technologies.
All rights reserved.
|
|