Security

This section details the security checks that are enabled by the ALLCALL option. In addition, many other sections of this manual contain a summary of security checks done by the operation described in that section.

All of the security checks described below are issued via the RACROUTE macro. RACROUTE issues a call to an z/OS component called System Authorization Facility (SAF), which routes the call to the active security system. This allows FDR to do security checking without needing to know which security system is involved. SAF is supported by IBM RACF, CA TOP SECRET, CA ACF2, and others.

FDR.NOALLCALL

The security administrator can create a profile named FDR.NOALLCALL in the FACILITY class under RACF, or the equivalent in other security systems. Most FDR operations that check the ALLCALL option also check for Read authority to a profile of FDR.NOALLCALL in the FACILITY class (those that do not are noted below). If this profile is defined, and the user does not have authority to it, then the user is not permitted to run without ALLCALL.

• If the profile is defined, and the user does not have Read authority, then FDR enforces ALLCALL security rules, even if the ALLCALL option is not enabled.
• If the profile is defined, and the user has Read authority, then FDR operates according to the setting of the ALLCALL option.
• If the profile is not defined, then FDR operates according to the setting of the ALLCALL option.

With this feature, the security administrator can cause FDR to enforce ALLCALL security, without depending on somebody else to set the ALLCALL option, and without worrying about multiple copies of the FDR load library that might have different option settings.

DASDVOL volume protection

FDR checks for a volume profile (CLASS='DASDVOL',ENTITY='volser') for most functions to see if the user is authorized to the entire volume; please read the following descriptions of security checks by FDR function for details.

We recommend that you establish DASDVOL volume profiles for all of your DASD volumes and authorize the user IDs that perform volume level operations (such as backups, COMPAKTions, and full-volume restores) with appropriate access to those profiles for two reasons:

1.In most cases, users must have appropriate authority to every data set being processed by FDR. When a large number of data sets are selected (such as a full-volume backup) the overhead to security check every one can be considerable. However, if the user is authorized to the entire volume under a DASDVOL profile, it is assumed that they have the same authority to every data set on the volume, so individual data set security checks are bypassed, greatly reducing that overhead. In these cases, since a failure of the DASDVOL check simply leads to individual data set checks, the DASDVOL check is issued with a parameter (LOG=NOFAIL) that suppresses any error messages or logging associated with it, since this could erroneously be interpreted as a security violation.

2.In some cases, the only security check done is a DASDVOL check, so for volumes that are not protected by a DASDVOL profile, any user is able to do the operation. These DASDVOL checks are done without LOG=NOFAIL, so potential security violations are logged.

IBM RACF users who use the GDASDVOL resource grouping class must insure that this option is in effect: SETROPTS RACLIST(DASDVOL)

For CA TOP SECRET and CA ACF2 users, consult vendor documentation for instructions on implementing DASDVOL class profiles.

If full-volume operations are done under a user ID with IBM RACF OPERATIONS authority (or the equivalent in other security systems), then the user ID appears to have DASDVOL authority for all volumes. This may be preferable to creating DASDVOL profiles.

When a user does not have READ authority to the DASDVOL class for the source volume, the RESTORE from the offline volume gets the message:

FDR021** RACF DATASET PROTECTION FAILED ON DSN=<original data set name>

However, if the user has READ authority to the DASDVOL class for the source volume, then the RESTORE is treated like a COPY and they are able to restore any data set to a new name.

STGADMIN (Storage Administrator) authority

As an alternative to defining DASDVOL profiles, you can use special Storage Administrator authority to bypass all of the individual security checks done by FDR and by IBM components called by FDR. To use Storage Administrator authority:

• You must specify the operand STGADMIN on the DUMP, RESTORE, COPY, or PRINT statement. STGADMIN is accepted only in programs FDR, FDRDSF, FDRCOPY, FDRABR, FDRFLASH, and FDRSNAP. For example: DUMP TYPE=FDR,DATA=USED,STGADMIN.
• FACILITY class must be active in your security system.
• The user under which the FDR operation is executed must have READ access to the appropriate profile in the FACILITY class (as listed below).

If all of the above are true, then no further security checks are done by any FDR component or by any IBM component invoked by FDR (such as allocation or catalog). If STGADMIN is specified but the user does not have authority to the profile or the profiles are not defined, the FDR step fails.

The FACILITY class profiles checked by the STGADMIN operand are:

STGADMIN.ADR.STGADMIN.COPY

Lets you copy data sets without having access authority to the source (READ) or target (UPDATE or ALTER) data sets and their catalogs.

STGADMIN.ADR.STGADMIN.DUMP

Lets you dump data sets without having READ access to the data sets.

STGADMIN.ADR.STGADMIN.PRINT

Lets you print data (with FDRDSF) without having READ access to the data sets containing the data to be printed.

STGADMIN.ADR.STGADMIN.RESTORE

Lets you restore data without having READ, UPDATE, or ALTER access to source and target data sets and their catalogs.

The STGADMIN operand applies to DASD volumes used as input on DUMP or COPY and as output on RESTORE or COPY. It has no effect on security checking for backup data sets.

If Transparent Cloud Tiering (TCT) is being utilized with FDR, additional security definitions are required. These definitions are documented in Configure the FDRTCT User and Define Security Definitions in Installation-Checklist.

Other than these STGADMIN.ADR security profiles listed in this section, all other STGADMIN security calls are performed outside of the FDR operation and would need the appropriate permissions for the functions being performed by the user. For a complete list of STGADMIN profiles performed by z/OS, see z/OS DFSMSdfp Storage Administration. For example, if the user is performing a DELETE NOSCRATCH on an entry in the catalog, they would need READ access to STGADMIN.IGG.DELETE.NOSCRTCH as defined in the aforementioned documentation.

DUMP TYPE=FDR

For full-volume backups under FDR or ABR, FDR first checks for READ authority to the input DASD volume with:

RACROUTE REQUEST=AUTH,APPL='FDR',CLASS='DASDVOL',ENTITY=volser,ATTR=READ

If a DASDVOL profile does not exist for the volume, or the user is not authorized under the DASDVOL profile, FDR then checks for READ authority to every data set on the volume with:

RACROUTE REQUEST=AUTH,APPL='FDR',CLASS='DATASET',ENTITY=dsname,
VOL=volser,ATTR=READ

If the user is not authorized to read every data set on the volume (either individually or globally via DASDVOL), the backup is terminated. Since full-volume backups always backup every data set on the volume, there is no facility to skip unauthorized data sets.

RESTORE TYPE=FDR

For full-volume restores under FDR or ABR, FDR checks for ALTER authority to the output DASD volume with:

RACROUTE REQUEST=AUTH,APPL='FDR',CLASS='DASDVOL',ENTITY=volser,ATTR=ALTER

If a DASDVOL profile exists for that volume, and the user is not authorized to alter the volume, the restore is terminated. No individual data set checking is performed.

The user’s authority to read the DASD volume that was backed up is checked by opening the backup file (see Additional Security Considerations in Security).

COPY TYPE=FDR

For full-volume copies, FDR performs the same checks as DUMP TYPE=FDR on the input volume and the same checks as RESTORE TYPE=FDR on the output volume.

COMPAKTOR

For COMPAKT TYPE=FASTCPK and TYPE=RELEASE, COMPAKTOR checks for ALTER authority to the volume being processed with:

RACROUTE REQUEST=AUTH,APPL='FDR',CLASS='DASDVOL',ENTITY=volser,ATTR=ALTER

If a DASDVOL profile exists for that volume and the user is not authorized to alter the volume, the operation is terminated. No individual data set checking is performed.

For an old-style COMPAKTion from a backup data set (COMPAKT TYPE=CPK, which is the default) COMPAKTOR does the same DASDVOL check on the output volume as described above. For a DUMP=NO COMPAKTion (from an existing backup) this is again the only check done. However, if an FDR backup is taken as part of the CPK run (the DUMP=YES operand to invoke an FDR backup, or the COMPAKT option on an FDR or ABR full-volume backup); the FDR backup performs the checks described above for DUMP TYPE=FDR on the input volume (usually the same as the output volume); this includes individual data set checks for READ authority if the user does not have DASDVOL authority to the entire input volume.

DSF absolute track operations

When the FROM/TO operands are used in FDRDSF or FDRCOPY to access tracks by their absolute address, FDR checks for authority to the volume with:

RACROUTE REQUEST=AUTH,APPL='FDR',CLASS='DASDVOL',ENTITY=volser,ATTR=access

where “access” is READ for DUMP and PRINT and for the input volume on COPY and is ALTER for RESTORE and for the output volume on COPY. If a DASDVOL profile exists for the volume being accessed, and the user does not have the requested access authority, the operation is terminated. FDR does not attempt to determine what data sets the requested tracks belong to, or to perform checking at the data set level.

If the installation decides that this approach does not provide adequate security, then absolute track operations can be disabled completely, as discussed under NOABSTRK in Security-Options.

DUMP TYPE=DSF / ABR / AUTO / APPL

For all DSF and ABR data set backups (including application backups), FDR first checks for READ authority to the input DASD volume with:

RACROUTE REQUEST=AUTH,APPL='FDR',CLASS='DASDVOL',ENTITY=volser,ATTR=READ

If the user is authorized, the dump proceeds with no further checking. If a DASDVOL profile does not exist for the volume, or the user is not authorized under the DASDVOL profile, FDR then checks for READ authority to each data set that is selected for backup with:

RACROUTE REQUEST=AUTH,APPL='FDR',CLASS='DATASET',ENTITY=dsname, VOL=volser,ATTR=READ

Any data sets that the user is not authorized is bypassed (not backed up). All authorized data sets and all unprotected data sets are processed.

DUMP TYPE=ARC and TYPE=SCR

For ABR Archive and Superscratch, FDR does the same checks as for DUMP TYPE=DSF described above, except that the requested access authority is ALTER since the data set is scratched.

However, DUMP TYPE=ARC,SCRATCH=NO is an application backup, equivalent to DUMP TYPE=APPL, so the requested access authority is READ.

RESTORE TYPE=DSF / ABR / ARC / APPL to the same name

For all DSF and ABR data set restores, FDR first checks for UPDATE authority to each output DASD volume with:

RACROUTE REQUEST=AUTH,APPL='FDR',CLASS='DASDVOL',ENTITY=volser,ATTR=UPDATE

If a data set being restored does not exist on DASD before the restore, then FDR requests that the Operating System create the data set. The Operating System checks for CREATE authority at the data set level, whether or not the user has DASDVOL authority and regardless of what security options the installation has activated within FDR. If the user is authorized to create the data set, FDR assumes they must be authorized to write to it; therefore, FDR does not issue its own security check.

If a data set being restored does exist on DASD before the restore, and a DASDVOL profile does not exist for the volume, or the user is not authorized under the DASDVOL profile, then FDR checks for UPDATE authority to the data set with:

RACROUTE REQUEST=AUTH,APPL='FDR',CLASS='DATASET',ENTITY=dsname, VOL=volser,ATTR=UPDATE

If a particular data set fails the security checks, that data set is bypassed, but other requested data sets may still be restored.

If the restore is an automatic recall of an archived data set, then additional options are available to modify the security checks. For example, you can allow the restore even though the user has only READ authority so that data sets can be recalled and read, or you can allow the restore even though the user has no authority to the data set. For details, see ABR-Auto-Recall-Security.

RESTORE TYPE=DSF / ABR / ARC / APPL to a new name

When restoring data sets to a new name, FDR checks authority to both the original data set (to verify authority to read that data set) and output data set (to create or update it). READ authority to the original data set name on the original volume serial is checked with:

RACROUTE REQUEST=AUTH,APPL='FDR',CLASS='DATASET',ENTITY=dsname, VOL=volser,ATTR=READ

If the user is not authorized to the original name or the data set is not protected on the current system, FDR does not restore the data set. Other data sets requested in the same run are still restored.

The reason why FDR fails the restore if the original DSNAME is unprotected (return code 4 from RACROUTE indicating no profile exists) is that it is possible that the data set was protected by a profile at the time it was backed up, and that the user running the restore would not have been authorized under that profile, but the profile has since been deleted or the restore is running on a different system. At the time of the restore, FDR cannot tell whether the data set was protected at the time of the backup. So if the input data set is not currently protected, the restore is disallowed. However, this means that if a data set has never been protected, FDR does not allow anyone to restore it to a new name; if you have unprotected data sets in your installation, contact BMC Support for assistance.

No checking is done for a DASDVOL profile for the volume from which the data set was backed up; so if the user has authority under a DASDVOL profile for the original volume, he must still have to have authority under a data set profile for the original DSNAME in order to restore the data set to a new name.

If the user is authorized to read the original data set name, FDR checks security for the output volume and the new name of the output data set as described in RESTORE TYPE=DSF / ABR / ARC / APPL to the Same Name.

ABR Auto-Recall

For auto-recall, there are additional security options in addition to those described above. See ABR-Auto-Recall-Security.

COPY and MOVE

FDRCOPY is essentially a dump and a restore in one task, so its security checks are essentially those described above for data set backups and restores.

For an FDRCOPY COPY operation, the input volume and data sets are checked as described in DUMP TYPE=DSF / ABR / AUTO / APPL. The output volume and data sets are checked as described in RESTORE TYPE=DSF / ABR / ARC / APPL to the Same Name.

For an FDRCOPY MOVE operation, since the input data set is scratched, FDRCOPY first checks for ALTER authority to DASDVOL on the input volume; if the user does not have that authority, it checks for ALTER authority to the data set itself. This is the same as the checks described in DUMP TYPE=DSF / ABR / AUTO / APPL except that ATTR=ALTER. The output volume and data sets are checked as described in RESTORE TYPE=DSF / ABR / ARC / APPL to the Same Name.

On a COPY or MOVE to a new name, the input data set is checked according to the rules just described. The special rules described in RESTORE TYPE=DSF / ABR / ARC / APPL to a New Name do not apply.

FDRABRM

FDRABRM is the ABR VTOC maintenance utility that sets DASD volume processing options for ABR. Under ISPF, it is invoked by option A.I.8. FDRABRM supports the ALLCALL option, but it does not yet support the FDR.NOALLCALL security profile.

FDRABRM first checks for ALTER authority to the DASD volume with:

RACROUTE REQUEST=AUTH,APPL='FDR',CLASS='DASDVOL',ENTITY=volser,ATTR=ALTER,LOG=NOFAIL

If a DASDVOL profile exists and the user is not authorized under the DASDVOL profile, FDRABRM terminates processing of that volume. No security violation message appears on the job log, but an error message appears in the SYSPRINT listing.

If the user is authorized under the DASDVOL profile or there is no DASDVOL profile, FDRABRM then checks for ALTER authority on the ABR Model DSCB with:

RACROUTE REQUEST=AUTH,APPL='FDR',CLASS='DATASET',ENTITY=dsname, VOL=volser,ATTR=ALTER

FDRABRM then checks for ALTER authority to every data set on the volume with:

RACROUTE REQUEST=AUTH,APPL='FDR',CLASS='DATASET',ENTITY=dsname, VOL=volser,ATTR=ALTER

If the user is not authorized to alter every data set on the volume (either individually or globally via DASDVOL), the VTOC update is terminated.

ABR remote queue operations

In ABR, requests for backups, archives, and restores can be added to “remote queues” by end users. Later, those remote queue requests are processed by a job submitted by the data center or some other central group. Requests are added by the ABR Remote Queue Utility (FDRABRUT), which can be invoked directly by a user, by an ISPF dialog, or by an ABR auto-recall for a TSO user. FDRABRUT supports the ALLCALL option, but it does not yet support the FDR.NOALLCALL security profile.

The security checks described below are done under the user ID of the requesting user, to verify that the user has the required authority to the data sets they are requesting.

The jobs that process the remote queues are usually run under a user ID associated with Operations. Since the normal checks for backups, restores, and archives described earlier are done, that job must be authorized to all volumes or data sets that the users have added to the remote queues.

ABR remote queue backup or archive

If DISKUPDATE=YES is in effect (see DISKUPDATE in ABR-Options), then the Remote Queue Utility (FDRABRUT) or the ABR ISPF dialog, before setting the Update indicator or ARCHIVE indicator in the DSCB, checks for authority to the volume with:

RACROUTE REQUEST=AUTH,APPL='FDR',CLASS='DASDVOL',ENTITY=volser,ATTR=access

Where “access” is READ if all of the commands for a given volume are BACKUP or RESET BACKUP, or ALTER if at least one of the commands for the volume is ARCHIVE or RESET ARCHIVE. If a DASDVOL profile does not exist for the volume, or the user is not authorized under the DASDVOL profile, then authority to each data set that is selected is checked with:

RACROUTE REQUEST=AUTH,APPL='FDR',CLASS='DATASET',ENTITY=dsname, VOL=volser,ATTR=access

Where “access” is:

READ

if the command for that data set is BACKUP or RESET BACKUP, or

ALTER

if the command is ARCHIVE or RESET ARCHIVE.

If DISKUPDATE=NO is in effect, then the Remote Queue Utility or the ABR ISPF dialog, before adding the request to a Remote Queue data set, does not check for volume authority, but checks authority to each data set that is requested to be processed with:

RACROUTE REQUEST=AUTH,APPL='FDR',CLASS='DATASET',ENTITY=dsname, VOL=volser,ATTR=access

Where “access” is READ if the command for that data set is BACKUP or RESET BACKUP, or ALTER if the command is ARCHIVE or RESET ARCHIVE. If the data set is not cataloged and VOL is not specified by the user, then the request fails since the volume serial is unknown. If DISKUPDATE=NO is in effect and ALLCALL is enabled then only requests for fully-qualified data set names are allowed because proper security checking cannot be done if DSG= or DSN=mask is used; VOLG= is also disallowed for the same reason.

If a particular data set fails the security checks, that data set is bypassed, and other requested data sets may still be processed.

ABR remote queue restore

Remote queue restore requests are always processed by adding the request to a Remote Queue data set. The Remote Queue Utility or the ABR ISPF dialog, before adding the request checks data sets with:

RACROUTE REQUEST=AUTH,APPL='FDR',CLASS='DATASET',ENTITY=dsname, VOL=volser,ATTR=access

It checks the original DSNAME on the original volume serial with “access” of READ.

If the user specified a new output data set name or a new volume serial, RACROUTE is also issued for the new data set with “access” of ALTER. If a profile exists for the new data set, then FDR required that a profile exist for the original data set also. If the original data set is not cataloged and VOL is not specified, or if the new data set is not cataloged and NVOL= is not specified, then the request fails. If ALLCALL is enabled then only requests for fully-qualified data set names are allowed because proper security checking cannot be done if DSG= or DSN=mask is used; VOLG= is also disallowed for the same reason.

If a particular data set fails the security checks, that data set is bypassed, and other requested data sets are still processed.

FDRREORG

FDRREORG supports the ALLCALL option. It supports the FDR.NOALLCALL security profile for PDS' data sets, but does not yet support it for VSAM or IAM.

For IAM and VSAM files that it processes, FDRREORG checks for authority with:

RACROUTE REQUEST=AUTH,APPL='FDR',CLASS='DATASET',ENTITY=dsname, VOL=volser,ATTR=ALTER

A REORG of a PDS with FDRREORG (or an FDRCOPY “REORG TYPE=DSF”) requires UPDATE authority to the volume or the PDS, the same as defined in RESTORE TYPE=DSF / ABR / ARC / APPL to the Same Name.

In addition, FDRREORG uses dynamic allocation and OPEN:

• To create and open its backup and log data sets, using names defined by FDRREORG parameters and defaults (see SET-FDRREORG-Options). It must have CREATE authority to those data sets.
• For the VVDS on every volume containing VSAM being reorganized. It requires READ authority to the SYS1.VVDS.Vvolser data sets.

These checks are done by the operating system, so these authorizations are required even if the ALLCALL option is not in effect.

Additional security considerations

Normal opens are done on backup data sets, so OPEN checks that the user has authority to create the backup for DUMP statements and to read the backup on RESTORE statements. The STGADMIN operand has no effect on security checking for backup data sets. However, security checking for tapes and tape data sets may be optional so check your security system documentation for details on tape security. You may wish to restrict most users from reading backup data sets by protecting the backup data set names.

When the ABR DADSM Preprocessing exit is installed, it bypasses IBM RACF and CA TOP SECRET security checking when it catalogs entries into the ABR SCRATCH catalog. CA ACF2 users must either install the ACF2 VLDEXIT prevalidation exit ABRVALD (supplied by Broadcom, and documented in the CA ACF2 Other Products manual), or be authorized to create entries in the ABR SCRATCH catalog, that is, they must be authorized to catalog data set names starting with “#.”.

For all of the security checking described in this section, FDR supports both “discrete” and “generic” RACF security profiles. Although generic profiles are used in most IBM RACF installations, discrete profiles (one per data set) may still be in use. Discrete profiles may be automatically deleted when the data set is deleted, and FDR does not preserve discrete profile information on its backups, so when a data set that was protected by a discrete profile is restored by FDR, a “default” discrete profile is created for it, granting access only to the user doing the restore; this profile may require manual updating.

We recommend that the profile or security rule protecting a data set or volume should not be deleted as long as any copy of that data set or volume exists on a backup or ARCHIVE tape.

FDR jobs that use HFS=QUIESCE to quiesce HFS file systems and ZFS=QUIESCE to quiesce zFS file systems must be authorized to use z/OS UNIX services. For details, see Hierarchical File System (HFS) and zSeries File System (zFS) in FDR-Processing-by-Type-of-Data-Set.

Restricting program access

IBM RACF has a feature called Program Access to Data Sets (PADS) that can restrict the program names that can open particular data sets; other security systems have a similar feature (sometimes called “program pathing”). To limit access to certain data sets to FDR programs, you need to define rules that allow only programs starting with FDR to open them. PADS requires that every program loaded at the time the file is opened be explicitly listed; if you wish to use PADS to restrict access to certain data sets to FDR programs, you can define every program in the FDR program library which starts with FDR (plus IGG019YZ), or contact BMC Technical Support for a list of modules used for specific functions. Other security systems may be able to conveniently define rules for generic FDR* programs; check your security documentation.

FDR and ABR backups contain the data from many data sets. You may need to grant users READ authority to those backups in order to restore data sets to which they are authorized, but you do not want them to be able to open or browse the backup data so that they cannot see non-authorized data sets. Therefore, you may wish to restrict access to backup data sets to FDR programs. You can eliminate the need to give READ authority to users for ABR backups by setting options so that all recalls and restores are done in the background or via Remote Queues.

The Archive Control File and Encryption Keyfile are additional FDR control data sets that should be secured with specific program access as these data sets act like databases to restore archived data sets and restore encrypted backups. Only a limited set of FDR programs should be allowed to have UPDATE authority to these data sets. Contact BMC Support for a list of modules used for these specific functions.

Users who are allowed to restore data sets from ARCHIVE need UPDATE authority to the Archive Control File (to set a “restored” flag), but you may want to restrict them to reading or updating the Control File with FDR programs.

Users who add requests to the ABR Remote Queue data sets require UPDATE authority to them, but you may want to restrict them to reading or updating the Remote Queues with FDR programs. It may also be possible to bypass security checking during the Remote Queue updates; contact BMC Support for details.