RACF demystified
This chapter explains how you can use the IBM Resource Access Control Facility (RACF®) to protect your network and communications. RACF uses the z/OS System Authorization Facility (SAF) to control access to resources such as data sets and IBM MVS™ commands. In a networking context, RACF resources can include networks and network services.
SAF is the high level MVS interface that allows you to plug in to any SAF-compatible security product. Although any product can use this interface, we describe only RACF in this chapter. For the equivalent capabilities in other SAF security products, see that product’s documentation.
This chapter includes the following topics:
1.1 RACF basic concepts
RACF has evolved over more than 30 years to provide protection for a variety of resources, features, facilities, programs, and commands on the z/OS platform. Because of its vast array of commands and numerous methods of protection, it is easy to become confused by RACF. This chapter tries to demystify RACF by explaining the basic concepts.
The RACF concept is simple: it keeps a record of all the resources that it protects in the RACF database. What is a resource? A resource can be a data set, a program, and even a subnetwork. RACF can, for example, set permissions for file patterns even for files that do not yet exist. Those permissions are then used if the file (or other object) is created at a later time. In other words, RACF establishes security policies rather than just permission records.
RACF initially identifies and authenticates users from a user ID and password when they log on to the system. When a user tries to access a resource, RACF checks its database. Then, based upon the information that it finds in the database, RACF either allows or denies the access request. It displays an ICH408I message if the access is denied.
To understand the basic concepts, we examine the ICH408I access denial message (see Example 1-1) to see what RACF is saying.
Example 1-1 ICH408I message
ICH408I USER(UTSM) GROUP(MTSM) NAME(TSOMON STC-USERID)
EZB.PORTACCESS.SX00.TCP2.SAPSYS CL (SERVAUTH)
INSUFFICIENT ACCESS AUTHORITY FROM EZB.PORTACCESS.*.*.SAPSYS (G)
This message means that the user is not authorized to access a resource defined as a TCP/IP port. Consider the following points:
•The user ID is UTSM.
•The user ID belongs to RACF group MTSM.
RACF keeps users with similar security access requirements in groups so that any access changes can be done simply to the group profile (record) rather than to each individual user’s profile.
•The name recorded in the RACF database for the user ID is TSOMON STC-USERID.
•The TCP/IP port that failed access has a name SAPSYS, and it belongs to the TCP/IP stack named TCP2 on z/OS system SX00.
•The TCP/IP port belongs to the resource class SERVAUTH. The resource name that we use to query RACF is EZB.PORTACCESS.SX00.TCP2.SAPSYS.
In other words, this TCP/IP port is defined to RACF as EZB.PORTACCESS.SX00.TCP2.SAPSYS. What we do not know yet is which port number, and which protocol, is really represented by this resource.
When the user ID UTSM tried to open the port named SAPSYS on the system SX00 and on TCP/IP stack TCP2, RACF checked its database for a discrete profile specific to EZB.PORTACCESS.SX00.TCP2.SAPSYS.
It did not find it, but instead found a generic profile EZB.PORTACCESS.*.*.SAPSYS, which covered the resource. A generic profile protects multiple resources having similar characteristics. The user ID UTSM was not in the access list and RACF failed the request.
Next, using the information that is shown in Example 1-2, we describe what should have been done to protect the TCP/IP port and to give proper access to the legitimate user.
Example 1-2 RACF commands to protect a TCP/IP port
SETROPTS CLASSACT(SERVAUTH)
SETROPTS RACLIST(SERVAUTH)
RDEFINE SERVAUTH EZB.PORTACCESS.*.*.SAPSYS UACC(NONE)
PERMIT EZB.PORTACCESS.*.*.SAPSYS CLASS(SERVAUTH) ID(UTSM) ACCESS(READ)
SETROPTS RACLIST(SERVAUTH) REFRESH
We examine each TSO command shown in Example 1-2, explaining why it is needed and what it does. You need to have RACF authority to issue the following commands:
•SETROPTS CLASSACT(SERVAUTH) activates the SERVAUTH class of profiles that protect resources managed by the z/OS TCP/IP stack.
When you activate a resource class, you are telling RACF to do authorization checking when an application (on behalf of a user ID) tries to access any resource protected under that class. RACF keeps resources with similar characteristics in one class. TCP/IP resources such as the stack, networks, and ports belong to the SERVAUTH class.
Another example of a resource class is OPERCMDS, which protects the use of sensitive operator commands such as VARY TCPIP.
|
Tip: In most installations, the SERVAUTH class will be active. In that case, you can skip this step. You can issue a RACF command SETROPTS LIST in TSO to check if it is active. Look in the section starting with ACTIVE CLASSES =.
|
•SETROPTS RACLIST(SERVAUTH) tells RACF to read the profiles for the SERVAUTH class from the RACF database into the RACF data space, and to activate the sharing of these in-storage profiles.
With these profiles in storage, RACF does not have to perform an input/output (I/O) to read the RACF database when making an access decision, and this improves performance.
•RDEFINE SERVAUTH EZB.PORTACCESS.*.*.SAPSYS UACC(NONE) defines a generic profile to cover all TCP/IP ports that have the name SAPSYS.
The profile that you have to define to protect the TCP/IP ports is of the format EZB.PORTACCESS.systemname.stackname.portname.
– The first two qualifiers of the profile have to be EZB.PORTACCESS. This tells the system that this profile is protecting TCP/IP ports.
– The third qualifier specifies the z/OS system name.
– The fourth qualifier specifies the name of the TCP/IP stack.
– The last qualifier is the name of the port. We have the wildcard character (*) for systemname and stackname. This will cover TCP/IP ports with name SAPSYS on all TCP/IP stacks and on all z/OS systems. Note that we have set UACC(NONE) to restrict its access.
•PERMIT EZB.PORTACCESS.*.*.SAPSYS CLASS(SERVAUTH) ID(UTSM) ACCESS(READ) gives READ access for the user ID UTSM to the TCP/IP port.
•SETROPTS RACLIST(SERVAUTH) REFRESH updates the in-storage SERVAUTH class profiles in the RACF data space.
Example 1-3 shows an example in which the socket option IPV6_NEXTHOP is sensitive and you want to restrict its usage to authorized persons.
Example 1-3 RACF commands to restrict the use of socket option IPV6_NEXTHOP
SETROPTS CLASSACT(SERVAUTH)
SETROPTS RACLIST(SERVAUTH)
RDEFINE SERVAUTH EZB.SOCKOPT.*.*.IPV6_NEXTHOP UACC(NONE)
PERMIT EZB.SOCKOPT.*.*.IPV6_NEXTHOP CL(SERVAUTH) ID(UTSM) ACCESS(READ)
PERMIT EZB.SOCKOPT.*.*.IPV6_NEXTHOP CL(SERVAUTH) ID(*) WHEN(PROGRAM(TSOMON)) ACCESS(READ)
SETROPTS RACLIST(SERVAUTH) REFRESH
Example 1-3 shows the following RACF commands:
•Defines the RACF profile to restrict the use of the IPV6_NEXTHOP socket option:
RDEFINE SERVAUTH EZB.SOCKOPT.*.*.IPV6_NEXTHOP UACC(NONE)
•Gives access for the user UTSM to use the IPV6_NEXTHOP socket option in the user’s programs:
PERMIT EZB.SOCKOPT.*.*.IPV6_NEXTHOP CL(SERVAUTH) ID(UTSM) ACCESS(READ)
You can also protect the use of the socket option by setting up any user to use the socket option, if the user is doing it from a specific program. With this method, you give authority to a program rather than to a user to access the resource (socket option).
The following command allows anyone to access the socket option, provided the user is using program TSOMON:
PERMIT EZB.SOCKOPT.*.*.IPV6_NEXTHOP CL(SERVAUTH) ID(*) WHEN(PROGRAM(TSOMON)) ACCESS(READ)
1.2 Protecting your network resources
Various network resources protected by RACF. You have seen how you can define resource profiles to protect a TCP/IP port, and also to protect the use of an IPv6 socket option. All network resources are protected by RACF in the same way. Most TCP/IP resources are protected by profiles defined in the SERVAUTH resource class.
|
Tip: All z/OS Communications Server profiles in the SERVAUTH class have EZA, EZB, or IST as the high level qualifier (HLQ).
|
Use the following method to protect a resource:
•If the SERVAUTH class is not active, activate it with the SETROPTS command. You need to perform this only once in your system (in most cases, it will already be active on your system).
•Identify the profile that protects the resource from Chapter 2, “Protecting network resources” on page 11. Define the profile with the RDEFINE command.
•Allow access to authorized users to this profile using the PERMIT command.
•Refresh the RACLIST in-storage profiles of the SERVAUTH class in the RACF data space using the SETROPTS command.
See Chapter 2, “Protecting network resources” on page 11, for more detailed information about how RACF protects the various TCP/IP resources using this method.
1.3 Protecting your programs
One of the main strengths of the z/OS platform is the exceptionally robust protection of its programs from unauthorized alteration. This is one of RACF’s most powerful features, and it protects the z/OS platform from computer viruses. Very strict controls and protection mechanisms in RACF make it almost impossible for any unauthorized person to modify programs on the z/OS platform.
z/OS security has evolved and matured over a period of more than quarter of a century. Many other operating system platforms cannot match the inherent security of the z/OS platform, because they were originally designed either with a single user in mind or for academic collaboration.
RACF uses the following mechanisms to secure programs from unauthorized access:
•Authorized Program Facility (APF)
•Program Protection by RACF resource class PROGRAM
•Program Access Control
•Controlling program access by SYSID
•The sticky bit in the UNIX environment
The following sections describe each mechanism in more detail.
1.3.1 Authorized Program Facility
z/OS protects the use of sensitive system functions and supervisor calls (SVC) using the Authorized Program Facility (APF). Programs have to be APF-authorized to use these system functions. To obtain APF authorization, a program should meet two conditions:
•It must reside in a library that is in the APF list or in the Link Pack Area (LPA).
•The program must be link-edited with authorization code AC=1.
In addition, the program libraries are protected by RACF. These protections make virus attacks unlikely on z/OS.
1.3.2 Program protection by RACF resource class PROGRAM
RACF treats program load modules as protected resources. PROGRAM is the RACF resource class that protects programs. Example 1-4 shows the RACF commands to protect a program. You use the ADDMEM parameter in RDEFINE to specify the library where the program resides.
Example 1-4 RACF command to protect a program
RDEFINE PROGRAM MYPROGRAM ADDMEM('SYS1.LINKLIB') UACC(NONE)
PERMIT MYPROGRAM CLASS(PROGRAM) ID(SOMEUSER) ACCESS(READ)
1.3.3 Program Access Control
You can use the Program Access Control facility to specify that access to a resource is allowed only if you are accessing it using a specific program. The program itself has to be in a controlled library and restricted to only authorized users.
Example 1-5 shows how to restrict the use of advanced IPV6 socket options by program access control.
Example 1-5 PADS to protect use of socket option
PERMIT EZB.SOCKOPT.*.*.IPV6_NEXTHOP CL(SERVAUTH) ID(*) WHEN(PROGRAM(TSOMON)) ACCESS(READ)
1.3.4 Controlling program access by SYSID
Access to programs (load modules) can be controlled based on the SMF system ID of the z/OS system, as shown in Example 1-6.
Example 1-6 Controlling program access by system ID
PERMIT MYPROGRAM CLASS(PROGRAM) ID(SOMEUSER) WHEN(SYSID(PROD_SYSTEM))
1.3.5 The sticky bit in the z/OS UNIX environment
Because z/OS UNIX files are not as secure as MVS data sets, sensitive programs running under z/OS UNIX do not load from the z/OS UNIX file system. z/OS will instead turn to the standard MVS search order to look for a copy of the executable file in an MVS load library. z/OS UNIX System Services uses the sticky bit on the program library to bypass loading of a program from the UNIX Systems Services file system. Often the program needs to reside in APF authorized libraries protected by program control.
The sticky bit is one of the bits in the Access Control List (ACL) of the z/OS UNIX file. To determine whether the sticky bit is set on a file (program), issue the UNIX command ls -l, as shown in Example 1-7. The T as the last character in the access list for the file IMWCGIBN indicates that its sticky bit is on. This means the system will not look for the program IMWCGIBN in the UNIX files. Instead, it will search for it in more secure authorized z/OS libraries.
Example 1-7 UNIX command to show the sticky bit
/usr/lpp/internet: >ls -l
total 40
-rw-r--r-- 2 WEBADM IMWEB envvars
-rw-r--r-- 2 WEBADM IMWEB httpd_msg.cat
drwxr-xr-x 2 WEBADM IMWEB IBM
-rwxr--r-T 2 WEBADM IMWEB IMWCGIBN
Drwxr-xr-x 2 WEBADM IMWEB logs
Drwxr-xr-x 3 WEBADM IMWEB Samples
Drwxr-xr-x 10 WEBADM IMWEB ServerRoot
/usr/lpp/internet: >
1.4 Associating a user ID with a started task
RACF makes sure that everyone who accesses the system resources is accountable. This applies to the system tasks as well. For this, RACF associates every started task (STC) with a specific user ID. RACF keeps this information in a resource class called STARTED. Example 1-8 shows how to define this to RACF.
Example 1-8 RACF commands to associate a user ID with a started task
SETROPTS GENERIC(STARTED)
SETROPTS CLASSACT(STARTED) RACLIST(STARTED)
RDEFINE STARTED TCPIP.* STDATA(USER(tcpip_user) PRIVILEGED(NO) TRUSTED(NO) TRACE(NO))
RDEFINE STARTED FTPD.* STDATA(USER(tcpip_user) PRIVILEGED(NO) TRUSTED(NO) TRACE(NO))
SETROPTS RACLIST(STARTED) REFRESH
Before you can start an STC in the system, you must tell RACF to give the STC user ID access to all the resources used by the STC using the PERMIT commands.
1.5 Setting up security for daemons in z/OS UNIX
TCP/IP and other, related daemons work in the z/OS UNIX environment and use many of its services. Therefore, it is important to understand how to set up security for daemons working in the z/OS UNIX security environment.
To set up a daemon under z/OS UNIX, complete the following steps:
1. Define a user ID for the daemon.
2. Define an OMVS segment for the user ID.
3. Give superuser authority for the user ID.
4. Give user ID access to various RACF profiles protecting the resources for which the daemon will need access.
5. Associate the user ID with the daemon.
6. For certain daemons, you have to turn the sticky bit on to indicate that the program module resides in a protected z/OS library, rather than in the z/OS UNIX file pointed to by the module.
For more information, see z/OS UNIX System Services User’s Guide, SA22-7801.
1.6 RACF multilevel security for network resources
Multilevel security (MLS) addresses government requirements for highly secure data. This supports sharing of classified information among multiple agencies on demand. As security controls become more critical in emerging on-demand virtual environments, this new technology has applications in the general business sectors, as well. This secondary layer is on the top of existing RACF resource protection.
1.6.1 Basic MLS concepts
In MLS, the resources are divided into several categories based on where they belong. For example, you can classify the resources of your organization based on departments such as PAYROLL, PERSONNEL, RESEARCH, MARKETING, SALES, PRODUCTION, and so on.
Resources in each category are further classified based on their importance and sensitivity. For example, you can classify them into GENERAL, CONFIDENTIAL, SENSITIVE, and TOP-SECRET in the ascending order of their importance and sensitivity. This classification is hierarchical, which means GENERAL would be the lowest that everyone can access. The level goes up with CONFIDENTIAL, then SENSITIVE, and the highest level is TOP-SECRET.
After this classification is done, assign a similar category and security level for each user by default. After you switch on MLS, when a user tries to access a resource, RACF checks whether the user’s security level is equal to or above that of the resource. RACF also verifies that the user and the resource belong to the same category. Thus, a user in the PERSONNEL department will be able to access a resource only in the PERSONNEL department.
1.6.2 Security levels
Also, the user should have the correct security level. For example, a user from PERSONNEL with a security level of GENERAL will not be able to access a PERSONNEL resource with a security level of CONFIDENTIAL. A user from MARKETING will not be able to access a resource from RESEARCH, though the user might have TOP-SECRET security level in the MARKETING department.
RACF uses security labels (SECLABELs) to enforce multilevel security.
SECLABELS
A security label (SECLABEL) consists of two entities:
•A security category such as PAYROLL, PERSONNEL, or RESEARCH
•A security level such as CONFIDENTIAL, SENSITIVE, or TOP-SECRET
The security administrator sets security labels for each user and each resource. When a user tries to access a resource, RACF allows access only if the security level in the user’s SECLABEL is higher or equal to the security level specified in the resource’s SECLABEL for the security category being accessed.
A user might be permitted to access several security labels, but can only be logged onto one of them at a time.
You can provide additional layers of protection for your network resources by implementing MLS. For more information, see z/OS 1.6 Security Services Update, SG24-6448.
1.7 Digital certificates in RACF
RACF allows you to create and maintain security keys, key rings, and digital certificates in the RACF database. In a client/server environment, RACF has the ability to map a client’s digital certificate to a RACF user ID either by storing the digital certificate in the RACF database or by mapping using a certificate name filter rule. A digital certificate or digital ID, issued by a certificate authority, contains information that uniquely identifies the client.
See Chapter 8, “IP Security” on page 245, for information about how to set up digital certificate keys and key rings.
1.8 More information
You can find job samples with the RACF commands that are required for z/OS Communications Server and applications in your installation library TCPIP.SEZAINST(EZARACF). Note that the high level qualifier of this library might differ in your installation.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.