Security

My May column discussed how to review your installation’s protection of disk data sets, including whether the security software gets control, what happens if there’s no matching rule, and protection by both dsname and volser. Here I will provide further coverage of disk data sets, addressing undercutting rules in memory and user privileges that bypass data set protection.

Undercutting rules in memory serves to improve performance. By locking certain data set rules in memory, the security software avoids the need to read the data set rules from disk. Here we’re concerned with rules that grant data access that wouldn’t be evident by merely listing the data set rules in the security software. You will see that with all three security software packages, it’s common practice to grant a user complete access to any data set whose high-level qualifier is the userid.
     
RACF calls these in-memory rules GLOBAL rules, and stores them in the Global Access Table (GAT). You can see it as one of the reports produced by DSMON or by issuing the command RLIST GLOBAL DATASET. RACF GLOBAL rules for data sets use these masking or “wildcard” characters: % matches exactly one character; * matches a string of  zero or more characters for one or sometimes more than one node; ,** matches zero or more characters for zero or more nodes at the end of a dsname; &RACUID matches the userid of the user attempting the access; and &RACGPID matches the current connect group of the user attempting the access. In addition to the GLOBAL rules, RACF logic usually permits every user complete access to every data set whose high-level qualifier is his or her userid. 
     
CA ACF2 uses the RESTRICTIONS PREFIX field in the LID (user) record to give a user complete access to every data set with a specified high-level qualifier. This is almost always set to the value of the userid itself, but could conceivably be set to a value such as SYS1. Data set rules may be made resident in ACF2, as can be seen in the SHOW ALL report.
     
CA Top Secret stores the ALL record in memory to give all users permission to access certain data sets and disk volumes. A common usage is to use the ALL record to give each user complete access to all data sets where his or her userid is the high-level qualifier of the dsnname. You can see the ALL record by issuing TSS LIST(ALL)  DATA(ALL). Top Secret data set entries in the ALL record use the following masking or “wildcard” characters: * matches any one node or qualifier; + matches any one character; % matches the ACID (userid) of the user attempting access; and %42 matches the string of characters starting with the fourth character of the userid for a length of two characters.
     
All three security software packages have ways of giving users privileges that grant access to any data set in the system. In RACF, this is the OPERATIONS privilege that gives access (with some exceptions) to all data sets. Use the DSMON report to see which users have this privilege. This privilege has a scoped form called “group-OPERATIONS” or “connect OPERATIONS,” which applies to a subset of data sets and resources, based on the structure of the RACF group tree. The DSMON report shows which users have SYSTEM-wide OPERATIONS and which have group-OPERATIONS. DSMON also shows you the Group Tree Report.
     
In ACF2, the NON-CNCL privilege gives complete access to all data sets. In addition, if a user has the SECURITY privilege, and doesn’t have the RULEVLD attribute, then that user has complete access to all data sets. The READALL privilege lets a user read every data set. The MAINT privilege gives a user total access to any data set, but only through programs defined with the MAINT privilege. You can see who has these privileges by issuing these ACF2 sub-commands: LIST IF(NON-CNCL), LIST IF(SECURITY), LIST IF(RULEVLD), LIST IF(READALL), and LIST IF(MAINT).
     
In Top Secret, the NODSNCHK privilege gives a user complete access to all data sets. Further, the NOVOLCHCK gives complete access to all tape and disk volumes, which amounts to access to all data sets.
     
To evaluate the quality of your security implementation, you will need to pay attention to these ways users can access data sets without being permitted in the data set rules.
     
My next column will continue this discussion, addressing disk data set security for residual data and system data sets, and how to tell that the security rules are “right.” Future columns will address the security issues you need to understand involving tape data set protection.