Security

We continue our discussion of data set security by addressing security for tape data sets. Tape security is different from disk security in three respects: tape labels, tape management software, and the DEVSUPxx member of parmlib. 

Tape labels include both external (paste-on) labels and two types of internal labels (records written on the tape itself). Each tape cartridge is identified by a unique, six-character volume serial number (volser). This number is printed on the external label on the side of each cartridge in both eyeball-readable and bar code form.  

When your tape librarian receives a box of tapes from the manufacturer, the manufacturer has already written the first record on each cartridge. This is the internal volume label, which includes the same volser as on the paste-on label. When your program needs a tape data set, the system issues a mount message to the operator for that tape’s volser. When the operator (or a robot) mounts the tape, the system reads the volume label and checks that the volser number is correct. This protects against operators mounting the wrong tape.
     
The second internal label, the header label, provides security. It contains the dsname of the data set and is written on the tape just before the data set itself. When you read a tape data set, the system checks that both the volser in the volume label and the dsname in the header label are correct. This sort of checking is one reason the mainframe is considered more secure than distributed platforms.
     
You need to address two concerns regarding the security you get from label checking. The first is the ability to bypass the label processing, called BLP. Programmers make this happen by coding LABEL=(2,BLP) on the DD card for the data set. Any user who can do this can bypass security for all tape data sets. 
      
To illustrate this, suppose the master payroll file, named PROD.PAYROLL.MASTER.DATA, is on a tape whose volser is 123456. I have no business reading this data set, but I really want to know other peoples’ salaries. Suppose my userid is STU, and I code LABEL=(2,BLP),DSNAME=STU.DATA,VOL=SER=123456 on my DD card. The system has the operator mount the tape, but doesn’t verify the dsname is correct. When the security software is called, it sees that the high-level qualifier of the dsname is my userid, so it permits me to access the data. In this way, the ability to BLP lets me access any tape data set I want.
     
You use your security software to control who can BLP. If you don’t use the security software, then the ability to control BLP depends on settings in JES that are implicitly insecure. Of course, each security package has its own method to do this. RACF uses a FACILITY class rule named ICHBLP. (Note that RACF only uses this rule if the TAPEVOL class is active. Many RACF shops activate TAPEVOL without defining any rules in it.)
     
CA ACF2 controls the ability to BLP by use of a bit flag in the LID (logonid or userid) record named TAPE-BLP. CA Top Secret controls BLP by permitting to VOLUME rules with ACCESS(BLP).

The second concern regarding tape labels is the fact the header label has room for only 17 characters of the dsname, the rightmost 17 characters. Dsnames can have a maximum length of 44 characters. This introduces a security exposure unless you provide a way to control the full 44 characters of the dsname.

The exposure works like this. Suppose a data set named PROD.PAYROLL.MASTER.DATA is on the tape whose volser is 123456. My userid is STU and I want to read it. I code a DD card with
VOL=SER=123456,DSNAME=STU.PAYROLL.MASTER.DATA. The check of the dsname in the header label passes, since I make sure the rightmost 17 characters match. The security software gives me access based on the full 44-character dsname, whose high-level qualifier is my userid.

The solution almost everyone uses is to carry the full 44-character dsname someplace else: in the tape management software, which we will address in the next column.