SEARUG NEWSLETTER
January 1996 SEATTLE RACF USERS GROUP
NEXT MEETING Tuesday, February 13th. 1996
Site: Airborne Express
Host: Kevin Jasper (206) 281-1058
Address: 101 Western Ave Seattle Wa.
Directions: Call Kevin for directions.
AGENDA: 1:00 PM Airborne 'automated' RACF administration by Gretchen Kerns
2:30 PM BREAK
2:45 PM A presentation on The Agora -- a new Seattle area security user group by Kirk Bailey.
3:15 PM A Webbing we will go. Demonstration of access to the Internet aimed at finding security information, etc. Places to go, things to see.
4:30 PM Sharing and swilling. (i.e. informal discussion and future user group meeting plans conducted at local licensed establishment)
Something to eat and drink will be provided in the conference room. Also, adjacent to the third floor conference room is the cafeteria which will have vending machines open late in the afternoon.
SEARUG NEWS By George Fogg
Well....during the Christmas break I had to find that Tahiti RACF User's Group (TRUG) that I heard of some months back. And wouldn't you know it?, there isn't any. I looked on the main Island of Tahiti, in the bars of Moorea, in the volcanoes of Raiatea, on the sandy beaches of Huahine, and underneath the palm trees of Tahaa. No luck. I almost gave up but thought it was my duty to find the elusive TRUG so we sailed on to Bora-Bora. Our first port-of-call was the Bora-Bora Yacht Club (being a famous watering hole for visiting yacht club members so why not famous RACF clubs?) I knew I failed my quest when the bartender at the club said "what'sa RACF ?" Being full of despair and remorse, I immediately ordered a mai-tai foo-foo drink and promptly forgot about computers and all other associated entities like RACF. The biggest computer I saw during my vacation was a hotel PC on a hotel LAN running hotel software stuff. Lucky them...
Mailing list and membership Information.
Lupe Peru of SEAFIRST Bank has moved on to Microsoft. Her replacement is Kristin Michael at Seafirst Bank, Phone number is 358-6677. We will miss Lupe and the great work she did for SEARUG (she still owes me a beer).
What's the New News
YEAR 2000 -What's RACF development going to do about the roll over date for Year 2000? Here's the latest scoop on what they are planning for us.
A direct quote from IBM: "RACF will continue to use 3-byte dates in the database, and for a value of yyddd will consider yy values <= 70 to indicate 20yy, while yy values >= 71 will indicate 19yy." There may , and I mean may, a callable service provided by IBM for customer code to deal with the year 2000 change. I for one would welcome this function since I have written code that extracts fields from the RACF database. I can also assume that RACF wasn't around in 1969, back in my surf bum days.
SECURITY EDUCATION AVAILABLE
The Henderson Group Education
"THE HENDERSON GROUP" is in the business of Security education. They offer many courses in MVS and UNIX security. Please call (301) 229-7187 for details on courses that are available.
IBM Education
IBM courses available in the near future are:
H3992 - Implementing RACF Security for CICS/ESA
H4020 - Migrating to RACF Version 2 (Including RACF 2.2) In Seattle on 4/2/96 Z2187 -RACF for the Security Administrator (Scheduled by the IBM Learning Center)
H3927 - Effective RACF Administration
H3918 - MVS/ESA RACF Security Topics
Call IBM-TEACH: 1-800-426-8322 for schedules and details
PRODUCTS OF INTEREST
BookManager Update for RACF 2.2
On-line books for RACF has been updated to a SEPTEMBER 95 edition. The order information is: IBM On-line Library Productivity Edition: RACF Information Collection September 1995, SK2T-2180-03. 28 new books were added to the collection that comes on two CD-ROMs. The first contains MVS system control program books. The second contains MVS non-system control program books, MVS RACF books, VM RACF security books, and "Rainbow" RACF books.
HIPER APARS UPDATE FOR SEPTEMBER 1995 THROUGH JANUARY 18th 1996
Hiper APARs are documented problems of extreme magnitude that they are defined in a special category on IBMLink. I treat them as a flashing red light, telling me that IBM or a customer has found a problem that can cause major trouble. Hipers can be open or closed. Hiper APARs that are closed have a fix available from IBM (A fix is also known as a PTF. Some APARs may have more than one PTF to fix one or more modules in error and PTFs can fix one or more reported APARs).
Hipers for RACF 1.9, 1.9.2, 2.1.0, and 2.2.0 since the last newsletter in October 95
OW13698 -CLOSED Abend 878 & 80A due to RACF allocation of SGFBUFFERS below the 16M line.
OW14930 -CLOSED RACF dataset index corrupted.
OW14419 -CLOSED IRRDBU00 output record type 220 missing one byte...
OW17257 -CLOSED In datashare mode, an ALTERI on a multi RBA profile may result in database corruption.
OW16088 -CLOSED Started Procedures run as undefined to RACF when STDATA segment does not contain a groupid. This is a hot one for you started class users!
TECHNICAL CORNER -- Front-ending RACF Commands
Front-ending RACF commands is a way to execute code before the actual RACF command is invoked. Although this is not recommended by IBM, it gives us a method to provide a pseudo exit to a RACF command that doesn't have a "certified and blessed by IBM" exit point. Here's an example:
We give certain users group-special to a given group so they can manage that group and subordinate groups and userids that are owned by the group they have group-special with. We call these semi-privileged users "focal points". Once in a while we get a focal point clown that likes to create subordinate group names that have no meaning. They create group names such as "doggie" or "mommie" or "boom" or a name like "zzzzz" (wonder what Freud would think of these names). I think these focal points have run out of things to do or bored with life. They could be one of those mis-directed aggressive types that take out their anger on inanimate objects such as a ADDGROUP command. Gee, guess we're lucky there's no command called "SHOTGUN" or one called "CLINTON" for those angry white republicans. Anyway, they create a mess. We decided to allow them to continue having group-special (since we don't want to do their job) but not give them the ability to create clownish group names that have no purpose in a group hierarchy.
RACF does not provide an exit point for ADDGROUP (for that matter, most RACF commands do not have an exit point) so I wrote a front-end processor that gets control when a user types in the ADDGROUP command . The logic in the front-end processor does the following: Allow the user to use the ADDGROUP command if they have system special or are connected to the group "addgroup". (clever name huh?) If they don't have these exalted properties then send a pleasant, but informative message to the user that they don't have the authority to use the command and stop processing. (source code attached to newsletter)
I'm giving you this information for two reasons. One, so you know there's alternatives when no exit is provided for RACF commands and , Two, if you have written a front-end processor, then changes in RACF 2.2 will make your old front-end processor fail.
Before RACF 2.2, a TSO command was given immediate control. In RACF 2.2, the RACF command envelope (IRRENV00) module gets control first. For details on what IRRENV00 does at this stage then see the RACF Diagnosis Guide, LY27-2635-01. You need to change the link-edit statements for the front end command processor for 2.2 or you will most likely receive abends. I had to make the following changes for my ADDGROUP front end command processor when we went to RACF 2.2:
Pre RACF 2.2
++JCLIN.
//LINK EXEC PGM=IEWL,PARM=
//LCLDLIB DD DSN=SYS1.LCLDLIB,DISP=SHR
//SYSLMOD DD DSN=SYS.LINKLIB,DISP=SHR
//SYSLIN DD *
INCLUDE LCLDLIB(ADDGROUP)
ENTRY ADDGROUP
ALIAS AG,ADDGROUP
NAME ICHCAG00(R)
/*
RACF 2.2 Changes
++JCLIN.
//LINK EXEC PGM=IEWL,PARM=.....
//LCLDLIB DD DSN=SYS1.LCLDLIB,DISP=SHR
//SYSLMOD DD DSN=SYS1.LINKLIB,DISP=SHR
//SYSLIN DD *
INCLUDE LCLDLIB(ADDGROUP)
INCLUDE SYSLMOD(ICHCAG00)
ENTRY ADDGROUP
NAME ICHCAG00(R)
/*
QUESTIONS and ANSWERS
Q: What's the difference between making a Program Property Table (PPT) entry for a task to bypass RACF authority checking and using the Trusted and Privileged settings in the Started Procedure Table (SPT) to bypass authority checking?
A: There's a little history here. The PPT has been around Before RACF (B.R.). It was a way to give a program special authorities such as marking it non-swapable, defining system processor affinities, setting the task as non-cancelable, etc. For bypassing dataset password checking there was a bit called the "nopass" bit in the PPT. One use to set these bits on by patches and zaps. Anyway, along comes RACF (A.R.) and the "nopass" PPT bit now means to bypass RACF authority checking for the dataset class only. Now days, one sets the "nopass" bit on for a program by making a PPT entry in the SCHEDxx parmlib member using the NOPASS parameter. Again, this parameter will bypass authority checking for the dataset class only.
RACF came with the Started Task Table now known as the Started Procedure Table (SPT). In the pre RACF 1.9 days, and without the technicalities on how to do this, the only way to give a program the ability to bypass "all" authority checking was to mark it as a privileged started procedure using the ICHRIN03 module. RACF 1.9 added the "trusted" bit in ICHRIN03. The difference between "privileged" and "trusted" is that marking a SPT entry "trusted" also allowed logging of the access in order to comply with the government requirements for a B1 security level rating of RACF 1.9. A "privileged" SPT entry has no logging of access attempts. In fact, you are not supposed to use the PPT or RACF's "privileged" bit to bypass authority checking when your system is certified as a B1 level system.
RACF 2.1 makes this process a whole lot easier with the "started" general resource class. No more IPLs required to invoke a new started procedure. A simple RDEFINE and a refresh of the started class defines a new SPT entry and the started task is ready to execute.
The other ways to set a program or task as "trusted" is by using the RACROUTE VERIFY, VERIFYX, and TOKENBLD macros but that's another story and the code using these macros needs to run authorized anyway.
Recommendations: I would take all PPT entries that enable a started procedure program to bypass dataset authority checking to be set as "trusted" either in the ICHRIN03 module or the "Started" general resource class so logging can be performed to make the auditors happy among other things. PPT NOPASS entries are checked by MVS and never passed by RACF. "Trusted" and "Privileged" SPT entries are passed to RACF and grants access to the resource but no exits are called, no further authority checking is performed, and no audit requirements stated in the profile that protects the resource are satisfied.
INTERNET NEWS
HOT WEB URL's for RACF interested parties:
http://www.win.com/~ssabel/searug/searug.html for our own SEARUG Home Page
http://www.ibmlink.ibm.com for the new WEB IBMLink
http://www.mindspring.com/~ajc10/garug.html for Georgia's RACF User's group
http://www.redbooks.ibm.com/redbooks/ for IBM's REDBOOK Collection
http://www.hiway.co.uk/xephon/racf/html for new RACF Update books from the XEPHON Corporation
COPYRIGHT and TRADEMARKS
All Copyright and Trademarks are recognized by this author wherever they appear in any SEARUG Newsletter; hereforthwith, hereinafter, hereafter, herebeforewith, ad infinitum. (I'm too lazy to add TM and Copyright symbols whenever the words IBM or DB2 or RACF, etc.that may appear in the text but I respect their ownership and claims to said material)
SEE YOU AT THE FEBRUARY 13th. MEETING AT AIRBORNE
SEARUG is proudly sponsored by Technology Management Group, Inc. (206) 451-2575