version 2 release 4 z/os - ibm · z/os version 2 release 4 security server racf security...

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
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
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
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
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
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

version 2 release 4 z/os - ibm · z/os version 2 release 4 security server racf security...

Documents