RACF Users' News # 44

March, 1998 Newsletter

Issue No. 44

RACF is a trademark of IBM. This newsletter is not affiliated with IBM in any
way.

Another Case of Automatic Translation with
RACF Userids to Support Single Signon

You all know how RACF can provide automatic translation of who you are to
several other products (using the UID for OMVS, the UUID for DCE, the OPIDENT
for CICS, and the ADDMEM in the NODES class for NJE). Here's another one: the
TMEADMIN resource class provides translation between a Tivoli administrator's
userid and his or her RACF userid.

Today's Question:

Given the tremendous demand for single signon products, and the number of
excellent products which try to address it, why haven't we all found a product
that meets our needs? Is there any such product which has more than a dozen
very happy users who actually use the product for most of their installation's
computers?

NEW YORK RUG Meeting Date for April

On Wednesdays, from 1 to 5 PM: April 22, 1998, and then on July 22 and October
28, 1998. Mark your calendars now. See inside for details.

BALTIMORE/WASHINGTON RUG

On Thurdays, from 9AM to Noon: April 23,
1998, and then on July 23, and October 29, 1998. Mark your calendars now.
See inside for details.

New Contact for Southern California RUG
Jay Carter is relocating to New England and has passed the reins to Mark Hahn
(the current Secretary) until elections in April. Call Mark Hahn at (818) 980-
2825 for more info.

How A Hacker Might Crack Into Your System:

Most of us use the Started Procedures Tables and/or the STARTED resource class
to assign userids to started tasks. In many cases the password for userids
associated with started tasks is easy to guess: it's the default group. This
happened years ago in many of our shops when someone needed to get a started
task going in a hurry. So he did an ADDUSER command and didn't specify a
password. In this case the password defaults to the default group for the
userid.

If this is the case is in your shop, and if any of these userids has powerful
privileges, then you are open to abuse.

Suppose for example that one of these userids has the SPECIAL attribute. A
hacker with a normal, TSO userid could submit a batch job, using the JCL to
submit TSO commands in batch. This could include for example, ALTUSER commands
to make his own userid SPECIAL. On the JOB card, the hacker would specify:
USER=userid-of-the-started-task,PASSWORD=(oldpassword,newpassword) which would
let the batch job execute under the userid of the started task.

Or suppose that one of the started task userids has permission to access some
sensitive dataset in your shop. Using the same USER= and PASSWORD= operands
on the JOB card as in the example above, any TSO user could submit a batch job
which would successfully copy or change sensitive data on your computer.

You might think that it is difficult for hackers to learn the userids of
started tasks. This is not so. RACF has a control block called the RCVT
which points to the started task table. The RCVT is pointed to by the CVT
(MVS Communications Vector Table, the "mother of all MVS control blocks"),
which is pointed to by the contents of address 16. Using the TEST command in
TSO, it is very easy for even a casual hacker to explore these control blocks.

To prevent such an attack, you might want to restrict userids assigned to
started tasks not to be usable for anything other than started tasks. Reading
the IBM documentation, it is clear that the JESINPUT resource class might be
the way to do this. And you can, by defining a rule:

RDEF JESINPUT ** UACC(READ)

and then permitting the started task userids to it with ACCESS(NONE). But
this is not as clean as it seems. Please read on.

A Surprising Difference Between IBM Documentation and Real Life:

The JESINPUT resource class is used by JES to control which userids can come
into your system through each path. For example, if JESINPUT is active, JES
will use it to determine which userids are permitted through each NJE node,
and through each RJE remote. (Each of these is a path into your system.)
Other paths into your system, such as CICS signons and IMS signons can be
controlled with the APPL resource class.

Early documentation for the JESINPUT class described rules to control access
to your system through TSO signons (TSUINRDR) and through the started task
internal reader (STCINRDR). But JES does not make use of these rules. We at
the RACF User News think that this would be worthwhile to do so, in order to
provide complete RACF control over every path into the system. Hayim, can you
consider this a formal request?

Interesting Products Column

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

-- Proginet announces a new product named SecurPass Enterprise which:

Revokes or deletes a user on all platforms when you revoke or delete
the user on RACF

Doesn't need to be installed on every platform; it just needs to be
installed on the mainframe and one server

Call Proginet at (516) 248-3362 or email at sales@proginet.com for more info.

-- IBM provides conversion services from ACF2 and TopSecret to RACF. For
more information, call Marilyn Thornton at (904) 928-4512 or e-mail
marilyn_thornton@us.ibm.com.

Names in the News

The current "Enterprise Systems Journal" profiles Alex Monaco of Brooklyn
Union Gas and the NYRUG and his techniques for managing RACF and DB2 security
(including RIOVISION).

Advice from the RACF List Server

If you are wondering which started tasks should be marked "Privileged" or
"Trusted", Simon Dodge of the GARUG points out that the IBM manual "Planning:
B1 Security", GC28-1440, Chapter 3 suggests marking the following started
tasks "Trusted": JES, MOUNT (IEEVMPCR), PSF, VTAM (aka NET), APPC, ASCH, LLA,
VLF, SMF, CATALOG, DUMPSRV, CONSOLE, SMS, and IOSAS. Any other started tasks
marked "Privileged" or "Trusted" should have a clear reason why documented in
writing. (Any errors in this item are not Simon's.)

This release lets you specify a default UID and/or GID to be used by OMVS to
identify a user when that user's RACF userid doesn't provide one. You specify
the default UID and/or GID for a system with a rule in the FACILITY class.
The rule looks like this:

RDEF FACILITY BPX.DEFAULT.USER APPLDATA('userid/groupname')

where userid is a RACF userid whose OMVS segment provides a valid UID, and
groupname is a valid RACF group whose OMVS segment provides a valid GID.

Note the use of the APPLDATA operand. You can win a Henderson Group golf
shirt if you are the first to contact Stu [at (301) 229-7187] with another use
for the APPLDATA operand, which is not already described on this page.

Release 4 Also Lets Us Do PERMIT WHEN by SYSID

Have you ever wanted to let a user access a dataset from one system, but not
from another? Well now you can, with a new operand on the PERMIT command:
WHEN(SYSID(sysid)). Another small advantage of TopSecret over RACF bites the
dust!!

Release 4 Also Fixes a Password History Problem

Before this release of RACF, when you changed a user's password, his or her
old password was not placed in the password history list in the user record.
This meant that a user could re-use a password without being stopped by RACF.
With release 4, the old password is added to the list of previously used
passwords in the user record, so that RACF can prevent the user from using it
again.

Release 4 Also Supports Digital Certificates

Release 4 provides the new DIGTCERT resource class with its CERTDATA segment
to map digital certificates to a RACF userid. Digital certificates provide
the public encryption key for a userid to validate the user's identity. (The
DIGTCERT class also uses the APPLDATA operant to specify the userid associated
with the certificate, but this usage is not valid to win the shirt described
above.) The UACC of the rule specifies the trust status of the certificate.

To manage the certificates, IBM provides a new RACF command named RACDCERT. To
use this command, you need either the SPECIAL attribute OR permission to a
FACILITY class rule named one of: IRR.DIGTCERT.LIST, IRR.DIGTCERT.ADD,
IRR.DIGTCERT.ALTER, or IRR.DIGTCERT.DELETE.

Fifteen Minute Project to Improve Your RACF

Define this rule in the NODES class:

RDEF NODES *.GROUPJ.* UACC(CONTROL) ADDMEM(&DFLTGRP)

This tells JES to use what ever the default group is at the local node for a
job's userid, no matter what group is specified in the NJE header. (Thanks to
Hayim Sokolsky of Sysdata, NYRUG, and SHARE for this. Any mistakes in this
item are not his.)

Question and Answer

Q) Our auditors are pressing us to protect "sensitive programs such as
AMASPZAP and ICKDSF". What should we do?

A) Point out to the auditors that AMASPZAP and ICKDSF now have calls built
into it to them to RACF to control their sensitive functions. Ask the
auditors for a complete list of the "sensitive programs" they think should be
controlled. (They can't give you a complete list, since it consists of [all
the programs which are APF authorized and which do not have logic or other
compensating controls to protect against abuse of their APF authorization].
The best person to develop such a list is likely the manager of system
programming, who is too busy to develop a complete list. So send him a memo
asking him to identify any programs he thinks are sensitive, and to indicate
who should be authorized to execute them. (You've just made him the owner of
the PROGRAM class, but be reasonable and don't expect a complete answer.) Be
happy with whatever he gives you, protect it accordingly, and point the
auditors at him. Rejoice that RACF no longer requires you to specify the
volser of the library for PROGRAM class rules. (Another small advantage of
TopSecret bites the dust!!)

Q) Our system programmers are trying to turn their TSO sessions into MVS
consoles. We've defined the OPERPARM segment on their RACF user profiles,
defined the consoles in the CONSOLE class, and defined the operator commands
in the OPERCMDS class. But it doesn't work and they say it's RACF's (that is,
my) fault. What should I do?

A) Define a rule in the TSOAUTH class named CONSOLE and permit them to it.
They need this authority to make their TSO sessions into master consoles.

Permanently Interesting Products Column

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

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:

Georgia RUG home page on the Internethttp://www.mindspring.com/~ajc10/garug.html