Security Labels: An Example

Figure 1 shows how to set up security labels to meet the following needs:
  • Projects on the same system cannot access each other's data
  • Projects on the same system have access to common data (such as tools or data that they need read access to, but not write access)
In this example, there are two projects, A and B. Each project has one category (categories A and B). (While each project can have more than one category, it is simpler to show only one for each project.)
The system has four security levels:
  • REG (registered, currently the highest security level on the system)
  • RES (restricted)
  • CON (confidential)
  • INT (internal)
To give each of the two projects access to common data, do one of the following:
  • If the SETROPTS MLACTIVE option is in effect, create a third security category (called COMCAT). When you create security labels, include the common category in security labels to allow users logged on at those security labels to read common data.

    Create a security label at the lowest defined security level (INT) that includes a third security category (COMCAT).

  • If the SETROPTS MLACTIVE option is not in effect, assign no security label to profiles protecting the common data.

Data at the lowest security level (INT) within a particular project is shown primarily to show the effect of creating security labels that include no category for common data.

Figure 1. Security Labels: An Example

Security
Levels        Project A        COMCAT         Project B
              +------------------------+
REG/30        | REGA                   |
              +------------------------+
                             +------------------------+
                             |                   REGB |
                             +------------------------+
              +------------------------+
RES/20        | RESA                   |
              +------------------------+
                             +------------------------+
                             |                   RESB |
                             +------------------------+
              +------------------------+
CON/20        | CONA                   |
              +------------------------+
                             +------------------------+
                             |                   CONB |
                             +------------------------+

INT/10        +------+        +--------+       +------+           
              | INTA |        | COMLBL |       | INTB |
              +------+        +--------+       +------+ 

----------
- SYSLOW -
----------
Note:
  1. SYSHIGH includes security level REG and categories A, B, and COMCAT.
  2. SYSLOW includes security level INT and no categories.
Note: The following commands assume that the security levels and categories have already been defined.
Commands to Define Security Labels for Project A: 
RDEFINE SECLABEL REGA SECLEVEL(REG) ADDCAT(A COMCAT) UACC(NONE)

RDEFINE SECLABEL RESA SECLEVEL(RES) ADDCAT(A COMCAT) UACC(NONE)

RDEFINE SECLABEL CONA SECLEVEL(CON) ADDCAT(A COMCAT) UACC(NONE)

RDEFINE SECLABEL INTA SECLEVEL(INT) ADDCAT(A) UACC(NONE)
Commands to Define Security Labels for Project B: 
RDEFINE SECLABEL REGB SECLEVEL(REG) ADDCAT(B COMCAT) UACC(NONE)

RDEFINE SECLABEL RESB SECLEVEL(RES) ADDCAT(B COMCAT) UACC(NONE)

RDEFINE SECLABEL CONB SECLEVEL(CON) ADDCAT(B COMCAT) UACC(NONE)

RDEFINE SECLABEL INTB SECLEVEL(INT) ADDCAT(B) UACC(NONE)
Command to Define the Common Security Label: 
RDEFINE SECLABEL COMLBL SECLEVEL(INT) ADDCAT(COMCAT) UACC(NONE)

Commands to Assign Security Labels to Users:

Security administrator (a SPECIAL or group-SPECIAL user): 
ALTUSER ADMIN SECLABEL(SYSHIGH)
A team leader has access to all security labels, but usually logs on to the highest security label in his or her project (REGA): 
ALTUSER  LEADERA  SECLABEL(REGA)

PERMIT  (REGA RESA CONA INTA)  CLASS(SECLABEL)  ID(LEADERA)  ACCESS(READ)
A newly hired worker has access only to the lowest security label in his or her project: 
ALTUSER  WORKERA  SECLABEL(INTA)

PERMIT  INTA CLASS(SECLABEL)  ID(WORKERA)  ACCESS(READ)
Note: Similar commands are issued for project B users.
Commands to Assign Security Labels to Data for Project A: 
ALTDSD  'GROUPA.REGA.**'  SECLABEL(REGA)
ALTDSD  'GROUPA.RESA.**'  SECLABEL(RESA)
ALTDSD  'GROUPA.CONA.**'  SECLABEL(CONA)
ALTDSD  'GROUPA.INTA.**'  SECLABEL(INTA)

RALTER  VMMDISK  GROUPA.294  SECLABEL(REGA)
RALTER  VMMDISK  GROUPA.293  SECLABEL(RESA)
RALTER  VMMDISK  GROUPA.292  SECLABEL(CONA)
RALTER  VMMDISK  GROUPA.291  SECLABEL(INTA)
Note: Similar commands are issued for project B data.
Commands to Assign Security Labels to Common Data: 
ALTDSD  'COMMON.DATA' SECLABEL(COMLBL)

RALTER  VMMDISK  COMMON.191  SECLABEL(COMLBL)

What Users Can Do Based on Security Label Authorization Checking (SETROPTS NOMLS in Effect):

Note: Other authorization requirements, such as access lists and UACC, can prevent users from accessing data. This figure is limited to the controls enforced by security label authorization checking (with the SECLABEL class active and the SETROPTS NOMLS option in effect).

Users who log on with project A security labels can only view data with security labels REGA, RESA, CONA, INTA, and COMLBL.

Users who log on with project B security labels can only view data with security labels REGB, RESB, CONB, INTB, and COMLBL.

Note that data with security label COMLBL can be seen by users in either project A or project B.

Users logged on with a particular security label:
  • Can read or update data with lower security labels in that project, plus COMLBL
  • Cannot read data with higher security labels in that project.
For example, users logged on with security label RESA can:
  • Read or update data with security label RESA, CONA, INTA, and COMLBL
  • Cannot read data with security label REGA.
Note: INTA represents something of a special case. Because the INTA security label is not defined to include the COMLBL category, users who log on with the INTA security label can only access data with the INTA security label.

What Users Can Do Based on Security Label Authorization Checking (SETROPTS MLS(FAILURES) in Effect):

Note: Other authorization requirements, such as access lists and UACC, can prevent users from accessing data. This figure is limited to the controls enforced by security label authorization checking when the SECLABEL class is active and the SETROPTS MLS(FAILURES) option is in effect.

Users who log on with project A security labels can only view data with security labels REGA, RESA, CONA, INTA, and COMLBL.

Users who log on with project B security labels can only view data with security labels REGB, RESB, CONB, INTB, and COMLBL.

Note that data with security label COMLBL can be seen by users in either project A or project B.

Users logged on with a particular security label:
  • Can update data with that security label
  • Can read data with lower security labels in that project, plus COMLBL
  • Cannot read data with higher security labels in that project.
For example, users logged on with security label RESA can:
  • Update data with security label RESA
  • Read data from lower security labels in that project: CONA, INTA, and COMLBL
  • Cannot read data with security label REGA.
Note: INTA represents something of a special case. Because the INTA security label is not defined to include the COMLBL category, users who log on with the INTA security label can only access data with the INTA security label.