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.
-------------------------------------------
San Francisco RUG Thrives in California Call Sue Odneal (510) 926-3035 for information.
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:
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.)
Release 4 of OS/390 Security Server (aka RACF 2.4) Provides Default UIDs and GIDsK
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.
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)
May 4-8, 1998 in Atlanta
Sept. 21-25, 1998 in NYC
Nov. 16-20, 1998 in Washington, DC
Feb. 22-26, 1999 in Clearwater, FL
2) HG05 (formerly HG44) Advanced RACF Administration ($850)
March 2-3, 1998 in Clearwater, FL
April 20-21, 1998 in NYC
Dec. 10-11, 1998 in Washington, DC
3) HG17 How to Be an Effective Mainframe Data Security Officer)
(covers CICS, VTAM, DB2, JES, and other security along with MVS
security, SAF, and OS/390)
(3 days in 1998 for $1150)
Mar. 30-Apl 1, 1998 in Denver, CO
May 27-29, 1998 in NYC
Dec. 7-9, 1998 in Washington, DC
4) HG40 Mastering Windows NT Security ($850)
April 6-7, 1998 in Atlanta
Oct. 19-20, 1998 in Washington, DC
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:
Georgia RUG home page on the Internet
http://www.mindspring.com/~ajc10/garug.html
IBM RACF home page:
http://www.s390.ibm.com/products/racf/racfhp.html
IBM S/390 home page, including RACF:
http://www.s390.ibm.com
IBM FTP site, including RACF stuff:
lscftp.kgn.ibm.com
IBMLink at: http://www.ibmlink.com
Palace Guard:
http://www.palaceguard.com/pgshome
Proginet:
http://www.proginet.com
Consul:
http://www.consulrisk.com
SysData:
http://www.sysdata.com
the Henderson Group:
http://www.stuhenderson.com/index.html
Stuart Henderson
Copyright ©: 1998, Stuart C. Henderson
Revised - March 25, 1998
URL:
http://www.stuhenderson.com/index.html