RACF Users' News # 51

Dec., 1999 Newsletter

Issue No. 51

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

More Name Changes From IBM

IBM has changed the name of RACF
once again. For a while we thought the
name was "OS/390 Security Server", but this
is really the name of the package which
includes RACF, the Firewall, and several
other tools. IBM has now changed the name
to be "Secureway" for at least the month of
January.
Remember how cleverly IBM named
UNIX when they put it onto the mainframe.
"OMVS" sure doesn't sound like UNIX. But
neither does the prefix "BPX" which is used
for UNIX parmlib members and manuals.
But then IBM changed the name from
"OMVS" to "UNIX System Services" which is
abbreviated "USS", not to be confused with
the VTAM "Unformatted System Services".
Did you ever have an English teacher
(or a corporate boss) who kept marking up
your papers, no matter what you wrote. And
then you finally figured out that if you saved
your original draft and turned it in again as
the fifth or sixth, it might be accepted? Who
would like to bet that the name of RACF will
some day come around again, either as the
"brand new" name for IBM's mainframe
security software, or as a table in VTAM?

NEW YORK RUG Meeting Dates

On Wednesdays, from 1 to 5 PM: this quarter on January 12, 2000. The
following meeting will be April 12, 2000. Mark your calendars now. See inside
for details.

BALTIMORE/WASHINGTON RUG

Meeting Dates

On Thurdays, from 9AM to Noon:
But there will be no meeting this quarter. The next meeting is scheduled
for April 13, 2000. Mark your calendars now. See inside for details.

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

More Change in the RACF Software
Industry

Technologic Software has acquired
LT Technologies' SSSR (Security Server SMF
Reporting). Call Bill Tomlinson or Dick
Kielb at (949) 509-5000 for more info. We
understand that: "SSSR provides 32 pre-
packaged RACF reports organized for use on
daily, weekly, and monthly schedules, and
the convenience of regular, standard analysis
and the ability to quickly focus on trouble
areas. On demand analysis gives you the
ability to drill down into any security issue
and provide instant insight into any problem
or request."

Technologic Software has another
product called In-Compliance, which
provides "a new Web interface tool to RACF
that allows administrators and auditors to
analyze, compare, and set thresholds on
over 200 standards/rules/policy categories
they have established. The tool will notify
you via electronic communication (fax,
pager, e-mail) when any of the compliance
and tolerance levels you set deviates."

More on UNIXPRIV Resource Class Rules

Here is a more complete list of rules in this class:

(These all require READ access except as noted)

CHOWN.UNRESTRICTED -- if this rule exists, then any user can CHOWN the owner of
files he owns to be any UID or GID

SUPERUSER.FILESYS -- READ allows you to read any file, and to read or search any
directory. UPDATE lets you write to an file, but not to any directory. (UPDATE of course
implies READ as well.) CONTROL lets you write to any directory. This rule applies only
to HFS files and directories, not to NFS (Network File System) files and directories.

SUPERUSER.FILESYS.CHOWN -- lets you CHOWN the owner of any file, not just ones
you own.

SUPERUSER.FILESYS.MOUNT -- READ lets you issue the USS commands mount and
unmount with the nosetuid option. (Please pronounce this "no set uid", not "nose tu id".)
UPDATE lets you issue those command with setuid as well.

SUPERUSER.FILESYS.QUIESCE -- READ lets you issue the USS commands quiesce and
unquiesce with the nosetuid option. (Please pronounce this "no set uid", not "nose tu id".)
UPDATE lets you issue those command with setuid as well.

SUPERUSER.FILESYS.PFSCTL -- lets you use the pfsctl() callable service.

SUPERUSER.FILESYS.VREGISTER -- lets a server use the vreg() callable service to
register as a VFS file server.

SUPERUSER.PROCESS.GETPSENT -- lets you use the w_getpsent callable service to
receive data for any process.

SUPERUSER.PROCESS.KILL -- lets you issue the kill() callable service to send signals
to any process.

SUPERUSER.PROCESS.PTRACE -- lets you use the ptrace() function in the dbx
debugger. Also lets you use the ps command to list information on all processes.

SUPERUSER.SETPRIORITY -- lets you set your own priority.

Fifteen Minute Project to Improve Your RACF

Here's a basic check to see if your RACF implementation is as comprehensive as it should
be (according to our highly biased, but completely correct opinion):

Are All Paths Into Your System Controlled by RACF?

Are BATCHALLRACF and XBMALLRACF (in SETR LIST) active?

Does RACF control all TSO logons (Perhaps with a TSOPROC resource class rule
named **. Don't assume that just because you use RACF with TSO that RACF
controls all TSO logons!)

Do all started tasks have RACF userids associated with them? (An entry named *
in the Started Procedures table, as seen in DSMON)

Do all CICS regions call RACF for all signons? (Are they CICS release 3 or higher?)

Do all IMS regions call RACF for all signons? (See the macro set by the IMS
system programmer.)

Do batch jobs for each production application have a userid which is unique to
that application? (Use the SURROGAT resource class to authorize your job
scheduling software to submit such batch jobs to the internal reader without
providing the password.)

Are all NJE jobs controlled with RACF userids? (Use the NODES resource class.)

Does every applid (that is, every program which VTAM lets you sign onto from a
terminal) call RACF to check out your userid and password? (If not, revoking the
RACF userid of someone fired for dishonesty won't necessarily cut that person off
from the system. Take your VTAM system programmer to lunch to discuss this
one.)

Once you get to RACF 2.8, have you made all userids which should be protected
be protected? (that is, all started task userids, all production batch userids, CICS
pre-defined terminal userids, CICS default userids, and other userids which should
never be capable of logon with a password, and which should never be revoked.
See last issue.)

Are All Datasets Protected by RACF?

Is PROTECTALL turned on in SETR LIST?

Is TAPEDSN turned on in SETR LIST?

Is Erase-On-Scratch turned on, at least for selected disk datasets? (And is there a
process in place to determine which datasets should be protected this way, while
ensuring that there is no performance problem?). Find out if your disk drives have
the hardware feature which makes EOS so fast that it's almost impossible to have
performance problems with it.

Is the UACC for almost all datasets set to NONE?

Do you know that GLOBAL rules don't undercut dataset rules in the RACF
database?

Do you control Bypass Label Processing (BLP) for tape datasets with the FACILITY
class rule named ICHBLP (and the TAPEVOL class active)?

Are All Appropriate Resource Protected by RACF?

Do you have a list of all resource classes in your shop (from DSMONM perhaps?)
with markings to indicate which ones you have agreed to use and which you have
decided not to use?

Have you identified the owner of each resource class on this list?

Have you turned on AUDIT for every resource class (except perhaps the UNIX
ones)?

Have you activated every class which you have agreed to use?

Do You Have a Plan in Place to Address These Issues?

Do you have such a plan in writing?

Has your boss seen this plan? (If not, she probably thinks that all you do is reset
passwords and kill production jobs.)

Do you report progress against this plan to your boss? To your sub-ordinates?

This checklist helps you to determine whether your RACF implementation is
comprehensive, and to some degree whether your RACF implementation is managed. In a future
issue, we will provide a separate checklist to help you determine the quality of your RACF
implementation, as opposed to its completeness. WARNING: Don't let your auditor see any of
these checklists.

Critical Performance Tips From George Fogg on the RACF List Server:

Apply the PTF described in APAR OW30858 if you use RACF and WEB services.

Ask your system programmer to make sure that these VLF classes are defined:
IRRACEE, IRRGTS, IRRGMAP, IRRUMAP, and IRRSMAP.

Restrict or limit the use of LISTUSER * and SEARCH CLASS(USER) NOMASK
with large amounts of output. If you use these commands in CLISTs to feed the
output into your own report generator, find a different way. For example, use the
RACF Database Unload utility or one of the tools listed in this issue under
"Permanently Interesting Products".

Our next meeting will be at Prudential Securities. Our speakers will be Hayim Sokolsky of
Vanguard on the subject: "How to Secure SDSF with RACF" and Stu Henderson on the topic: "How
to Break Into an OS/390 System". 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, January, 12, 2000 from 1PM until it's too late to go back to the office.

Place: Prudential Securities at One Seaport Plaza, aka 199 Water Street, (on Water Street between
Fulton and John Streets in downtown Manhattan in the Peking Room on the 9th Floor Here
are some useful subway stops:
---IRT 2 or 3: Fulton Street stop, proceed east about 2 short blocks;
---IND A: Broadway-Nassau Street stop, proceed east about 4 short blocks;
---IND E: Chambers Street stop (last stop), proceed east about 6 short blocks;
---Lex 4 or 5: Fulton Street stop, proceed east about 4 short blocks;
---BMT N or R: Cortlandt Street stop, proceed east about 6 short blocks.
As you can see, Water Street overlooks the East River, near the Brooklyn Bridge.
==============================================================
BWRUG (Baltimore/Washington RUG):

The BWRUG will not meet this quarter. Our next meeting is
scheduled for April 13, 2000.

Wherever You Live or Work:

Why not see if your organization can host a meeting for your local
RUG?

Permanently Interesting Products Column

We have not evaluated these, but think every RACF shop should know about them.

CONSUL/RACF including CICS Toolkit. Call Brent Phillips at (888) 323-0880
for information. On the Internet: http://www.consul.com

RACF Password Cracker Program, no longer free, but with more features than
the free version (see related article earlier in this issue). Email Kurt
Meiser at kmeiser@ibm.net or mail request to ITSS, 11 Phillips Road,
Poughkeepsie, NY 12603 USA.

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.