RACF (part of OS/390 Security Server) is a trademark of IBM. This newsletter is not affiliated with IBM in any way.
NEW YORK RUG Meeting Dates
On Wednesdays, from 1 to 5 PM: on April 14, 1999 and then July 14, 1999. Mark your calendars now. See inside for details.
BALTIMORE/WASHINGTON RUG
Meeting Dates On Thurdays, from 9AM to Noon: on April 15, 1999 and then July 15, 1999. Mark your calendars now. See inside for details.
-------------------------------------------
Correction to Last Issue
Of course we should have pointed out that the following SEARCH command (from the Q&A in last issue) would cause a call to RACF for every dataset rule in the RACF database. This might slow down performance, so consider breaking it into pieces with different masks, or running in an off-shift (or an off-week if it really slows you down.) Our apologies. SR USER(USER02) NOMASK + CLASS(DATASET)
How To Save Yourself Some Grief
We understand from the RACF List Server that the new version of FTP (File Transfer Protocol under TCP/IP) requires you to use the OPERCMDS resource class. Supposedly, FTP doesn't even check to see whether the class is active or not. This would be a large irritation, except that you need to have OPERCMDS protection to have good security anyhow. Next issue, we will have a small lesson on how to use the OPERCMDS class. In the mean time, start talking to your system programmers and lead operators to find out who should be permitted to which commands.
The Same Old Problem With 8 Character Userids
We used to have a problem because an MVS control block only allowed 7 characters for the userid. IBM since fixed the control block, but not all software seems to be on top of the improvement. Several shops have had mysterious problems which affected some userids, but not others. Turns out the problem was always with an 8 character userid. The newest version of FTP has a fix to allow it to handle 8 character userids. Remember to look for this pattern when debugging problems that only affect certain userids.
Texas RUG Strong and Active
Contact President Margaret Washington (713) 245-3700 for more info.
Here's a Small Lesson on Accessing OMVS Files From TSO
Say you've logged onto TSO with userid STU, and you want to copy some files between you OMVS directory and MVS. (OMVS is also called USS or Unix System Services. It is UNIX under MVS, and is now a part of the core operating system with OS/390.)
Let's say that all your MVS files have names beginning STU. and all your OMVS files live in your directory in the HFS dataset. The directory structure is very similar to the one on your hard drive on your personal computer, except that the slashes go the other way. The top of the directory tree is a slash /, and the sub-directory below that where users keep their own files is /u/. You would keep your files in a sub-directory under /u/. Perhaps the sub-directory would be named stu to make it easy to associate with your RACF userid STU. So the full name of the directory where you would keep your OMVS files would be: /u/stu/.
Let's assume that your RACF administrator is also the OMVS userid administrator, and that she has added an OMVS segment to your RACF user profile:
ALU STU OMVS( HOME('/u/stu') PROGRAM('/bin/shell') UID(666) )
This assigns your RACF userid the UNIX uid 666, and specifies that your home directory is /u/stu/. This means that when you connect to OMVS, your working, or current, directory will be /u/stu/, which is where you want to be. This OMVS segment also specifies that when you connect to OMVS, the program shell in the directory bin will automatically start executing, much as ISPF starts up when you log onto TSO.
If you were going to enter the UNIX world, you would type the TSO command OMVS, and UNIX would take over from TSO, using the information from your RACF OMVS segment to identify you and get you going. YOU MUST REMEMBER THIS NOW: the way to exit from OMVS and get back to TSO is to issue: exit. Don't issue the OMVS command until you memorize how to get out.
But to keep things simple for now, let's just pretend that you are staying in TSO. Suppose that you have a file named test1.dat in your directory. Then the full name of the file would be /u/stu/test1.dat.
To copy the file test1.dat from OMVS to MVS, where you want to call it STU.TEST1.DAT, you would use the OGET command in TSO:
OGET '/u/stu/test1.dat' 'STU.TEST1.DAT' BINARY
You can use a single asterisk in OMVS file names as a wildcard, just the way you do on your personal computer, or just the way you do in RACF.
To learn the syntax of any of the TSO commands for OMVS, use the OHELP command:
OHELP
In the other direction, to copy the file STU.TEST2.DATA to OMVS with filename test2.dat, use the OPUT command:
OPUT 'STU.TEST2.DATA' '/u/stu/test2.dat' BINARY
If you want to access OMVS files from MVS batch jobs, the DD card has a new operand named PATH in which you specify the directory and sub-directory path for the file you want.
In an upcoming issue, we'll tell you how to change the security settings in OMVS for these files. In the meantime, can you guess what these TSO commands do: MKDIR, OBROWSE, OCOPY, OEDIT, OBATCH, and OFOOEY? You can use OHELP to learn their syntax. (Hint: OFOOEY is someone's idea of a funny joke. The editor had to clean it up before we could even print it for you gentle readers. It's not a real command.)
What Does This Tell Us About the History of the World?
Looking at the directory structure and file names in UNIX and in MS/DOS or Windows on your personal computer, you can see more than a passing similarity. Both use . as the name of the working directory, and both use .. as the name of the parent directory. You would almost have to conclude that either UNIX copied the idea from MS/DOS, or that MS/DOS copied it from UNIX. Which came first? UNIX, of course. You can almost see IBM's signature in changing the forward slash to a backslash.
Fifteen Minute Project to Improve Your RACF
The FIELD class now needs to be RACLISTed. This is as of RACF 2.2 and later with APAR OW30469, and also vof OS/390 2.6 without any special APARs. If you don't RACLIST the FIELD class, then only users with SPECIAL can update fields in segments of RACF records. So issue this command if you use the FIELD class:
SETR RACLIST(FIELD) LIST
Oh, for a UACC of NONE!!
Many RACF installations are finding themselves with connections to the Internet or other places through TCP/IP and OMVS. Since OMVS is now part of the base system with OS/390, and many executives are starting to think of e-commerce, we sometimes find the Internet connection has been opened without consultation on the security consequences. Now we have a bunch of unknown users connected to our mainframes, and are struggling to get the OMVS security in place before the alligators overwhelm us. Remember when you were first rolling out RACF protection for datasets and the question came up, "Should the default UACC be NONE or READ?" You knew that NONE would be more secure, but also that READ would make life easier. Some of us went with UACC(READ), and swore that we'd come back some day and tighten things up. With the new TCP/IP and OMVS, you might want to address the possibility that TCP/IP users could copy any data on the mainframe side which has a UACC of READ.
Diatribe on the Design of VTAM
Several users of the RACF List Server have been commenting on what is necessary to ensure that all paths into the system are controlled by RACF. (Sort of like PROTECTALL, but for userids instead of datasets). The one weakness we all face is VTAM applids, that is programs that VTAM lets you sign onto from a terminal. CICS, IMS, and TSO are common examples of applids, but your installation probably has several others. And you can't force them to call RACF to check out a person's userid and password. This makes it possible (subject to the judgement of the system programmer who installs the applid) to define a path into your system which is not controlled by RACF. Wouldn't it be great if VTAM had an option to force users to sign on through RACF before it allowed you to bind to an applid? The only other options seem to be to write exits from VTAM or to publish a policy and try to get everyone to follow it. When IBM applied to get a B1 rating from the Federal government, many system software components (including MVS, JES, TSO, and others) were modified so that they always called RACF. Maybe someday VTAM will close this last hole for us.
Questions and Answers
NYRUG (New York RACF Users Group) and BWRUG (Baltimore/ Washington RUG) NEWS
NYRUG: At Our Next Meeting
PassGo Technologies will host our next meeting. They are offering a freee lunch and product demo before the meeting, if you want to learn more about their software. The product presentation is completely separate from, and precedes our regular meeting. Please call Amy Ricker at (978) 635- 1588 if you will be attending the lunch. (To learn more about PassGo Technologies, see "Interesting Products" earlier in this issue.) At the regular meeting, planned speakers include an official representative of IBM (we hope to get Mark Nelson) describing the coolest new features of the latest RACF release AND Hayim Sokolsky of Vanguard on the subject: "RACF and Disaster Recovery (not an Oxymoron)". If time permits, Stu Henderson may describe how to prepare to use the Mainframe Firewall tool, a follow-on to his recent "What Mainframers Need to Know and Do About TCP/IP". As always, we will have a question and answer session with some of the keenest RACF minds in the State to answer questions
Time: Wednesday, April 14, 1999. The lunch and product presentation will begin at 11:30AM. The regular meeting starts at 1PM until it's too late to go back to the office.
Place: Loews New York Hotel, 569 Lexington Avenue (at about 51st St.), phone (212) 752-7000. The monitor in the lobby will list the exact location. By subway, take the #5 LexAve train to Lexington Ave and 51st. By auto, take the FDR North to 42nd St. and take a left (going west) to 3rd Ave. At 3rd Ave, take a right onto 51st. Parking is in 51st St. garage on the left side of 51st between Lex and 3rd Ave.
==============================================================
BWRUG (Baltimore/Washington RUG):
PassGo Technologies will host our next meeting. They are offering a freee lunch and product demo after the meeting, if you want to learn more about their software. The product presentation is completely separate from, and follows our regular meeting. Please call Amy Ricker at (978) 635- 1588 if you will be attending the lunch. (To learn more about PassGo Technologies, see "Interesting Products" earlier in this issue.) At the regular meeting, planned speakers include an official representative of IBM (we hope to get Mark Nelson) describing the coolest new features of the latest RACF release AND Hayim Sokolsky of Vanguard on the subject: "RACF and Disaster Recovery (not an Oxymoron)". If time permits, Stu Henderson may describe how to prepare to use the Mainframe Firewall tool, a follow-on to his recent "What Mainframers Need to Know and Do About TCP/IP". As always, we will have a question and answer session with some of the finest RACF minds on the east coast ready to share their knowledge.
Time: Thursday, April 15, 1999. The regular meeting will be from 9AM to noon. The lunch and product presentation will be from noon to 1PM.
Place: Marriott Residence Inn at 7335 Wisconsin Ave in Bethesda, MD, phone (301) 718-0200. This is at the Bethesda stop of the RED LINE of the Metro (which goes quickly to Union Station for MARC and Amtrak riders). By car: Take the beltway I495 to Exit 34 (Wisconsin Ave.) This is NW of DC, near where I270 joins I495. Take Wisconsin Ave South (aka Route 355 South) about 2.5 miles. Watch for the Hyatt/Bethesda Metro on the right. Just past the Hyatt, take the next left onto Montgomery Avenue. Go one block and take the first right onto Waverly Avenue. Waverly wraps around to the front of the hotel where there is valet parking.
Interesting Products Column
We have not evaluated these, but think every RACF shop should know about them.
Permanently Interesting Products Column
We have not evaluated these, but think every RACF shop should know about them.
HG RACF and Security Training 1998 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.
1) HG04 Effective RACF Administration (formerly called How to Implement and Administer RACF
Effectively) ($1695)
Apl 5-9, 1999 in Bethesda MD (extra session)
May 17-21, 1999 in Atlanta, GA
Sept.27-Oct. 1, 1999 in New York City
Nov. 15-19, 1999 in Washington, DC
Feb. 21-25, 2000 in Clearwater, FL
2) HG05 Advanced RACF Administration ($850)
June 21-22, 1999 in Denver, CO
Sept. 21-22, 1999 in Washington, DC
3) HG17 How to Be an Effective OS/390 (MVS) Data Security Officer) (covers CICS, VTAM, DB2, JES, and
other security along with MVS security, SAF, and OS/390)
($1150)
June 16-18, 1999 in Atlanta, GA
Oct. 18-20, 1999 in Washington, DC
4) HG40 Mastering Windows NT Security ($850)
June 23-24, 1999 in Denver, CO
[This course will expand to 3 days in the second half of 1999.] RACF User Services (Key Phone Numbers / Addresses)
RACF User Services (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@uga.cc.uga.edu or LISTSERV@UGA.BITNET
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.
Other Internet places: