SDSF and SAF Security
By Syd Hutchinson

With the release of JES2 3.1.3 and SDSF 1.3, IBM has shown how it plans to use
the System Authorization Facility (SAF) in its program products. This article
discusses the implementation of SAF security with the new release of SDSF, some
problems that you may encounter with the new release, and current and future
solutions to these problems.

The System Authorization Facility

SAF is a relatively new feature of the MVS environment that can be used to
centralize security system processing. It functions as a gateway by receiving
security requests from the MVS router and passing them on to a security package
(CA-ACF2, CA-Top Secret, RACF) for validation. SAF and the MVS router are part
of all MVS/SP systems, whether a security package is present or not.
Each security package has its own method of determining which SAF calls it will
process and which it will ignore. RACF requires an entry in the RACF router table
(ICHRFR0X and ICHRFR01) and the RACF class descriptor table to process the
request, as does CA-Top Secret (their versions of these tables). For CA-ACF2,
there must be a SAF PROTECT and a SAFMAP record defined in the global system
options to process the request. The RACF router table and SAF PROTECT record tell
the security system to process this SAF request, and the class descriptor table
and SAFMAP record convert the SAF request to a RACF, CA-Top Secret, or CA-ACF2
request.
The biggest benefit that SAF provides is a standardized method for third-party
software to use the security system. Installation of security products,
administration of security software and reporting of security events should all
become much easier as vendors take advantage of SAF and eliminate their own
proprietary methods.

Installing SAF Support

SAF support is included as part of the base SDSF product. Prerequisites for SAF
security are MVS 3.1.3, JES2 3.1.3 and RACF 1.9 (or its CA-ACF2 or CA-Top Secret
equivalent).

Activating SAF Security

SAF security for SDSF is activated by telling the security package  to process
SAF security calls from SDSF. There are four classes that need to be activated
to do this:
JESSPOOL: controls access to jobs, output, SYSIN and SYSOUT data sets on the
ST, DA, H, I and O panels.
OPERCMDS: controls access to commands (JES2 and MVS) that are generated by
entering action characters and overtyping fields.
SDSF: controls access to SDSF panels, the ability to issue console commands (/
authority), initiators, destination names and operator authority.
WRITER: controls access to printers.
These classes are activated in CA-ACF2 by inserting the following global system
option (GSO) record:

SAFPROT CLASS(JESSPOOL OPERCMDS SDSFWRITER) CNTLPTS(ISF-) SUBSYS(ISFMAIN-)
CA-ACF2 also requires you to map classes with names longer than three characters
to a CA-ACF2 resource type. This is done with the SAFMAP GSO record.
These classes are activated in RACF by issuing the following RACF command:
SETROPTS CLASSACT(JESSPOOL OPERCMDS SDSF WRITER)
Generic processing should also by activated for these classes with the RDEFINE
command.
Chapter 5 of the System Display and Search Facility Guide and Reference, Release
3.1 (SC23-0408-5) provides all of the information necessary to write CA-ACF2
resource access rules or define RACF or CA-Top Secret security profiles. You will
probably have to read it twice to really understand how it works. I have two
suggestions for those using SAF for the first time.
The rules (or profiles) required to protect SDSF resources are complicated. For
example, to update the output class on a job on the hold queue, you must have
access to the H panel (SDSF class), be able to access that job (JESSPOOL class),
and be able to issue the appropriate JES2 command (OPERCMDS class). Therefore,
keep your rules (or profiles) as simple as possible.
Use the samples provided in the SDSF Guide and Reference (Chapter 5, Section
II, þMigrationþ) as a starting point for establishing access rules (or profiles),
and then customize the privileges to your environment. This method gets you 80
percent of the way there with 20 percent of the effort.
Migrating to SAF also provides a good opportunity to review the SDSF access
privileges that have been assigned previously, since a much finer level of
control is now available. Also, auditing and reporting that was not previously
available can be used to let data center management know what events are
occurring in SDSF.
Problems With SAF and SDSF
Once the initial rules (or profiles) are established, everything will appear to
be working as planned. However, in the test environment, there are probably just
a bunch of systems programmers using the new system. With their security
privileges, it may be difficult to notice any problems. Upon further testing with
operator, programmer or end-user privileges, you will notice three problem areas:
1) It will be very difficult to write rules (or profiles).
The format of the resource name makes it difficult, if not impossible, to write
rules (or profiles) to protect the JESSPOOL resource class. As delivered from
IBM, the format of the resource name is:
nodeid.userid.jobname.jobid.Ddsid.dsname
The problem is that the length of the user ID field can vary, as can the job
name. Since rules (and profiles) are positional in nature, this makes it
impossible to efficiently protect resources. For example, if a user is looking
at the SYSOUT from a job submitted by user ID 1234 (job name CICSTEST from node
MVSA and the job is number 1001), the JESSPOOL resource name validated would be:
MVSA.1234.CICSTEST.J0001001.D0000101.SYSOUT
However, if user ID 1234567 submitted the job, the JESSPOOL resource name
validated would be:
MVSA.1234567.CICSTEST.J0001001.D0000101.SYSOUT
even though it may be the same job. If you are trying to write rules (or
profiles) to allow operators to look at the JCL and messages of output (Dsid less
than 101), but not SYSIN or SYSOUT data, rule (or profile) writing becomes
impossible.
2) Users can not access their own jobs on the spool.
It is desirable with SDSF to allow users to view or update their jobs when on the
spool. However, this is not so easily done with SAF and a security package. Due
to the format of the resource name, a CA-ACF2 rule (or RACF profile) has to be
written for every user to let them access their own jobs. With ISFPARMS, one
parameter can be used to allow users to view or update their jobs from the spool.
Needless to say, this is not a good solution for a large installation. To
accomplish this, you have to further investigate the relationship between SAF and
ISFPARMS.
The relationship between SAF and ISFPARMS is a little confusing. From reading the
IBM documentation initially, it appears that SAF calls will be made and
processed, and then ISFPARMS security will be checked. This does happen when an
þindeterminateþ response is received from the security system. Itþs not clear
what indeterminate means, but you will soon find out. In SDSF, indeterminate
means that neither an access allowed or access denied response is received from
the security system. Therefore, this response will only occur when there is no
CA-ACF2 rule (or RACF profile) defined an access request.
Given the complexity of the rules (or profiles) that have to be written and the
desire to keep them as simple as possible, in practice, an indeterminate response
will never be returned. In the JESSPOOL class, unless you want to create a rule
(or profile) for each user or job name that exists, it is easier to create one
rule (or profile) that covers the entire resource class. An example of the
CA-ACF2 rule to allow all users to view all output is:
%KEY(****************************) TYPE(JES)UID(-) SERVICE(READ) ALLOW
The RACF command to permit all users read to access this class is:
PERMIT ** CLASS(JESSPOOL) ACCESS(READ).
Once a similar rule (or profile) is in place, you will never receive an
indeterminate response from SDSF for the JESSPOOL class.
The solution to the problem is to find a way to force an indeterminate response
from SAF if the access request is for the JESSPOOL class for a user accessing
their own job. That way, you can just let the one ISFPARMS parameter allow this
access, and avoid the problems associated with rule (or profile) writing. This
assumes, of course, that you do not want to let SDSF users write their own access
rules (or profiles) to let others view or update their jobs on the spool.
3) The resource name is too long for CA-ACF2.
A problem that was particular to CA-ACF2 is that the maximum number of characters
that ACF2 can process for a resource name is 40. However, with the JESSPOOL
resource class, the resource name can be up to 49 characters long. This problem
turns out not to be too difficult to solve as the other problems are fixed.

Managing the Problems

A good place to begin is to examine the preSAF exit point. This exit point is
used before the call to SAF is made, and can be used to modify the resource name
passed to the security system. An example of the processing logic you may want
to use for this exit is:
RESOURCE CLASS = JESSPOOL?YES, CONTINUEOBTAIN RESOURCE NAMEREBUILD RESOURCE
NAMEFIX FIELD LENGTHSEXIT
An example of the new resource name format you can use is:
nodeid.userid.jobname.Ddsid.dsname
If any field name (other than nodeid) is less than eight characters, the name
should be left justified and the field padded with a dummy character (e.g., #).
This solves the positional problem, and gets the resource name down to 41
characters, which you can live with for CA-ACF2. The JESSPOOL resource name to
be validated for a user viewing the SYSOUT of our job described earlier
(submitted by user ID 1234, job name CICSTEST, node MVSA and the job is number
1001) would be:
MVSA.1234####.CICSTEST.D0000101.SYSOUT
In testing this exit, you will find that it can not be used to force an
indeterminate response (since SAF had not been called yet), so that ISFPARMS can
be used to allow users to access their own jobs. You need a postSAF exit to do
this. Unfortunately, this is not available, though IBM level 2 support has stated
that it would be available in the next release. Therefore, you will have to
modify module ISFSAF in SDSF to avoid writing rules (or profiles) for all SDSF
users. The logic in this module can be changed to force an indeterminate response
if the access is for a user accessing their own job. This allows ISFPARMS to be
called and the DSPAUTH=USERID parameter to be used to allow users to access their
own jobs.

Summary

Having completed all these steps, your problems are solved (for now). When IBM
provides a postSAF exit, you can migrate the functionality of the code that was
placed in module ISFSAF to this exit. This will eliminate the need to update the
IBM source code. Whether IBM chooses to fix the position of the fields in the
JESSPOOL resource name or not is another issue.
Like anything else you do for the first time, dealing with SAF and SDSF will be
hit or miss. Fortunately, a good test environment and adequate time to test the
interface will allow the problems that are encountered to be addressed and
solved.
/*
Was this article of value to you? If so, please let us know by circling Reader
Service No. 76.