RACF Users' News # 68

March, 2006 Newsletter

Issue No. 68


RACF (part of z/OS Security Server) is a trademark of IBM. This newsletter is not affiliated with IBM in any way.

Exciting Quiz

How many ways can you name that RACF can be bypassed? That is, suppose you protect a dataset with a RACF dataset rule with UACC(NONE) and only authorized users in the permit list, how many ways could someone be able to read the dataset without being authorized to read it?

For example, one way would be a GLOBAL rule that undercuts the dataset rule.

Another way would be to have a program in the Program Properties Table marked, so that it doesn't call RACF when it opens a dataset.

How many other ways can you name? We have our list on the next to last page of this newsletter. But see first how many you and your officemates can come up with. We will offer a handsome black canvas briefcase to the first five readers who tell us about other ways that are not already on our list.

A Note on Tape Encryption

Several firms have been embarrassed by recent newspaper articles describing how sensitive client data on tape such as credit card numbers had been apparently stolen from delivery trucks. Look to see new products coming which will provide encryption of tapes (and decryption too!).

NEW YORK RUG Meeting Dates

Tuesday, April 4, 2005 from 10AM to around 4PM. PLEASE NOTE THIS IS A SPECIAL MEETING WITH DIFFERENT TIMES AND REGISTRATION REQUIRED. THIS IS A LOT OF TRAINING AVAILABLE IN ONE DAY. You will not be allowed to attend without pre-registering (it's free), as described inside. Mark your calendars now. See inside for details, including the tentative agenda. The meeting after that will likely be in October, 2006. Please note the NYRUG will meet twice a year from now on.

-------------------------------------------

Todays Proverb

"The essence of control is comparison to a standard."

Vanguard Conference on West Coast in 2006

It's scheduled for July 8-12, 2006 in San Diego, CA. Note that the regular sessions start on the Sunday, not the Monday.

To Get a Free Subscription to the RACF User News

Phone Stu at (301) 229-7187 with your request, leaving your name, postal address (sorry, only US postal addresses; others will need to read issues online), and phone. For back issues and articles on topics like the SERVAUTH resource class, check his website: www.stuhenderson.com.

More on The Health Checker

Our last issue described the Health Checker for z/OS, a program which runs all the time in the back of your computer, making certain checks for proper settings at the times you specify. Checks can be made for: RACF, consoles, GRS, RSM, SDUMP, USS, VSM, and XCF. In this issue, we will discuss the two possible checks for RACF:

1) Checks for ENQs

2) Checks for system-critical datasets

1) Checks for ENQs An ENQ or enqueue is a way of reserving a resource on the computer so that no one else will update it while you are in the middle of updating it. This is essential to maintain data integrity, in the case of RACF to preventing corruption of the RACF database. RACF issues several ENQs (and releases the resources with appropriate DEQs or dequeues) to maintain integrity of the RACF database. It is possible for other parts of the system software to change the scope of such ENQs, for example from covering just an address space, to covering a full MVS image, or to covering several MVS images in a sysplex. Changing the scope of these ENQs up or down can result in corruption of the RACF database. The RACF service team has debugged several customer problems which turned out to be caused by just such changes in scope. (You wouldn't want to try to debug a problem like that without someone like Russ Hardgrove helping you.) So IBM added a check to the Health Checker to make sure that the scopes of these ENQs aren't changed in ways which are risky for RACF. Would you know about this risk to your installation if you didn't run the Health Checker?

2) Checks for System-Critical Datasets The Health Checker can review the dataset rules for several critical system datasets and warn you of any that seem inappropriate. (Apparently it doesn't yet check relevant GLOBAL rules.). This checking gives you more information that that provided by the DSMON SELECTED DATASETS REPORT, checking not just the UACC, but also whether WARNING is set, and whether access is permitted to ID(*). We do not yet have a list of the datasets covered by the Health Checker, but we believe it to be more complete than that from DSMON.

IBM may add additional RACF checks in the future. Your sysprogs may add checks as well, but this should be done with great care. You can learn more about the Health Checker from this IBM manual: "IBM Health Checker for z/OS User's Guide" SA22-7994-00 and from Mark Nelson's presentations at user groups and conferences. You should discuss this useful tool with your system programmers to see if it makes sense in your installation. They will find several other checks (beyond the RACF checks) of interest to them.

What Is the PROPCNTL Resource Class?

This is used to specify userids which are never to be propagated onto batch jobs. When a user submits a batch job, and the JOB card does not specify USER=, then the userid of the submittor is automatically propagated onto the batch job. Another way of describing this is to say that the batch jobs inherits the userid of the submittor. So if I log onto TSO with the RACF userid STU, and submit a batch job which doesn't specify USER=, then the batch job executes under the userid STU (inheriting it from the submittor). No password is needed, and no security exposure is introduced. This inheritance is part of standard JES logic.

Now imagine a user logged onto CICS with RACF userid MARY. In addition to MARY's userid, there is a userid for the CICS region itself, let's say CICSPRD1. Suppose that MARY executes a CICS transaction that submits a batch job, and the JOB card does not specify USER=. Which userid does the batch job execute under? Murphy's Law would predict the userid of the CICS region, since it has more power than we want the batch job to have. And Murphy's Law would be right again. The batch job executes under the userid CICSPRD1, which is probably not desireable.

So we to prevent this, we would use the PROPCNTL resource class. This is used to tell JES not to propagate the userid CICSPRD1. The RACF command would look like this:

RDEF PROPCNTL CICSPRD1 UACC(NONE) ...

This sounds like a good thing to do, until you talk to the CICS developers, who explain to you that they have hundreds of source decks for various transactions, and no one has the time to go through them all looking for JOB cards. And besides, they say, you haven't given us a simple, perfect method to fix this if we find it. (There are work-arounds, but no one thinks they are great.) So, they explain further to you, since BATCHALLRACF is active, if you turn that PROPCNTL thing on, and lots of production batch jobs blow up for RACF failures, it'll be your fault.

So most shops don't use this class. But you might consider using it whenever you create a new CICS region, so it's active for that region's userid from the start. (Of course, each CICS region should have a unique userid, and each region's default userid should be unique, and not the same as the userid of the region.)

A Different Opinion on What RACF Settings Are Important

Many administrators and auditors argue about what RACF options should or should not be active. In the opinion of Larry Merry Ogleby, our resident RACF theoretician, "there is a simple basis for making many of these decisions: "It's easy to think through, and life is easier for the RACF administrator, if you keep in mind that:

1) RACF Should Be Comprehensive

2) RACF Administration Should be Simple

3) Good Standards Should Make Your Life Easier Here's some explanation of the first item, and how it can make your life easier:

1) RACF Should Be Comprehensive

This includes two parts: RACF should be called automatically whenever needed, and RACF should fail a request when there is no matching rule (unless the RACF administrator has decided to allow such requests). Some examples of automatic calls that make life easier:

In summary, if RACF isn't always called when it's needed, then you have to go check lots of other places to be sure protection is adequate. In this situation, you never can know that your security is reliable. Failing a request when there is no matching rule makes life simpler, and guarantees that programmers will have to inform RACF administration when defining new datasets, applids, and so on. RACF gives us switches like PROTECTALL and BATCHALLRACF. (PROTECTALL can also enforce naming standards automatically, making it easier for operations to tell what a dataset is for and where it came from.) For resource classes, we can define backstopping rules (named **) which match anything and then either allow or fail the request.

(XBMALLRACF is a similar switch, but of little criticality. It applies only to jobs run under JES's Execution Batch Monitor. Almost no one uses this JES feature, so turning it on or off makes little difference for most of us. If you use XBM (ask your JES sysprog), then you should consider it.)

Some examples of the benefits of failing undefined requests:

So, when trying to figure out what options to set in RACF, list the critical places where RACF needs to be called, and then find ways to always- call it, and to fail calls with no matching rule." We hope to get Larry to expound upon the other items in upcoming issues. Thanks Larry

NYRUG (New York RACF Users Group):

Our next meeting is at IBM, 590 Madison Avenue. Attendees must present a government issued photo ID to enter the building. Admission is free to hear these great speakers, but you must pre-register by emailing NO LATER THAN NOON APRIL 3, 2006 to Mark Nelson (markan@us.ibm.com) with "NYRUG MEET" in the subject line and your name and company in the body. Pre-registration is highly recommended.

Our exact agenda is not certain at press time, so you might want to check this link for exact details as they become final: http://www.stuhenderson.com/XNEWSTXT.HTM#nyrugref 

Starting roughly at 10AM (tentative agenda) ending around 4PM:

(Please note that times are approximate and that speakers and topics are subject to revision.)

Time: Tuesday, April 4, 2006 from 10AM to around 4PM .

Place: IBM, 590 Madison Avenue . Attendees must present a photo ID to enter the building and must pre-register in advance..

Interesting Products Column

These are products which we think you will find interesting, but you should perform your own evaluation before deciding whether to use.

==============================================================

New Free Email Newsletter for Mainframe Auditors
To learn more about the Mainframe Audit News (MA News), check Stu's website: http://www.stuhenderson.com 

HG How to Audit Training Schedule:
The Henderson Group now offers its series of "How to Audit.." seminars for IT auditors. These describe clearly how the associated software works, where the control points are, how to collect and interpret data, and how to conduct the audit. More information is available at our website: www.stuhenderson.com  If you have a class you would like to have added to this series, please let us know. (See info on "RACF and Security" classes below.)


  A)    HG64 How to Audit MVS, RACF, ACF2, CICS, and DB2 ($1550)      
                Apl. 5-7,        2006 in Washington, DC
                Nov. 1-3,        2006 in Clearwater, FL

  B)    HG65 How to Audit z/OS with USS, TCP/IP, FTP, and the Internet
                (This class is a logical follow on to HG64.) ($1560)
                Dec. 11-13       2006 in Bethesda, MD  


HG RACF and Security Training Schedule:
The Henderson Group offers its RACF and computer security/audit seminars around the country and on-site too. See the details below or call (301) 229-7187 for a free seminar catalog. For more info or to see what students say about these classes, please go to www.stuhenderson.com . (See info on "How to Audit ..." classes above.)



  1)    HG04 Effective RACF Administration    ($1995)  
                Sept. 18-21,             2006 in Washington, DC

  2)    HG05 Advanced RACF Administration  ($1990)                        
                Spring,                  2006 in Clearwater, FL

  3)    HG17 Comprehensive z/OS Security (Formerly: How to Be an Effective z/OS or
        OS/390 (MVS) Data Security Officer) (covers CICS, VTAM, DB2, and JES security
        along with MVS security, SAF, OS/390, and z/OS)  ($1290)                  
                Dec. 6-8,        2006 in Bethesda, MD


Answers to Quiz on First Page

The first page of this newsletter describes a quiz to see how many ways you can list for RACF to be bypassed. Here's our list, in no particular order:

  1. Userid has the OPERATIONS or relevant group OPERATIONS attribute
  2. There is a GLOBAL DATASET rule which undercuts the DATASET rule.
  3. The program is listed in the Program Properties Table with BYPASS PASSWORD CHECKING set to YES.
  4. The dataset rule is marked WARNING.
  5. The dataset is on disk, gets erased, and is not protected by ERASE-ON- SCRATCH.
  6. A started task marked TRUSTED or PRIVILEGED tries to read the dataset.
  7. The high level qualifier of the dsname is the userid of the the user.
  8. The dataset is on tape, and tape protection is turned off, both in RACF and in the tape management software.
  9. The dataset is on tape and the user can Bypass Label Processing, so he lies about the dsname, specifying a fake dsname that has his userid as the high level qualifer.
  10. The dataset is on tape and there is a second dataset on the same cartridge to which the user is permitted access. The user then opens the second dataset and give the command "Backward Space File" to position the tape drive at the start of the first dataset. The user then reads the data.
  11. The dataset is on tape, the user waits until the tape becomes a scratch tape and calls for it, browsing the data which is still there.
  12. (A bit of a stretch) The dataset is on disk, the dataset rule is discrete (not generic), but the RACF bit is not turned on for the dataset, so the discrete dataset rule is ignored.

Permanently Interesting Products Column
This column has been permanently moved from this newsletter to Stu's website. You can find it at: www.stuhenderson.com/XINFOTXT.HTM 

RACF User Services (Newsletter Subscriptions / Key Phone Numbers / Addresses)

RACF List Server on the Internet
To join, send E-mail to the administrator for the server. (Don't send it to the server itself or your request will be routed to every subscriber.) For example, if your name is John Smith and you want to subscribe, then send this E-mail:

subscribe racf-l john smith

to the address: listserv@listserv.uga.edu

The reply will include directions on how to get info such as a list of all subscribers, an index to previous comments, and a command summary. You will want to set up a filter for incoming emails to direct mail from the list server to a dedicated folder or directory.

New Free Email Newsletter for Mainframe Auditors
To learn more about the Mainframe Audit News (MA News), check Stu's website at: http://www.stuhenderson.com 

The RACF User News
is published two times a year (March, and September) to share information about RACF. All information in it is offered on an "as is" basis, and should be used at your own risk, and with your own testing.

Other Internet places:

Stuart Henderson
(301) 229-7187
5702 Newington Road Bethesda, MD 20816-1282
stu@stuhenderson.com


Copyright ©: 2006, Stuart C. Henderson