May 14 ’12

Mainframe Security: Data Set Protection

by Stu Henderson in z/Journal

In previous columns, I described a structured approach to evaluating your mainframe security, starting with controls over access to the system. I also described how your security software (RACF, ACF2, or Top Secret) can control system access for each of several paths, including TSO, started tasks, and batch jobs.

Let’s now turn to security software protection of data sets, starting with disk data sets. You will see that a thorough evaluation of file security requires more than just a review of the data set rules in the security software. To verify the exceptional settings described here, you will want to review standard reports of option settings. For RACF, these include SETR LIST and DSMON. For ACF2, review SHOW ALL.

For Top Secret, review TSS MODIFY(STATUS(BASE,CPF,FACMODE,JES,PASSWORD,PHRASE,SYSPLEX,VERSION)).

Several factors affect our ability to claim that all disk data sets are properly protected, including whether the security software gets control; what happens if there’s no matching rule; protection by dsname vs. by volser; undercutting rules in memory; user privileges that bypass data set protection; residual data; system data sets and logging; and how we can tell the security rules are “right.” There are slight differences in the ways RACF, ACF2, and Top Secret address these factors.

In general, the security software gets control for every data set access, since IBM modified the logic of OPEN and other system functions decades ago to invoke SAF, which invokes the security software. However, the security software either doesn’t get control or doesn’t enforce the rules in the following cases:

 

 

You can see how each of these options is set by reviewing the standard reports listed above.

Once the security software gets control, there may be no security if there’s no data set rule whose name matches the name of the data set. With RACF, this is controlled by the PROTECTALL switch. (RACF allows data set access when there’s no matching rule unless PROTECTALL is active, in which case RACF denies access.) With ACF2, if the data set exists on a disk pack that isn’t defined in either the SECVOLS or the RESVOLS list, the data set isn’t protected. Otherwise, ACF2 fails data set access attempts that have no matching rule. With Top Secret, if the MODE is set to FAIL, then access attempts to data sets with no matching data set rule and no matching VOLUME rule are failed.

When the security software is deciding whether to permit a data set access, the software may decide on the basis of either the dsname of the data set (matched against data set rules in the security software) or the volume serial (VOLSER) number of the disk pack the data set resides. (The VOLSER is a unique number that identifies each disk pack and each tape cartridge.)

RACF makes its decision almost exclusively on the basis of dsname. (The exception is discrete data set rules, which you want to avoid using. Discrete data set rules let you provide different sets of permission, depending on which VOLSER a data set resides on. However, discrete data set rules have so many implementation problems they’re best avoided.)

ACF2 determines which disk pack the data set resides on and then compares the VOLSER of that disk pack to the RESVOLS and the SECVOLS lists. If the VOLSER is on the RESVOLS list, then ACF2 compares the dsname to the matching data set rule. Otherwise, if the VOLSER is on the SECVOLS list, then ACF2 compares the VOLSER to a special type of data set rule that represents the disk pack. If the VOLSER is on neither list, then ACF2 allows the access.

Top Secret compares the VOLSER to the matching VOLUME permissions in the Top Secret database. If they permit the access, then the access will usually be allowed, regardless of the data set rules. Otherwise, Top Secret uses the data set permissions based on the dsname of the data set.

My next column will continue this discussion of how to evaluate how well your disk data sets are protected on the mainframe.