z/OS: z/OS Security Server RACF Security Administrator's
GuideSecurity Server RACF Security Administrator's Guide
IBM
SA23-2289-40
Note
Before using this information and the product it supports, read the
information in “Notices” on page 721.
This edition applies to Version 2 Release 4 of z/OS (5650-ZOS) and
to all subsequent releases and modifications until otherwise
indicated in new editions.
Last updated: 2019-12-17 © Copyright International Business
Machines Corporation 1994, 2019. US Government Users Restricted
Rights – Use, duplication or disclosure restricted by GSA ADP
Schedule Contract with IBM Corp.
Contents
Chapter 1.
Introduction.........................................................................................
1 How RACF meets security
needs.................................................................................................................1
Suggestions for assigning user
attributes.................................................................................................65
Verifying user
attributes............................................................................................................................
66 Default universal access authority
(UACC)...............................................................................................
66 Assigning security categories, levels, and labels to
users........................................................................66
Passwords and password
phrases............................................................................................................
67 Assigning password
phrases.....................................................................................................................
68 Multi-Factor Authentication for
z/OS........................................................................................................
69
Defining protected user
IDs.......................................................................................................................72
Restrictions for using protected user IDs with z/VM
systems............................................................73
SETROPTS options for automatic control of access list
authority.........................................................
136 Automatic addition of creator's user ID to access
list......................................................................
136 Automatic omission of creator's user ID from access
list................................................................
136
Specifying the encryption method for user
passwords..........................................................................137
Using started
procedures........................................................................................................................
138
Rules for defining data set
profiles....................................................................................................145
Controlling the creation of new data
sets.........................................................................................
147 Data set profile
ownership.................................................................................................................148
Data set
profiles.................................................................................................................................
148 Rules for generic data set profile
names...........................................................................................149
Automatic profile modeling for data
sets..........................................................................................156
Password-protected data
sets..........................................................................................................
158 Protecting GDG data
sets...................................................................................................................158
Protecting data sets that have duplicate
names...............................................................................159
Disallowing duplicate names for data set
profiles............................................................................
160 Using the PROTECT operand or SECMODEL for non-VSAM data
sets..............................................160 Protecting
multivolume data sets with discrete
profiles..................................................................
160
active.............................................................................................................................................
177
JCL
changes........................................................................................................................................177
Installations with
DFSMShsm............................................................................................................178
IEC.TAPERING profile in the FACILITY
class....................................................................................
178 Password-protected tape data
sets..................................................................................................
178 Using the PROTECT parameter for tape data set or tape volume
protection.................................. 178 Multivolume tape
data
sets...............................................................................................................
179 RACF authorization of bypass label processing
(BLP)......................................................................
179 Authorization requirements for
labels...............................................................................................180
Tape data set and tape volume protection with nonstandard labels
(NSL)..................................... 180 Tape data set and
tape volume protection for nonlabeled (NL)
tapes.............................................180
viii
Controlling the allocation of
devices.......................................................................................................228
Protecting LLA-managed data
sets.........................................................................................................
230 Controlling data lookaside facility (DLF) objects
(Hiperbatch)..............................................................
231 Using RACROUTE REQUEST=LIST,GLOBAL=YES
support.....................................................................
233
Defining delegated
resources.................................................................................................................
253 Steps for authorizing daemons to use delegated
resources............................................................
253
Restrictions for applications and vendor
products...........................................................................
255 Using the dynamic
CDT............................................................................................................................256
Processing options that are controlled by a shared POSIT
value.....................................................259 Rules
about disallowing generics when sharing a POSIT
value....................................................... 260
Steps for adding a dynamic class with a shared POSIT
value..........................................................
260
Changing a POSIT value for a dynamic
class..........................................................................................
261 Steps for changing a POSIT value of an existing dynamic
class.......................................................261
Guidelines for changing dynamic CDT
entries........................................................................................
262 Defining a dynamic class with generics
disallowed................................................................................264
ix
Steps for deleting a dynamic CDT
class............................................................................................
265 Disabling the dynamic
CDT......................................................................................................................267
Re-enabling a previously defined dynamic
class...................................................................................
268
Protecting program
libraries...................................................................................................................
297 Program access to data sets (PADS) in BASIC
mode........................................................................298
Choosing between the PADCHK and NOPADCHK
operands.............................................................302
Program access to data sets (PADS) in ENHANCED
mode...............................................................
303 Using EXECUTE access for programs and libraries in ENHANCED
mode.........................................304 When to use MAIN
or
BASIC..............................................................................................................304
Defining programs as MAIN or
BASIC...............................................................................................
305
How protection works for programs and
PADS......................................................................................
306 How program control
works..............................................................................................................
306 Informational messages for program
control...................................................................................
307 Authorization checking for access control to load
modules.............................................................307
Authorization checking for access control to data
sets....................................................................
308
x
Chapter 13. Program signing and
verification.....................................................
315 Overview of program signing and
verification.........................................................................................315
Enabling RACF to verify signed
programs...............................................................................................322
Overview of enabling RACF to verify signed
programs.....................................................................
322 Steps for discovering if signed programs currently execute on
your systems (optional)................326 Steps for preparing RACF
to verify signed programs (one-time
setup)........................................... 327 Steps for
verifying a signed
program.................................................................................................329
Chapter 14. Operating
considerations................................................................
333 Coordinating profile
updates...................................................................................................................333
Logging on as IBMUSER and checking initial
conditions..................................................................
335 Defining administrator user IDs for your own
use............................................................................
336 Defining at least one user ID to be used for emergencies
only........................................................ 336
Logging on as RACFADM, checking groups and users, and revoking
IBMUSER...............................336 Defining the groups
needed for the first
users..................................................................................336
Defining a system-wide
auditor.........................................................................................................337
Defining a system-wide read-only
auditor........................................................................................
337 Defining users and
groups.................................................................................................................
337 Defining group administrators, group auditors, and data
managers................................................337
Protecting system data
sets..............................................................................................................
338 Setting RACF
options.........................................................................................................................
339
Chapter 17. Providing security for
JES................................................................429
xii
Refreshing profiles for SETROPTS RACLIST processing for MGMTCLAS
and STORCLAS............... 475 DFP segment in RACF
profiles.................................................................................................................475
DFP segment in user and group
profiles...........................................................................................
475 DFP segment in data set
profiles.......................................................................................................476
How RACF uses the information in the DFP
segments.....................................................................
477 Controlling access to the DFP
segment.............................................................................................477
Controlling the use of other SMS
resources...........................................................................................
480
Using UNIXPRIV class profiles to manage z/OS UNIX
privileges..........................................................
503 Example of authorizing superuser
privileges....................................................................................
503 Allowing z/OS UNIX users to change file
ownerships.......................................................................504
Allowing z/OS UNIX users to read or search
directories..................................................................
504 Configuring the group owner for new UNIX
files...............................................................................505
Protecting file system
resources.............................................................................................................506
Administering
ACLs............................................................................................................................
506
Restricting execute access in a zFS or TFS file
system..........................................................................
510 Steps for restricting execute access in a zFS or TFS file
system......................................................510
z/OS UNIX application
considerations....................................................................................................511
Threads and
security..........................................................................................................................511
Application services and
security......................................................................................................
512 Restrictions of RACF client ACEE
support.........................................................................................513
Using a PCI cryptographic coprocessor to generate private
keys....................................................558
Migrating an ICSF private key in the PKDS from one system to
another......................................... 558
The irrcerta, irrmulti, and irrsitec user
IDs.............................................................................................
559 Renewing an expiring
certificate.............................................................................................................560
Supplied digital
certificates.....................................................................................................................564
Steps to begin using a supplied CA
certificate..................................................................................
564
Chapter 22. Controlling applications that invoke callable
services...................... 577 Authorizing
applications..........................................................................................................................577
Defining applications as RACF
users.................................................................................................
577 Defining resources that control callable
services.............................................................................
577 Activating your
authorizations...........................................................................................................
577
Activating
enveloping..............................................................................................................................
606 Disabling
enveloping................................................................................................................................607
Chapter 25. Defining and using custom
fields..................................................... 611
Overview of custom
fields.......................................................................................................................
611 Task roadmap for defining and using custom
fields...............................................................................612
Defining a custom field and its field
attributes.......................................................................................612
Authorizing users to define custom
fields..............................................................................................
619 Steps for authorizing users to define custom
fields..........................................................................619
xvi
Changing attributes of an existing custom
field.....................................................................................
621 When you need to change the data
type...........................................................................................
622 When you need to change the MAXLENGTH of a numeric
field........................................................623
Removing a custom
field.........................................................................................................................
624 Steps for removing a custom
field.....................................................................................................
624
Delegating the authority to list user information in any user
profile................................................ 629
Delegating the authority to list user information in only selected
user profiles.............................. 630 Delegating the
authority to list user information by
owner..............................................................
631 Delegating the authority to list user information by group
tree....................................................... 632
Excluding selected user
profiles........................................................................................................633
Delegating the authority to reset passwords and password
phrases....................................................634
Levels of
authority..............................................................................................................................634
Delegating the authority to reset the password for any
user........................................................... 636
Delegating the authority to reset passwords for only selected
users.............................................. 637 Delegating
the authority to reset passwords by
owner....................................................................
637 Delegating the authority to reset passwords by group
tree.............................................................
638 Excluding selected
users...................................................................................................................
640
Delegating both by owner and by group
tree..........................................................................................641
Examples of delegating help desk
authorities........................................................................................642
Delegating help desk authorities by
owner.......................................................................................642
Delegating help desk authorities by group
tree................................................................................
643 Delegating help desk authorities for all users, excluding
selected users........................................ 643
Chapter 27. Distributed identity
filters...............................................................
645 Overview of distributed identity
filters....................................................................................................645
Defining a filter for an X.500 user
identity..............................................................................................
652 Steps for defining a filter for a full X.500
DN.....................................................................................653
Steps for defining a filter using selected
RDNs.................................................................................
654
Deleting a distributed identity
filter........................................................................................................
655 Steps for deleting a distributed identity
filter...................................................................................
656
xvii
Appendix E. Debugging problems in the RACF
database..................................... 691 Checklist:
Resolving problems when access is denied
unexpectedly................................................... 691
Checklist: Resolving problems when access is allowed
incorrectly......................................................
692 When changes to data set profiles take
effect.......................................................................................
693 Authorization checking for RACF-protected
resources..........................................................................694
When authorization checking takes place and
why..........................................................................
694 Authorizing access to RACF-protected
resources............................................................................
695 Pictorial view of RACF authorization
checking..................................................................................699
Authorizing access to z/OS UNIX files and
directories.....................................................................
703 Authorizing access to RACF-protected
terminals.............................................................................
705 Authorizing access to consoles, JES input devices, APPC partner
LUs, or IP addresses................706 Authorization checking for
RACROUTE REQUEST=FASTAUTH
requests.........................................707 Authorizing
access to RACF-protected
applications........................................................................
708 Security label authorization
checking...............................................................................................
708 Relationships among the SECLABEL class, SETROPTS MLS(FAILURES),
SETROPTS
Appendix F.
Accessibility...................................................................................
717 Accessibility
features..............................................................................................................................
717 Consult assistive
technologies................................................................................................................717
Keyboard navigation of the user
interface..............................................................................................717
Dotted decimal syntax
diagrams.............................................................................................................717
2. Sample ISPF panel for
RACF.......................................................................................................................12
3. Scope of control of an attribute assigned at the group
level.....................................................................
14
4. User and group
relationships......................................................................................................................38
10. Member UGRP: Users with extraordinary group authorities: report
format statements..................... 354
11. Member UGRPCNTL: Users with extraordinary group authorities:
record selection statements........ 354
12. Report of all users with extraordinary group
authorities.......................................................................355
13. Customized record selection
criteria.....................................................................................................
358
17. Sample SQL utility statements: Creating a
table...................................................................................
361
19. Db2 utility statements required to load the
tables................................................................................362
20. Db2 utility statements required to delete the group
records................................................................362
21. Sample SQL to process revoke and resume
dates................................................................................
367
22. A sample SQL
query................................................................................................................................368
27. Searching for specific
references...........................................................................................................
373
28. Specifying a replacement
ID..................................................................................................................
373
31. Running IRRRID00 with data in SYSIN: Sample
input..........................................................................
376
32. Running IRRRID00 with data in SYSIN: Sample
output........................................................................376
33. Sample output from the IRRRID00
utility..............................................................................................378
34. Running IRRRID00 CLIST using TMP: Sample JCL
statements............................................................
378
35. An RRSF
network....................................................................................................................................
384
37. RACLINK ID(userid) LIST(*.*)
output.....................................................................................................
389
40. Which NODES profiles are
used?............................................................................................................448
41. Example: Simple NJE user
translation...................................................................................................455
42. Example: Simple NJE user translation using
&SUSER...........................................................................455
43. Example: Trusted, semitrusted, and untrusted
nodes..........................................................................
456
44. Example of a simple certificate
hierarchy..............................................................................................516
45. A high-level view of a secure z/OS handshake using a public key
network protocol........................... 519
46. Controlling access to RACDCERT functions under the FACILITY
class................................................ 527
47. Output from the RACDCERT LIST
command.........................................................................................
529
48. Output from the RACDCERT LISTRING
command................................................................................
530
50. Output from the RLIST DIGTCERT
command........................................................................................
531
52. Example of an X.500 directory information
tree....................................................................................547
53. Sample RACDCERT MAP command for creating an issuer's name
filter.............................................. 548
54. Sample output from the LISTMAP command for an issuer's name
filter..............................................549
55. Sample RACDCERT MAP commands for creating subject's name
filters..............................................550
56. Sample RACDCERT MAP command for creating a subject's and
issuer's name filter..........................551
57. Sample RACDCERT MAP commands using a model
certificate............................................................
553
58. Sample RACDCERT MAP commands not using a model
certificate......................................................
553
59. Sample RACDCERT MAP command using the NOTRUST
option...........................................................554
60. Sample RACDCERT MAP and RDEFINE commands for mapping multiple
user IDs............................ 555
61. Sample output from the LISTMAP command for a MULTIID
filter........................................................555
62. Sample RACDCERT MAP and RDEFINE commands using multiple
criteria..........................................556
63. Sample group and user structure for delegating help desk
authorities................................................642
64. Process flow of callers of RACF for RACROUTE REQUEST=AUTH
requests.........................................699
65. Process flow of SAF router for RACROUTE REQUEST=AUTH
requests................................................ 700
66. Process flow of RACF
router...................................................................................................................700
67. Process flow of RACF authorization checking, part 1 of
3.....................................................................701
68. Process flow of RACF authorization checking, part 2 of
3.....................................................................702
69. Process flow of RACF authorization checking, part 3 of
3.....................................................................703
xxi
xxii
Tables
3. Command to search for profile
names.......................................................................................................
27
5. Checklist for implementation team
activities.............................................................................................41
6. Scope of authority for user attributes at the group
level...........................................................................
62
7. Group
authorities........................................................................................................................................
87
8. Sample profile names for STARTED class
resources...............................................................................141
9. Sample data set profile names in order from most specific to
least specific (EGN off)......................... 151
10. Sample data set profile names in order from most specific to
least specific (EGN on)....................... 152
11. Protecting GDG data sets using generic
profiles...................................................................................
159
13. RACF commands used with general resource
profiles..........................................................................181
14. Choosing among generic profiles, resource group profiles, and
RACFVARS profiles...........................184
15. Sample general resource profile names in order from most
specific to least specific.........................186
16. ALTER, NONE, and CONTROL, UPDATE, and READ access authorities
for general resources............ 189
17. Comparison of GRPACC attribute with &RACGPID.** entry in
global access checking table.............. 194
18. Fields in RACF segments that correspond to RACF command
operands............................................. 201
19. Delegating authority in the FACILITY
class............................................................................................207
20. Rules for merging conflicting
profiles....................................................................................................
210
xxiii
25. Processing options controlled simultaneously for classes
sharing a POSIT value.............................. 260
26. ICHERCDE macro operands and the corresponding operands for the
RDEFINE and RALTER
commands................................................................................................................................................269
27. Correlation of record type, record name, and Db2 table
name.............................................................363
28. Return codes for the remove ID utility
(IRRRID00)...............................................................................373
29. RRSFDATA resources to control propagation of certificate
information.............................................. 408
30. Automatic command direction: Resource
names..................................................................................414
31. Resource names in the JESJOBS class for the Job Modify
SSI.............................................................441
32. NODES class operands and the UACC meaning for inbound
jobs.........................................................
449
33. NODES class operands, UACC, and SYSOUT ownership when node is
not defined to &RACLNDE..... 453
34. TSO command usage when RACF protection is
enabled......................................................................
487
35. The UNIXMAP class and VLF: Effects on performance for
installations that have not reached stage 3 of application identity
mapping..................................................................................................
500
36. Subject's and issuer's distinguished
names..........................................................................................
547
38. LDAP event notification of RACF profile
changes..................................................................................
592
40. Resource classes for z/OS
systems........................................................................................................657
41. Resource classes for z/VM
systems.......................................................................................................666
42. Functions of RACF
commands................................................................................................................669
43. Commands and operands you can issue if you have the SPECIAL or
group-SPECIAL attribute..........675
44. Commands and operands you can issue if you have the AUDITOR or
group-AUDITOR attribute.......676
45. Commands and operands you can issue if you have the ROAUDIT
attribute.......................................677
46. Commands and operands you can issue if you have the OPERATIONS
or group-OPERATIONS
attribute....................................................................................................................................................677
47. Commands and operands you can issue if you have the CLAUTH
attribute......................................... 678
xxiv
48. Commands and operands you can issue if you have a group
authority................................................ 679
49. Commands and operands you can issue if you have an access
authority............................................ 680
50. Commands and operands you can issue if you own a
profile................................................................681
51. Commands and operands you can issue for miscellaneous
reasons....................................................683
52. UACC values for system data
sets..........................................................................................................687
53. Required relationship between security levels for each MAC
checking type....................................... 710
54. Security label authorization checking when SECLABEL class is
active and either SETROPTS MLS(FAILURES) or MLS(WARNING) is in
effect......................................................................................
710
55. Security label authorization checking when SECLABEL class is
active and either SETROPTS NOMLS is in effect or the user is in
"writedown"
mode..........................................................................
711
56. Effects of MLACTIVE settings on security label
authorization..............................................................
712
57. Relationships among the SECLABEL class, SETROPTS MLS(FAILURES),
SETROPTS MLACTIVE(FAILURES), and SETROPTS
MLQUIET..................................................................................
712
58. Resource classes checked for logon and job initialization
requests.....................................................715
xxv
xxvi
About this document
This document supports z/OS (5650-ZOS) and contains information
about Resource Access Control Facility (RACF), which is part of
z/OS Security Server. This document provides information to help
the security administrator plan for and administer the RACF®
component of z/OS Security Server.
Who should use this document Security administrators, group
administrators, and other administrators who are responsible for
system data security and integrity on a z/OS system should use this
document for such tasks as:
• Planning how to use RACF to increase the security of the system •
Deciding which resources to protect • Performing administration
tasks • Coordinating with administrators of other products
Readers should be familiar with RACF concepts and terminology. The
readers of this document should also be familiar with z/OS
systems.
RACF overview information can be obtained from the RACF home page
(www.ibm.com/us-en/
marketplace/resource-access-control-facility-racf).
How to use this document Much of this document describes how to
protect resources, such as data sets, terminals, and others. In
general, you first need to define users to RACF and set some RACF
options. Then, depending on your security plan, you select classes
of resources to protect and create resource profiles for
them.
If you are reading this document for the first time, consider
reading the following parts first:
• Chapter 1, “Introduction,” on page 1 • Chapter 2, “Organizing for
RACF implementation,” on page 31 • Chapter 3, “Defining users,” on
page 43 • Chapter 4, “Defining groups,” on page 81 • “Defining
profiles for general resources” on page 181 • “Setting up the
global access checking table” on page 190 • “Getting started with
RACF (after first installing RACF)” on page 334 • Appropriate
portions of Chapter 6, “Specifying RACF options,” on page 103
Where to find more information When possible, this information uses
cross-document links that go directly to the topic in reference
using shortened versions of the document title. For complete titles
and order numbers of the documents for all products that are part
of z/OS®, see z/OS Information Roadmap.
To find the complete z/OS library, including the z/OS Knowledge
Center, see the z/OS Internet library
(www.ibm.com/servers/resourcelink/svc00100.nsf/pages/zosInternetLibrary).
To find educational material, see the IBM Education home page
(www.ibm.com/services/learning).
© Copyright IBM Corp. 1994, 2019 xxvii
Basics of z/OS RACF Administration BE870
Effective RACF Administration ES885
Exploiting the Advanced Features of RACF
IBM® provides various educational offerings for RACF. For more
information about classroom courses and other offerings, do any of
the following:
• See your IBM representative • Call 1-800-IBM-TEACH
(1-800-426-8322)
Other sources of information IBM provides customer-accessible
discussion areas where RACF may be discussed by customer and IBM
participants. Other information is also available through the
Internet.
Internet sources The following resources are available through the
Internet to provide additional information about the RACF library
and other security-related topics:
• z/OS Internet library
(www.ibm.com/servers/resourcelink/svc00100.nsf/pages/zosInternetLibrary)
• IBM Redbooks (www.ibm.com/redbooks) • Enterprise security
(www.ibm.com/systems/z/solutions/enterprise-security.html) • RACF
home page
(www.ibm.com/us-en/marketplace/resource-access-control-facility-racf)
• RACF download page
(github.com/IBM/IBM-Z-zOS/tree/master/zOS-RACF/Downloads)
How to send your comments to IBM
We invite you to submit comments about the z/OS product
documentation. Your valuable feedback helps to ensure accurate and
high-quality information.
Important: If your comment regards a technical question or problem,
see instead “If you have a technical problem” on page xxix.
Submit your feedback by using the appropriate method for your type
of comment or question: Feedback on z/OS function
If your comment or question is about z/OS itself, submit a request
through the IBM RFE Community
(www.ibm.com/developerworks/rfe/).
Feedback on IBM Knowledge Center function If your comment or
question is about the IBM Knowledge Center functionality, for
example search capabilities or how to arrange the browser view,
send a detailed email to IBM Knowledge Center Support at
[email protected].
Feedback on the z/OS product documentation and content If your
comment is about the information that is provided in the z/OS
product documentation library, send a detailed email to
[email protected]. We welcome any feedback that you have,
including comments on the clarity, accuracy, or completeness of the
information.
To help us better process your submission, include the following
information:
• Your name, company/university/institution name, and email address
• The following deliverable title and order number: z/OS Security
Server RACF Security
Administrator's Guide, SA23-2289-40 • The section title of the
specific information to which your comment relates • The text of
your comment.
When you send comments to IBM, you grant IBM a nonexclusive
authority to use or distribute the comments in any way appropriate
without incurring any obligation to you.
IBM or any other organizations use the personal information that
you supply to contact you only about the issues that you
submit.
If you have a technical problem If you have a technical problem or
question, do not use the feedback methods that are provided for
sending documentation comments. Instead, take one or more of the
following actions:
• Go to the IBM Support Portal (support.ibm.com). • Contact your
IBM service representative. • Call IBM technical support.
© Copyright IBM Corp. 1994, 2019 xxix
Summary of changes
This information includes terminology, maintenance, and editorial
changes. Technical changes or additions to the text and
illustrations for the current edition are indicated by a vertical
line to the left of the change.
Summary of changes for z/OS Version 2 Release 4 (V2R4) The
following changes are made to z/OS Version 2 Release 4
(V2R4).
New
• A new ACEE control block has been added. See Chapter 11,
“Detecting ACEE modifications,” on page 285.
• New entries for the DATASET CSDATA Record (0431) and General
Resource CSDATA Record (05J1) have been added to the table for the
correlation of record type, record name, and Db2 table name. See
“Db2 table names” on page 362 for more information.
• Chapter 25, “Defining and using custom fields,” on page 611 has
been updated to include data sets, general resources, a pointer to
the VALREXX documentation, and the update for the output heading in
all the listing commands.
• Table 22 on page 238 has been updated to include the NEWPREFIX
operand for the TARGET command. • A new entry for General Resource
SSIGNON Data Record (0530) has been added to the table for
the
correlation of record type, record name, and Db2 table name. See
“Db2 table names” on page 362 for more information.
• A new entry for General Resource JES Data Record (05L0) has been
added to the table for the correlation of record type, record name,
and Db2 table name. See “Db2 table names” on page 362 for more
information.
• “Field-level access checking” on page 196 has been updated for
the JES segment and SSIGNON segment.
• Documentation regarding PassTickets has been extensively updated,
and moved to its own chapter. Updates include:
– A new chapter has been created. See Chapter 10, “Using
PassTickets,” on page 273. – The topic “Defining profiles in the
PTKTDATA class” on page 274 has been updated. – The topic
“Protecting PassTicket keys” on page 277 has been updated. – The
topic “Converting masked keys to encrypted keys” on page 279 has
been added. – The topic “Authorization requirements for managing
PassTicket keys” on page 279 has been added. – The topic “Example
of defining a PTKTDATA class profile” on page 279 has been updated.
– The topic “Enabling the use of PassTickets” on page 282 has been
updated. – The topic “Verifying the PassTicket environment” on page
282 has been updated. – The topic “Preventing errors” on page 282
has been updated. – The topic “Auditing the use of PassTickets” on
page 283 has been added.
• “Controlling access to key labels for spool data sets” on page
466 has been added to the JES chapter.
Changed
• The topic "Using the secured signon function" has been renamed.
See Chapter 10, “Using PassTickets,” on page 273.
© Copyright IBM Corp. 1994, 2019 xxxi
• The topic "Protecting the secured signon application keys" has
been renamed. See “Protecting PassTicket keys” on page 277.
Deleted
• Removed content specific to releases prior to z/OS V2R1.
Summary of changes for z/OS Version 2 Release 3 (V2R3) The
following changes are made to z/OS Version 2 Release 3
(V2R3).
New
• The list of IBM software to add to program control has been
updated to include SYS1.CSSLIB. For more information see
“Maintaining a clean environment in BASIC or ENHANCED mode” on page
294.
• The following changes are for APAR OA52650:
– “The RACF command exits” on page 21 is updated to include the
keyword, RACPRMCK. – “Summary of commands and their functions” on
page 669 and “Other authorities” on page 682 are
updated to include the keyword, RACPRMCK. • New segments have been
added to the table for field-level access checking. See
“Field-level access
checking” on page 196. • New functionality added for “Field-level
access checking” on page 196 to improve security
administration granularity. • The topic for “Restricting the
creation of general resource profiles (GENERICOWNER and
ENHANCEDGENERICOWNER options)” on page 110 has been updated to
include information about the new ENCHANCEDGENERICOWER
option.
Changed
• The examples provided for using a supplied CA certificate have
been changed from the "Verisign Class 3 Primary CA" to the
"GeoTrust Global CA". See “Steps to begin using a supplied CA
certificate” on page 564 for more information.
• The following topics have been updated to include support for
TSO/E 8 character user IDs:
– “Command direction” on page 389 – “How automatic direction of
commands works” on page 404 – “Defining user ID associations” on
page 387.
Deleted
• The following RACF supplied certificates have been removed:
– VeriSign Class 1 Public Primary Certificate Authority – VeriSign
Class 2 Public Primary Certificate Authority – VeriSign Class 3
Public Primary Certificate Authority – VeriSign Class 1 Public
Primary Certificate Authority Generation 2 (G2) – VeriSign Class 2
Public Primary Certificate Authority - G2 – VeriSign Class 3 Public
Primary Certificate Authority - G2 – VeriSign Class 4 Public
Primary Certificate Authority - G2 – VeriSign Class 1 Public
Primary Certificate Authority - Generation 3 – VeriSign Class 2
Public Primary Certificate Authority - G3 – VeriSign Class 3 Public
Primary Certificate Authority - G3
xxxii z/OS: z/OS Security Server RACF Security Administrator's
Guide
– VeriSign Class 3 Public Primary Certificate Authority - G4 –
VeriSign Class 3 Public Primary Certificate Authority - G5 –
VeriSign Class 4 Public Primary Certificate Authority - G3 –
VeriSign Universal Root Certification Authority – Thawte Server
Certification Authority – Thawte Premium Server Certification
Authority – Thawte Personal Basic Certification Authority – Thawte
Personal Freemail Certification Authority – Thawte Personal Premium
Certification Authority – Integration Certification Authority Root
– Entrust Secure Server Root Certificate Authority – Equifax Secure
Certificate Authority – ICP-Brasil Certificate Authority - Version
1
Summary of changes for z/OS Version 2 Release 2 (V2R2) as updated
March 2017
The following changes have been made to z/OS Version 2 Release 2
(V2R2) as updated March 2017.
New information
• A new topic has been added for “MFA application bypass” on page
71.
Changed information
Deleted information
There is no deleted information in this version.
Summary of changes for z/OS Version 2 Release 2 (V2R2) as updated
June 2016
The following changes are made to z/OS Version 2 Release 2 (V2R2)
as updated June 2016.
The following changes are made to z/OS Version 2 Release 2
(V2R2).
New information
• A new topic has been added to the Defining users chapter. See
“Passwords and password phrases” on page 67 for more
information.
• A new topic has been added to including information about
multi-factor authentication. See “ Multi- Factor Authentication for
z/OS” on page 69 for more information.
• The MFA segment has been added to the table for field-level
access checking. See “Field-level access checking” on page
196.
Summary of changes xxxiii
• The MFADEF class was added to the list of classes which will
cause a VLF ACEE Cache purge when SETROPTS RACLIST / NORACLIST /
REFRESH is issued for them. See “RACF commands for flushing a VLF
cache” on page 334 for more information.
• A note has been added to include information on RRSF TCP/IP
connections in a multi-task environment. See “Establishing RACF
security for RRSF TCP/IP connections” on page 418.
• A new section has been added for “Controlling who can register a
job to a job group” on page 439. • Corrected syntax example for
AUDIT(SUCCESS(READ)) in several topics:
– “Steps for delegating the authority to list user information in
any user profile” on page 630 – “Steps for delegating the authority
to list user information by owner” on page 631 – “Steps for
delegating the authority to list user information by group tree” on
page 632 – “Steps for excluding selected user profiles” on page 633
– “Steps for delegating the authority to reset the password for any
user” on page 636 – “Steps for delegating the authority to reset
passwords by group tree” on page 639 – “Steps for excluding
selected users” on page 640 – “Delegating help desk authorities by
owner” on page 642 – “Delegating help desk authorities by group
tree” on page 643 – “Delegating help desk authorities for all
users, excluding selected users” on page 643
Changed information
• The chapter for Defining groups and users has been split into two
separate chapters. See Chapter 3, “Defining users,” on page 43 and
Chapter 4, “Defining groups,” on page 81.
• Updates have been made in regards to the restrictions for UTF-8
data values. For more information, see:
– “Operational considerations” on page 350 – “Db2 table names” on
page 362 – “Restrictions for UTF-8 data values” on page 650.
• The example for creating client browser certificates with a
locally signed certificate has been updated. See “Scenario 5:
Creating client browser certificates with a locally signed
certificate” on page 571.
Deleted information
• The topic for "Protecting the vector facility" has been removed
as it is an old reference to the 370 vector facility.
Summary of changes made in z/OS Version 2 Release 2 The following
changes are made to z/OS Version 2 Release 2 (V2R2).
This document contains information previously presented in z/OS
Security Server RACF Security Administrator's Guide, SA23-2289-00,
which supports z/OS Version 2 Release 1.
New information
• Table 22 on page 238 in “Controlling the use of operator
commands” on page 236 for the TARGET command has been updated with
the following new keywords:
– DENYINBOUND – ALLOWINBOUND
– RESETDENYINBOUNDCOUNT – MAIN – NEWMAIN – PLEXNEWMAIN
• A new topic, “Defining a system-wide read-only auditor” on page
337, has been added with the addition of the new ROAUDIT
attribute.
• The following topics in Chapter 3, “Defining users,” on page 43
have been updated to reflect the addition of the ROAUDIT
attribute:
– “Group profiles” on page 82 – “Group authorities” on page 87 –
“User profiles” on page 43 – “The base segment in user profiles” on
page 45 – “The DFP segment in user profiles” on page 47 – “The KERB
segment in user profiles” on page 48 – “The LNOTES segment in user
profiles” on page 49 – “The OMVS segment in user profiles” on page
50 – “User attributes” on page 55 – “Defining group administrators,
group auditors, and data managers” on page 337
• Additionally, “Field-level access checking” on page 196 in
Chapter 8, “Protecting general resources,” on page 181 has been
updated to include ROAUDIT amongst the list of attributes that
users can have to avoid the need for field-level access
checking.
• Topic “Allowing z/OS UNIX users to read or search directories” on
page 504, “Restricting execute access in a zFS or TFS file system”
on page 510 and “Steps for restricting execute access in a zFS or
TFS file system” on page 510 have been added to “RACF and z/OS
UNIX” on page 247.
• Chapter 21, “RACF and digital certificates,” on page 515 and
“Scenario 4: Secure server-to-server session enablement” on page
568 have been updated with information for the RDATALIB
class.
• A new certificate, STG Code Signing Certificate Authority - G2
(for RACF program signature verification for release z/OS V2R2 and
later), was added to the Appendix C, “Listings of RACF supplied
certificates,” on page 685 appendix.
• “Using the RACF database unload utility (IRRDBU00)” on page 349
is updated to indicate when IRRDBU00 requires UPDATE authority to
the input RACF database.
• “Protecting the RACF database” on page 347 is updated with
direction to see “Using the RACF database unload utility
(IRRDBU00)” on page 349 for more information on running
IRRDBU00.
• A new certificate authority was added to Appendix C, “Listings of
RACF supplied certificates,” on page 685.
• A new topic “Allowing special characters in passwords (PASSWORD
option)” on page 105 has been introduced.
• The topic “Specifying the encryption method for user passwords”
on page 137 has been rewritten to include the KDFAES method of
encryption.
• “Defining user ID associations for other users” on page 388 is
enhanced with information regarding passwords that start with '*'
and for using password phrases.
Changed information
• “Protecting data sets on spools” on page 459 has been updated to
indicate that RACF can protect data sets that reside on spool,
including spool files that JES appends to job output.
• Case 6 in “The CLAUTH attribute” on page 678 the requirement for
a discrete profile has been removed.
Summary of changes xxxv
• Step 4 in topic “Scenario 7: Sharing one certificate among
multiple servers” on page 574 of “Implementation scenarios” on page
565 has been updated for clarity.
• A new step has been added to “Authorizing access to z/OS UNIX
files and directories” on page 703 in Appendix E, “Debugging
problems in the RACF database,” on page 691
• “Levels of authority” on page 634 for READ access in “Delegating
the authority to reset passwords and password phrases” on page 634
has had the default password action removed and the restriction has
been updated to include passwords as well as password
phrases.
• “Assigning password phrases” on page 68 has been updated for the
ADDUSER and ALTUSER commands to allow the PHRASE() NOPASSWORD
combination.
• “Restrictions for using protected user IDs with z/VM systems” on
page 73 restrictions have been updated for releases prior to z/VM
Version 6 Release 2.
• “User identification and verification” on page 1 has been updated
for clarity regarding password and password phrase.
• “Summary of commands and their functions” on page 669 has been
updated to reflect that:
– a password is not required with a password phrase – the PASSWORD
or PHRASE command cannot be used to reset the password to a default
value.
• The description of PASSWORD or PHRASE in “Profile ownership
authority” on page 681 has been updated.
Deleted information
• The Using password phrases with shared downlevel systems topic is
obsolete and has been deleted. • The requirement for the NOOIDCARD
attribute in the description of NOPASSWORD “The base segment
in user profiles” on page 45 has been removed. • “Summary of steps
for defining users” on page 74 has had information regarding a
user's default
password deleted. • Text regarding the use of the DES algorithm was
removed from “The user profile” on page 16. • “Overview of
enveloping” on page 597 has had the mixed case check removed from
the topic. • As WORKATTR is not just for APPC capabilities, the
step that referencing such in “Summary of steps for defining users”
on page 74, has been removed.
xxxvi z/OS: z/OS Security Server RACF Security Administrator's
Guide
Chapter 1. Introduction
This topic introduces you to using RACF to administer security on
your system.
Over the past several years, it has become much easier to create
and access computerized information. No longer is system access
limited to a handful of highly skilled programmers; information can
now be created and accessed by almost anyone who takes a little
time to become familiar with the newer, easier- to-use, high-level
inquiry languages. As a result of this improved ease of use, the
number of people using computer systems has increased dramatically.
More and more people are becoming increasingly dependent on
computer systems and the information they store in these
systems.
As the general computer literacy and the number of people using
computers has increased, the need for data security has taken on a
new level of importance. No longer can the installation depend on
keeping data secure simply because no one knows how to access the
data. Further, making data secure does not mean just making
confidential information inaccessible to those who should not see
it; it means preventing the inadvertent destruction of files by
people who might not even know that they are improperly
manipulating data.
As the security administrator, it is your job to ensure that your
installation's data is properly protected. RACF can help you do
this.
How RACF meets security needs RACF satisfies the preferences of the
end user without compromising any of the concerns raised by
security personnel. The RACF approach to data security is to
provide an access control mechanism that:
• Offers effective user verification, resource authorization, and
logging capabilities • Supports the concept of user accountability
• Is flexible • Has little noticeable effect on the majority of end
users, and little or no impact on an installation's
current operation • Is easy to install and maintain
User identification and verification RACF controls access to and
protects resources. For a software access control mechanism to work
effectively, it must first identify the person who is trying to
gain access to the system, and then verify that the user is really
that person.
RACF uses a user ID and a system-encrypted password or password
phrase to perform its user identification and verification. When
you define a user to RACF, you assign a user ID and password or a
password phrase. The user ID identifies the person to the system as
a RACF user. The password or password phrase verifies the user's
identity.
The password or password phrase permits initial entry to the
system, at which time the person is required to choose a new
password or password phrase. Unless the user divulges it, no one
else knows the user ID-password or password phrase
combination.
During terminal processing, RACF allows the use of an operator
identification card (OIDCARD) in place of, or in addition to, the
password or password phrase. (The OIDCARD information is also
encrypted.) By requiring a user to know both the correct password
and the correct OIDCARD, you have increased assurance that the
proper user has entered the user ID.
The secured signon function provides an alternative to the RACF
password called a PassTicket, which allows workstations and client
machines to communicate with a host without using a RACF password
or password phrase. Using this function can enhance security across
a network. For more information, see Chapter 10, “Using
PassTickets,” on page 273.
Introduction
© Copyright IBM Corp. 1994, 2019 1
Authorization checking Having identified a valid user, the software
access control mechanism must next control interaction between the
user and the system resources. It must authorize not only what
resources that user can access, but also in what way the user can
access them, such as for reading only, or for updating as well as
reading. This controlled interaction, or authorization checking, is
shown in Figure 1 on page 2. Before this activity can take place,
however, someone with the proper authority at the installation must
establish the constraints that govern those interactions.
With RACF, you are responsible for protecting the system resources
(data sets, tape and DASD volumes, IMS and CICS® transactions, TSO
logon information, and terminals) and for issuing the authorities
by which those resources are made available to users. RACF records
your assignments in profiles stored in the RACF database. RACF then
refers to the information in the profiles to decide whether a user
should be permitted to access a system resource.
(1)
(7)
(2)
(6)
(3)
(5)
(4)
RACF
resource manager (such as TSO/E, CICS, or IMS).
(2) The resource manager issues a RACF request
to see if the user can access the resource.
In most cases, this is a RACROUTE macro.
In other cases, this is an independent RACF macro.
(3) RACF refers to the RACF database
(or profiles copied into storage
from the RACF database) and...
(4) ...checks the appropriate resource
profile.
profile...
(the user can or cannot access the
resource as intended) to the resource
manager.
the user request.
Figure 1. RACF authorization checking
Logging and reporting The ability to log information, such as
attempted accesses to a resource, and to generate reports
containing that information can prove useful to a resource owner,
and is very important to a smoothly functioning security
system.
Because RACF can identify and verify a user's user ID and recognize
which resources the user can access, RACF can record the events
where user-resource interaction has been attempted. This function
records actual access activities or variances from the expected use
of the system.
RACF has a number of logging and reporting functions that allow a
resource owner to identify users who attempt to access the
resource. In addition, you and your auditor can use these functions
to log all detected successful and unsuccessful attempts to access
the RACF database and RACF-protected resources. Logging all access
attempts allows you to detect possible security exposures or
threats. The logging and reporting functions are:
• Logging: RACF writes records to the system management facility
(SMF) for detected, unauthorized attempts to enter the system.
Optionally, RACF writes records to SMF for authorized attempts and
detected, unauthorized attempts to:
– Access RACF-protected resources
2 z/OS: z/OS Security Server RACF Security Administrator's
Guide
– Issue RACF commands – Modify profiles on the RACF database
RACF writes these records to an SMF data set. To list SMF records,
you can use either the RACF SMF data unload utility (IRRADU00) or
the RACF report writer.
– With the SMF data unload utility, you can translate the RACF SMF
records into a format you can browse or upload to a database,
query, or reporting package, such as Db2.
– With the report writer, you can select RACF SMF records to
produce the reports. Because the RACF report writer was stabilized
at the RACF 1.9.2 level, it cannot produce reports for all records
beyond that release.
You should keep in mind that, for each logging activity that RACF
performs, there is a corresponding increase in RACF and SMF
processing.
For more information on logging and auditing, see z/OS Security
Server RACF Auditor's Guide. For information about how to specify
logging and auditing functions, see z/OS Security Server RACF
Command Language Reference.
• Sending messages: RACF sends messages to the security console for
detected, unauthorized attempts to enter the system and for
detected, unauthorized attempts to access RACF-protected resources
or modify profiles on the RACF database.
As well as sending resource access violation messages only to the
security console, RACF allows you to send a message to a
RACF-defined TSO user. Each resource profile can contain the name
of a user to be notified when RACF denies access to the resource.
If the user is not logged on to the system at the time of the
violation, the user receives the message when logging on.
If you are auditing access attempts, and you have selected the RACF
function that issues a warning message instead of failing an
invalid access attempt (to allow for a more orderly migration to a
RACF- protected system), RACF records each attempted access. For
each access attempt that would have failed, RACF sends a warning
message (ICH408I) to the accessor, but allows the access. If a
notify user is specified in the resource profile, RACF also sends a
message to that user.
• Keeping statistical information: Optionally, RACF can keep
selected statistical information, such as the date, time, and
number of times that a user enters the system and the number of
times a single user accesses a specific resource. This information
can help the installation analyze and control its computer
operations more effectively. In addition, to allow the installation
to track and maintain control over its users and resources, RACF
provides commands that enable the installation to list the contents
of the profiles in the RACF database.
User accountability Individual accountability should probably be
one of your installation's prime security objectives. A user who
can be held individually accountable for actions is less likely to
make mistakes or take other actions that might disrupt or
compromise operations at your installation.
When an individual user accesses the system through a terminal, the
concept of individual user identity is fairly obvious. With a group
of production programs, however, it might be less clear just who
the user is. (Is it the application owner, the job scheduling
person, or the console operator?)
RACF offers you the ability to assign each user a unique
identifier. (Of course, whether you establish this degree of
accountability in all cases is an installation decision.)
In addition, RACF permits you to assign each user to one or more
groups, which are simply collections of users having common access
requirements.
RACF users
A RACF user is identified by an alphanumeric user ID that RACF
associates with the user. Note, however, that a RACF user need not
be an individual. For example, a user ID can be associated with a
started procedure. In addition, in many systems today a “user" is
equated with a function, rather than an individual. For example, a
service bureau customer might comprise several people who submit
work as a single user. Their jobs are simply charged to a single
account number. From the security standpoint, as
Introduction
Chapter 1. Introduction 3
mentioned before, equating a user ID with anything other than an
individual can be undesirable because individual accountability is
lost. However, it is up to the installation, through you, to decide
how much individual accountability is required.
RACF groups
A RACF group is normally a collection of users with common access
requirements. As such, it is an administrative convenience, because
it can simplify the maintenance of access lists in resource
profiles. By adding a user to a group, you can give that user
access to all of the resources that the group has access to.
Likewise, by removing a user from a group, you can prevent the user
from accessing those resources. You can also use groups as holding
groups or data control groups. For more information, see Chapter 4,
“Defining groups,” on page 81.
The group concept is very flexible; a RACF group can be equated
with almost any logical entity, such as a project, department,
application, service bureau customer, operations group, or systems
group. Further, individual users can be connected to several
groups. Membership and authority in these groups can be used to
control the scope of a user's activity.
What RACF controls
You can use RACF to control access to:
• The system. You can require that all users, including TSO users,
MVS™ system operators, and JES system operators (except operators
on locally attached JES3 consoles), log on and supply a password or
password phrase when logging on or submitting batch jobs. You can
also require that all users supply a security label when logging on
or submitting batch jobs.
• Many subsystems and applications, including:
– JES, including job names, JES commands, consoles, JES input
devices, spool, writers (printers) and others
– TSO – IMS – CICS – Storage Management Subsystem (SMS) – Db2 –
VTAM®
– APPC sessions • Terminals • MVS and JES consoles • Data,
including:
– Catalogs – DASD and tape data sets – DASD and tape volumes –
SYSIN and SYSOUT data on the JES spool – Message traffic
• Load modules (programs) for execution only, or copying as well •
IMS/CICS transactions • CICS files, journals, and so forth •
Installation-defined resources • APPC transactions and other
resources • Infoprint Server
For more information, see “Protecting general resources” on page
18.
Introduction
4 z/OS: z/OS Security Server RACF Security Administrator's
Guide
How users and groups are authorized to access resources
Basically, a user's authority to access a resource while operating
in a RACF-protected system at any time is determined by a
combination of these factors:
• The user's identity • The user's attributes • The user's group
authorities • The security classification of the user and the
resource profile • The access authority specified in the resource
profile
Identity: When defining a user, the security administrator assigns
a user ID consisting of 1 - 8 characters. This is the user ID with
which the user logs on to the system (or submits a batch job). When
a user attempts to access RACF-protected resources, RACF uses the
user ID to determine the user's access to those resources.
Attributes: The security administrator or a delegate can assign
attributes to each RACF-defined user. The attributes determine
various extraordinary privileges and limitations a user has when
using the system. Attributes are classified as either user-level
attributes (or, simply, user attributes) or group-level
attributes:
• User attributes: You can assign the SPECIAL, AUDITOR, ROAUDIT,
OPERATIONS, CLAUTH, GRPACC, ADSP, and REVOKE attributes at the
system level. When you assign attributes at the system level, the
privileges and limitations apply across the entire system. For
detailed information about these attributes, see “Assigning
optional user attributes” on page 13 and “User attributes” on page
55.
• Group-level attributes: When you assign an attribute at the group
level, RACF confines the privileges or limitations conveyed by the
attribute to the group to which it applies (and to resources,
users, and groups that fall within the scope of that group). For
more information about the group-SPECIAL, group- AUDITOR, and
group-OPERATIONS attributes, see “Assigning optional user
attributes” on page 13 and “User attributes” on page 55.
Group authorities: Each user that you define must be assigned
(connected) to at least one group (called the user's default
group). The security administrator or group administrator can
assign a specific level of “group authority" to each user of a
group. The group authorities are USE, CREATE, CONNECT, and
JOIN.
If a user has USE group authority within a group, the user can
access resources to which the group is authorized.
CREATE, CONNECT, and JOIN also enable the user to access resources
to which the group is authorized. However, these group authorities
also give the user administrative responsibilities and privileges.
The USE, CREATE, CONNECT, and JOIN group authorities are described
in detail in Chapter 4, “Defining groups,” on page 81.
If a user is added to a RACF group (via the CONNECT command) after
that user has already logged on, that user will have to log off and
log back on to have authority based on that group when accessing
resources in classes that have been RACLISTed.
If a user is deleted from a RACF group (via the REMOVE command)
after that user is already logged on, that user will have to log
off and log back on to not have authority based on that group when
accessing resources in classes that have been RACLISTed.
Security classification: Each user and each resource can have a
security classification specified in its profile. The security
classification can be a security level, one or more security
categories, or both. A security label is an installation-defined
name that refers to a combination of a security level and zero or
more security categories. A security level is an
installation-defined name that corresponds to a numerical security
level (the higher the number, the higher the security level). A
security category is an installation- defined name corresponding to
a department or an area within an organization that has similar
security requirements.
When a user requests access to a resource that has a security
classification, RACF compares the security classification of the
user with the security classification of the resource. For more
information on security classifications, see Chapter 5,
“Classifying users and data,” on page 93.
Introduction
Chapter 1. Introduction 5
Access authority: The access authority determines to what extent
the specified user or group can use the resource. The owner of a
profile protecting a data set or general resource (such as a tape
volume or terminal) can grant or deny a user or group access to
that resource by including the user ID or group name in the
resource profile's access list. Associated with each user ID or
group name is an access authority that determines whether the user
or group can access the resource, and if they can access the
resource, how they can use it.
The access authorities are NONE, EXECUTE, READ, UPDATE, CONTROL,
and ALTER (see Table 49 on page 680).
For data set profiles and profiles in the SERVAUTH class, an entry
in the access list might also contain the name of a program that is
associated with the user ID and the access authority. In this case,
the user must be executing that program to access the resource. For
more information, see “Program access to data sets (PADS) in BASIC
mode” on page 298 and “Program access to SERVAUTH resources in
BASIC or ENHANCED mode” on page 302.
For general resource profiles, an entry in the access list might
also contain the name of a RACF-defined terminal, console, JES
input device, partner LU, SERVAUTH resource (representing the name
of a network security zone), or CRITERIA that is associated with
the user ID and the access authority. In this case, the user must
be using the terminal, console, JES input device, partner LU name,
SERVAUTH, or CRITERIA to access the resource. For more information,
see “Conditional access lists for general resource profiles” on
page 189.
Each resource also has a universal access authority (UACC)
associated with it. The UACC can be NONE, EXECUTE, READ, UPDATE,
CONTROL, or ALTER. The UACC is the access authority allowed to any
group or non-restricted user who is not authorized in the access
list. UACC applies to all users, whether or not they are
RACF-defined, unless they are defined with the RESTRICTED
attribute. For information about assigning the RESTRICTED
attribute, see “Defining restricted user IDs” on page 73.
Using ID(*) on the access list
If you have some users who are not defined to RACF, you can use the
ID(*) entry on the access list instead of UACC to ensure that only
RACF-defined users, except those with the RESTRICTED attribute, can
access the resource. The following examples illustrate the
difference between UACC(READ) and ID(*) ACCESS(READ):
• To allow all users on the system to use a terminal, specify
UACC(READ) for the profile, as follows:
RDEFINE TERMINAL profile-name UACC(READ)
• To allow only RACF-defined users on the system to use a terminal,
specify UACC(NONE) for the profile, then issue the PERMIT command
with ID(*) and ACCESS(READ) specified:
RDEFINE TERMINAL profile-name UACC(NONE) PERMIT profile-name
CLASS(TERMINAL) ID(*) ACCESS(READ)
Neither the ID(*) entry on the access list nor the UACC is used to
allow a restricted user to access a RACF-protected resource.
RACF profiles
As the security administrator or a delegate defines authorized
users, groups, and protected resources, RACF builds profiles, which
contain the information RACF uses to control access to the
protected resources. Each profile is owned by a user or group. (By
default, the owner of a profile is the user who creates it.)
You can work with the following types of profiles:
• User profiles • Group profiles • Data set profiles • General
resource profiles
Introduction
6 z/OS: z/OS Security Server RACF Security Administrator's
Guide
User and group profiles contain descriptions of the authorized
users of a RACF-protected system. Data set and general resource
profiles contain descriptions of the resources and the levels of
authority that are necessary to access these resources.
Flexibility Because the security requirements at every installation
differ, RACF is flexible enough to assist each installation in
meeting its own security objectives. There are a number of ways
RACF accomplishes this:
• Administrative control: RACF allows you a wide range of choices
in controlling access to your installation's resources. RACF allows
you to use either centralized or decentralized administration
techniques by permitting you to delegate authority, establish
appropriate group ownership structures, and specify various
group-related user attributes. In addition, RACF provides a wide
range of processing options and installation exits.
Most RACF command functions, except those performed by RACMAP,
RVARY, SET, TARGET, the RACF report writer command (RACFRW), and
the block update command (BLKUPD), have Interactive System
Productivity Facility (ISPF) entry panels and associated help
panels. These panels make it easy to enter command options on
TSO.
• Generic profiles: RACF generic profiles allow you, your group
administrators, and other users to define profiles that consolidate
the security requirements of several similarly named resources that
have the same access requirements.
• Protection of installation-defined classes: RACF allows you to
protect your own installation-defined resource classes. To do this,
you can add entries to the class descriptor table (CDT) for the new
classes, create profiles in the class, and, when a user requests
access to a resource (or takes an action you want to control),
issue the RACROUTE REQUEST=AUTH macro from your application to
check authorization. You can control which users and groups can
access each resource in the class by defining profiles in the
class. The profiles can include access lists and other information
such as auditing, security labels, and so forth, as with profiles
in the CDT classes supplied by IBM.
See Appendix A, “Supplied RACF resource classes,” on page 657 for a
description of each CDT class supplied by IBM. See Chapter 9,
“Administering the dynamic class descriptor table (CDT),” on page
255 for details about creating installation-defined resource
classes.
• Installation exits: RACF installation exits allow you to tailor
RACF to specific needs of your installation. For more information,
see “Using RACF installation exits to customize RACF” on page
20.
Because of RACF's flexible design, you and your technical support
personnel can tailor RACF to operate smoothly within the local
operating environment.
RACF transparency No users want their data destroyed or altered by
other individuals (or themselves) except when they specifically
intend it. Unfortunately, users of all types are often reluctant to
take steps to protect what they have created. It is not uncommon to
see live data used as test data, or to see data deliberately
under-classified to avoid having to use the security procedures
that the appropriate classification would demand. In many cases,
people find it easier to ignore security procedures than to use
them. Even conscientious users can forget to protect a critical
piece of data. The solution to implementing effective security
measures, then, is to provide a security system that is transparent
(painless) to the user.
With RACF, end users need not be aware that their data is being
protected for them. Security and group administrators can use
generic profiles to make using RACF transparent to the majority of
the installation's end users. Administrators can also use profile
modelling to enhance RACF's transparency.
Implementing multilevel security If your installation's computing
system must implement multilevel security, RACF can help. For
detailed information, see z/OS Planning for Multilevel Security and
the Common Criteria.
Introduction
Chapter 1. Introduction 7
Multilevel security The United States Department of Defense (DoD)
has established security criteria for its computer systems and for
those systems that perform government work under contract. Each
system is evaluated and awarded a security rating, depending on the
extent the system protects resources and its own processing.
Although IBM does not claim compliance with any particular
criteria, the multilevel security (MLS) functions of a z/OS Version
1 Release 5 system and higher are designed to provide a high level
of security. See z/OS Planning for Multilevel Security and the
Common Criteria for details.
Characteristics of a multilevel-secure environment The security
policy that you implement in a multilevel-secure environment has as
its key feature a system of access controls that not only prevents
individuals from accessing information at a classification for
which they are not authorized, but also prevents individuals from
declassifying information. The system must protect resources of
different levels of sensitivity.
These are the key aspects of a multilevel-secure environment:
• Mandatory access control (MAC) • Security labels • Discretionary
access control (DAC) • Resource reuse • Identification and
authentication • Auditing
Mandatory access control (MAC)
Mandatory access control is a method of limiting access to
resources based on the sensitivity of the information that the
resource contains and the authorization of the user to access
information with that level of sensitivity.
You define the sensitivity of the resource by means of a security
label. The security label is composed of a security level and zero
or more security categories. The security level indicates a level
or hierarchical classification of the information (for example,
Restricted, Confidential, or Internal). The security category
defines the category or group to which the information belongs
(such as Project A or Project B). Users can access only the
information in a resource to which their security labels entitle
them. If the user's security label does not have enough authority,
the user cannot access the information in the resource.
Security labels
Security labels can be associated with all users and resources in
the system. The system uses these labels to determine if access to
a resource is allowed under the mandatory access control (MAC)
rules. Security labels, maintained in the RACF database, are
usually defined by the security administrator and can be changed
only by that person.
When a resource is exported to a device attached to a system, the
security label of the resource remains in effect. Whether the
resource resides on a single-level device, such as a tape drive
that does not process information at different levels of security
concurrently, or a multilevel