Previous topic |
Next topic |
Contents |
Contact z/OS |
Library |
PDF
Security for system data sets z/OS Security Server RACF Security Administrator's Guide SA23-2289-00 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
This topic contains some guidelines for defining UACC values for system data sets. Table 1 lists the UACC values that should be assigned to many of the system data sets. Note that your security policy might require a UACC of NONE for some data sets. For example, you can specify UACC(NONE) for macro libraries if you give READ access to programmers who need to assemble or compile programs that use those libraries. For a discussion of system data sets, see Protecting DASD system data sets. For guidelines about the security labels to assign system data sets on a multilevel-secure system, see z/OS Planning for Multilevel Security and the Common Criteria. You should consider creating a generic profile to protect system
data sets, as follows:
Specifying a UACC of NONE for the SYS1.* profile protects any system data sets that are added to the system by new products. If new system data sets need a UACC higher than NONE or a SECLABEL of SYSLOW, you can create more specific profiles for them. You should also create specific profiles for particular data sets (or groups of data sets, such as SYS1.DUMPxx data sets), using the information in Table 1. For any data set that is listed with a UACC of READ or higher, you should consider creating an entry in the global access checking table. For more information, see Setting up the global access checking table. For system data sets that are listed in the table with a UACC higher than NONE, you might prefer to specify UACC(NONE) and create an access list entry of ID(*) ACCESS(access-authority). This entry prevents restricted users and users who are not defined to RACF® from accessing the data sets. Restricted users enter the system with a user ID that is defined with the RESTRICTED attribute, and might be shared by many users. Restricted users are prevented from gaining access to protected resources through the global access checking table, UACC, or the ID(*) entry on the access list. User IDs defined with the RESTRICTED attribute must be specifically authorized with sufficient authority on the access list of any protected resource they must access. Therefore, to allow restricted users to access any data set listed with UACC of READ or higher in Table 1, each user ID with the RESTRICTED attribute must be specifically authorized at the level of access indicated by the UACC value.
|
Copyright IBM Corporation 1990, 2014
|