Read eTrust CA-ACF2 Security for z/OS and OS/390 Security Cookbook text version

eTrust CA-ACF2 Security for z/OS and OS/390

TM

z/OS and OS/390 Security Cookbook

October2002

This documentation and related computer software program (hereinafter referred to as the "Documentation") is for the end user's informational purposes only and is subject to change or withdrawal by Computer Associates International, Inc. ("CA") at any time. This documentation may not be copied, transferred, reproduced, disclosed or duplicated, in whole or in part, without the prior written consent of CA. This documentation is proprietary information of CA and protected by the copyright laws of the United States and international treaties. Notwithstanding the foregoing, licensed users may print a reasonable number of copies of this documentation for their own internal use, provided that all CA copyright notices and legends are affixed to each reproduced copy. Only authorized employees, consultants, or agents of the user who are bound by the confidentiality provisions of the license for the software are permitted to have access to such copies. This right to print copies is limited to the period during which the license for the product remains in full force and effect. Should the license terminate for any reason, it shall be the user's responsibility to return to CA the reproduced copies or to certify to CA that same have been destroyed. To the extent permitted by applicable law, CA provides this documentation "as is" without warranty of any kind, including without limitation, any implied warranties of merchantability, fitness for a particular purpose or noninfringement. In no event will CA be liable to the end user or any third party for any loss or damage, direct or indirect, from the use of this documentation, including without limitation, lost profits, business interruption, goodwill, or lost data, even if CA is expressly advised of such loss or damage. The use of any product referenced in this documentation and this documentation is governed by the end user's applicable license agreement. The manufacturer of this documentation is Computer Associates International, Inc. Provided with "Restricted Rights" as set forth in 48 C.F.R. Section 12.212, 48 C.F.R. Sections 52.227-19(c)(1) and (2) or DFARS Section 252.227-7013(c)(1)(ii) or applicable successor provisions.

2002 Computer Associates International, Inc.

All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.

Contents

Chapter 1: Introduction

Update Summary ............................................................................. What This Guide Provides ..................................................................... Documentation Set ............................................................................ Related Documentation ....................................................................... Command Notation ........................................................................... Introduction to eTrust CA-ACF2 ............................................................... Introduction to eTrust CA-ACF2 ............................................................... z/OS and OS/390 Compatibility ........................................................... Upgrade Solutions ........................................................................ Hyper Solution Delivery ................................................................... 1-1 1-2 1-2 1-2 1-4 1-5 1-5 1-5 1-5 1-6

Chapter 2: Implementing eTrust CA-ACF2 in a z/OS and OS/390 Environment

z/OS and OS/390 Release-Specific Security Concerns ............................................ z/OS V1R1 and Above .................................................................... EJBROLE and GEJROLE Resource Classes ............................................... R_cacheserv and R_proxyserv Callable Services .......................................... New Resource Added to SERVAUTH ................................................... OS/390 V2R10 ............................................................................ SERVAUTH Resource Class ............................................................ OS/390 V2R9 ............................................................................. OS/390 V2R8 ............................................................................. OS/390 V2R7 ............................................................................. UNIX System Services (USS) Support ........................................................... Starting eTrust CA-ACF2 in a USS Environment ................................................. Controlling Access to USS ..................................................................... Defining USS Users ....................................................................... Defining USS Groups ...................................................................... 2-1 2-1 2-1 2-1 2-2 2-2 2-2 2-2 2-2 2-3 2-4 2-4 2-5 2-5 2-6

Contents

0­1

Update Summary

Creating eTrust CA-ACF2 Logonid Records for USS .............................................. 2-7 Logonids Needed to Install USS ................................................................ 2-7 ServerPac and SystemPac Security Requirements ............................................. 2-7 Security Requirements for z/OS and OS/390 Installs Using the CBPDO Method ................. 2-8 Defining the OMVS Started Task Logonid ................................................... 2-8 Defining Additional Started Task Logonids ................................................. 2-10 Controlling Access to Superuser Status ......................................................... 2-11 Controlling Access to Daemons ................................................................ 2-11 Defining Servers to Use Thread-Level Security .............................................. 2-12 TSO ISHELL Support ......................................................................... 2-13 Creating an Administrator ID ................................................................. 2-14 USER Profile Records ..................................................................... 2-15 GROUP Profile Records ................................................................... 2-18 Displaying UID and GID Numbers ......................................................... 2-19 Defining a Default OMVS UID and GID .................................................... 2-19 Controlling Superuser Functions ............................................................... 2-20 Operator Commands for USS .................................................................. 2-22 Rebuilding Directories .................................................................... 2-22 Tracing USS SAF Requests ................................................................ 2-23 GSO UNIXOPTS Record ...................................................................... 2-24 Field Descriptions ........................................................................ 2-24 Displaying the UNIXOPTS Record ......................................................... 2-26

Chapter 3: Implementing USS Applications in an eTrust CA-ACF2 Environment

TCP/IP....................................................................................... 3-1 Communications Server IP for z/OS and OS/390 (TCP/IP) .................................... 3-2 TCP/IP SERVAUTH Class ................................................................. 3-2 Securing IP Addresses ..................................................................... 3-3 z/OS and OS/390 FTP ......................................................................... 3-4 Installing FTP with eTrust CA-ACF2 ........................................................ 3-5 Installing FTP with eTrust CA-ACF2 ........................................................ 3-5 ANONYMOUS Logon Feature .............................................................. 3-5 TELNET ...................................................................................... 3-6 Securing TELNET for USS .................................................................. 3-6 z/OS and OS/390 Infoprint Server .............................................................. 3-7

0­2

z/OS and OS/390 Security Cookbook

Update Summary

DOMINO for z/OS and OS/390 (Lotus Notes) Server ............................................ 3-8 z/OS and OS/390 Console for Domino ...................................................... 3-9 z/OS and OS/ 390 Console for Domino 5.0.6 and Higher ..................................... 3-9 Defining Lotus Notes Users ............................................................... 3-11 z/OS and OS/390 Component Broker Series (SOMobjects) Support............................... 3-11 z/OS and OS/390 Security Server ............................................................. 3-13 RACF ................................................................................... 3-13 DCE Security Server ......................................................................... 3-14 eTrust CA-ACF2 Support for the DCE Security Server ....................................... 3-15 z/OS and OS/390 DCE Support ........................................................... 3-18 Defining DCE under eTrust CA-ACF2 .................................................. 3-18 Distributed File Service ....................................................................... 3-20 Network File System (NFS) ................................................................... 3-22 eTrust CA-ACF2 Support for z/OS and OS/390 NFS ........................................ 3-23 Firewalls .................................................................................... 3-23 Adding Firewall Administrators to FWGRP ................................................ 3-26 Integrated Cryptographic Service Facility ...................................................... 3-26 Novell Network Services ..................................................................... 3-28 Kerberos .................................................................................... 3-28 Authentication of Principals............................................................... 3-29 Realms .................................................................................. 3-31 Shared Database Environment ............................................................ 3-32 Defining Your Local Realm ............................................................... 3-32 Defining Local Principals ................................................................. 3-33 Generating Keys for Local Principals ....................................................... 3-35 System Considerations for Key Generation ................................................. 3-35 Customizing your Foreign Environment ................................................... 3-36 Defining Foreign Realms .............................................................. 3-36 Mapping Foreign Principal Names ..................................................... 3-36 KERBLINK User Profile Record........................................................ 3-36 Controlling Applications that Invoke the R_ticketserver Callable Service .................. 3-37 HTTP Server ................................................................................ 3-38 Prerequisites............................................................................. 3-38 Installation Steps ......................................................................... 3-38 WebSphere Application Server for z/OS and OS/390 ........................................... 3-41 Authorization Checking .................................................................. 3-43 Level of Trust and Authority for Regions ................................................... 3-44

Contents

0­3

Update Summary

User Identification, Authentication and Network Security .................................... 3-45 LDAP Access Control Lists (ACLs) ..................................................... 3-45 CBIND Class ......................................................................... 3-45 EJBROLE and GEJBROLE Classes ...................................................... 3-46 SOMDOBJS Class ..................................................................... 3-47 Resource Managers ....................................................................... 3-48 Protection and Protect Directives ........................................................... 3-49 Prerequisites ............................................................................. 3-49 Installation Steps ......................................................................... 3-49 ACFCSEC ............................................................................... 3-50

Chapter 4: Controlling Access to the Hierarchical File System

Accessing a HFS Data Set from MVS ............................................................ 4-1 Controlling HFS Using the UNIX Security Model ................................................. 4-2 Processes that Affect HFS Security .............................................................. 4-3 Access Control Lists ....................................................................... 4-3 HFS FASTAUTH Checking ................................................................. 4-3 MOUNT NOSECURITY .................................................................... 4-4 Change Owner Command (CHOWN) ....................................................... 4-4 Program Control in the UNIX Environment ...................................................... 4-5 Controlling HFS using CA SAF HFS Security .................................................... 4-6 File Access Security ............................................................................ 4-7 Path Name Translation ..................................................................... 4-7 Seteuid Permission Bit Programs ............................................................ 4-9 Symbolic Links ............................................................................ 4-9 Shared HFS ............................................................................... 4-9 User File Ownership ...................................................................... 4-10 Rule Considerations ...................................................................... 4-11 Reporting ................................................................................ 4-12 Securing HFS Functions ....................................................................... 4-12 System Functions ......................................................................... 4-12 File Functions ............................................................................ 4-14 Sample Rules............................................................................. 4-16 Implementing CA SAF HFS Security ........................................................... 4-16 Exit Processing ........................................................................... 4-17 Troubleshooting .......................................................................... 4-19 CA SAF HFS Rule Generation Utility ........................................................... 4-20 CA SAF HFS Security Modification Utility ...................................................... 4-23

0­4

z/OS and OS/390 Security Cookbook

Update Summary

Chapter 5: Digital Certificate Support

Processing Digital Certificates with ACF Subcommands ......................................... CHKCERT Subcommand ................................................................. Parameter Descriptions ............................................................... Examples ............................................................................ EXPORT Subcommand ................................................................... Parameter Descriptions ............................................................... Examples ............................................................................ GENCERT Subcommand ................................................................. Parameter Descriptions ............................................................... Certificate Extensions ................................................................. GENCERT Examples ................................................................. GENREQ Subcommand .................................................................. Examples ............................................................................ CONNECT Subcommand ................................................................. Parameter Descriptions ............................................................... Examples ............................................................................ REMOVE Subcommand .................................................................. Parameter Descriptions ............................................................... Examples ............................................................................ Associating a Digital Certificate with a User .................................................... CERTDATA Profile Data Records ......................................................... Field Descriptions .................................................................... Creating CERTDATA Profile Records ...................................................... Certificate Replacement (.............................................................. Activating New CERTDATA Profile Records ........................................... Changing CERTDATA Profile Records ..................................................... Activating Changed CERTDATA Profile Records ....................................... Viewing CERTDATA Profile Records ...................................................... Deleting CERTDATA Profile Records ...................................................... Automatic Registration of Digital Certificates ............................................... Associating Multiple Digital Certificates with a User ............................................ KEYRING Profile Records ................................................................ Mapping Multiple Digital Certificates to a User ID .............................................. Digital Certificate Name Filtering .......................................................... Filtering Logic Processing ............................................................. 5-10 5-10 5-10 5-11 5-12 5-13 5-14 5-14 5-15 5-19 5-20 5-21 5-22 5-22 5-22 5-23 5-23 5-24 5-24 5-24 5-25 5-25 5-28 5-28 5-29 5-29 5-30 5-30 5-31 5-32 5-33 5-33 5-34 5-34 5-36

Contents

0­5

Update Summary

Certificate Name Filtering Options (CERTMAP) ............................................. 5-37 Field Descriptions .................................................................... 5-37 Example ............................................................................. 5-41 CERTMAP GSO Records .............................................................. 5-42 Examples ............................................................................ 5-43 Certificate Name Filtering Criteria Mapping (CRITMAP) ..................................... 5-43 Field Descriptions: .................................................................... 5-43 Example 1 ............................................................................ 5-44 Example 2 ............................................................................ 5-44 RACF to eTrust CA-ACF2 Translation .......................................................... 5-45 RACDCERT Command ................................................................... 5-45 Example 1 ............................................................................ 5-45 Example 2 ............................................................................ 5-45 Example 3 ............................................................................ 5-45 Example 4 ............................................................................ 5-46 Example 5 ............................................................................ 5-46 Example 6 ............................................................................ 5-46 Example 7 ............................................................................ 5-47 Example 8 ............................................................................ 5-47 Example 9 ............................................................................ 5-47 Example 10........................................................................... 5-47 Example 11........................................................................... 5-48 Example 12........................................................................... 5-48 Example 13........................................................................... 5-48 Example 14........................................................................... 5-49 Example 15........................................................................... 5-49 Example 16........................................................................... 5-49 Example 17........................................................................... 5-49

Chapter 6: The CA LDAP Server for OS/390 and z/OS

Requirements ................................................................................. 6-1 OS/390 and z/OS ......................................................................... 6-2 Installation ................................................................................ 6-2 Architectural Overview ........................................................................ 6-2 LDAP Server Overview ........................................................................ 6-3 CPS Manager Overview ....................................................................... 6-4 CPS Benefits .................................................................................. 6-5

0­6

z/OS and OS/390 Security Cookbook

Update Summary

CA LDAP Server for OS/390 and z/OS Capabilities.............................................. Databases ................................................................................ Access Controls ........................................................................... Configuration ............................................................................ Encryption ............................................................................... Multiple Instances ........................................................................ eTrust CA-ACF2 Support for OS/390 and z/OS NFS ......................................... IBM LDAP Server Support .....................................................................

6-5 6-5 6-5 6-6 6-6 6-6 6-6 6-7

Chapter 7: Logging UNIX System Services (USS) Security Calls

Setting Attributes ............................................................................. 7-1 The ACFRPTOM Report ....................................................................... 7-1 ACFRPTOM Parameters ................................................................... 7-2 ACFRPTOM Specific Parameters ........................................................... 7-2 Sample ACFRPTOM Output ................................................................... 7-5 Field Descriptions ......................................................................... 7-5 Service Field Values ........................................................................... 7-7 Security Credentials and File Security Packets .................................................. 7-11 Selective SMF Logging Options for USS ........................................................ 7-12

Appendix A: RACF to eTrust CA-ACF2 Translation

RACF Segments and ACF2 Profiles ............................................................. A-1 BASE and TSO Segment Considerations ..................................................... A-2 RACF Commands ............................................................................ A-4 ADDGROUP Command ................................................................... A-4 ADDSD Command ........................................................................ A-5 ADDUSER Command ..................................................................... A-5 ALTDSD Command ....................................................................... A-5 ALTGROUP Command.................................................................... A-6 ALTUSER Command ...................................................................... A-6 BLKUPD Command ....................................................................... A-7 CONNECT Command ..................................................................... A-7 DELDSO Command ....................................................................... A-7 DELGROUP Command.................................................................... A-7 DELUSER Command ...................................................................... A-8 LISTDSD, LISTGRP, and LISTUSER Commands ............................................. A-8 PASSWORD Command ................................................................... A-8

Contents

0­7

Update Summary

PERMIT Command ....................................................................... A-8 RACDCERT Command ................................................................... A-9 Example 1 ............................................................................ A-9 Example 2 ............................................................................ A-9 Example 3 ........................................................................... A-10 Example 4 ........................................................................... A-10 Example 5 ........................................................................... A-10 Example 6 ........................................................................... A-11 Example 7 ........................................................................... A-11 Example 8 ........................................................................... A-11 Example 9 ........................................................................... A-11 Example 10.......................................................................... A-12 Example 11.......................................................................... A-12 Example 12.......................................................................... A-12 Example 13.......................................................................... A-12 Example 14.......................................................................... A-13 Example 15.......................................................................... A-13 Example 16.......................................................................... A-13 Example 17.......................................................................... A-14 RALTER Command ..................................................................... A-14 RDEFINE Command..................................................................... A-14 RDELETE Command .................................................................... A-14 REMOVE Command ..................................................................... A-14 RLIST Command ........................................................................ A-15 RVARY Command ...................................................................... A-15 SEARCH Command ..................................................................... A-15 SETROPTS Command ................................................................... A-15 RACF Attribute Translation .................................................................. A-16 Program Control (PADS) ..................................................................... A-17 RACF Attributes ............................................................................ A-17

Index

0­8

z/OS and OS/390 Security Cookbook

Chapter

1

Introduction

This guide explains how to implement UNIX System Services (OMVS) in an eTrust CA-ACF2 Security for z/OS and OS/390 (hereafter referred to as eTrust CA-ACF2) environment. Traditional security tasks such as CICS and data set protection are largely unaffected by z/OS and OS/390 and are covered in the standard eTrust CA-ACF2 guides. Additional information regarding the administrative commands used in this book can also be found in the Administrator Guide.

Update Summary

This version (March 2002) of the Cookbook replaces the earlier versions of this cookbook. Several updates presented in the Cookbook were made at the request of eTrust CA-ACF2 clients. Contact eTrust CA-ACF2 Support with any suggestions for improving this guide. The following table lists the March 2002 updates and changes made in this document: Chapter 2 2 2 3 Description Added clarification about SAF extract call Added note about PSWDREQ option and default logonid Added HFSSEC to GSO UNIXOPTS Record Added note about ICSF processing in a CICS environment Add section on the HTTP server See Topic Defining a Default OMVS UID and GID Defining a Default OMVS UID and GID GSO UNIXOPTS Record Integrated Cryptographic Service Facility HTTP Server

3

Introduction

1­1

What This Guide Provides

What This Guide Provides

"Introduction"--Presents information about the contents and organization of the Cookbook as well as accessing online information through StarTCC. "Implementing eTrust CA-ACF2 in a z/OS and OS/390 Environment"-- Explains how to implement eTrust CA-ACF2 in a z/OS and OS/390 environment and discusses the z/OS and OS/390 changes that affect security. "Implementing USS Applications in an eTrust CA-ACF2 Environment"-- Explains how to implement various applications that run under USS in an eTrust CA-ACF2 z/OS and OS/390 environment. "Controlling Access to the Hierarchical File System"--Describes how to secure the Hierarchical File System using a UNIX model of security internal to USS and external security using standard eTrust CA-ACF2 security rules. "Digital Certificate Support"--Describes security-related tasks used to create, maintain and process digital certificate. "The CA LDAP Server for OS/390 and z/OS"--The CA LDAP Server for z/OS and OS/390." Describes CA's LDAP server and its components. It provides an overview of the database accesses provided via the LDAP protocol. "Logging UNIX System Services (USS) Security Calls"--Describes how to use the ACFRPTOM report to monitor user activity in a USS environment and other auditing activities. "RACF to eTrust CA-ACF2 Translation"--Appendix A: RACF to eTrust CA-ACF2 Translation." Describes RACF terminology for eTrust CA-ACF2 systems administrators. "Index"--Provides a quick way to find topics and key words.

Documentation Set

In addition to this guide, several other guides comprise the eTrust CA-ACF2 documentation set. A complete list of the documentation can be found in the Administrator Guide.

Related Documentation

With eTrust CA-ACF2 , Computer Associates distributes a Unicenter Common Services tape and the following guides:

1­2

z/OS and OS/390 Security Cookbook

Related Documentation

Name Unicenter Common Services Administrator Guide Unicenter Getting Started CA Message Guide CA-ACTIVATOR Supplement

Contents Operating instructions for the Unicenter Common Services.

Installation procedure and installation JCL for Unicenter Common Services. Messages and codes for Unicenter Common Services. Procedures for using CA-ACTIVATOR to install and maintain Unicenter Common Services.

CA-ACTIVATOR Installation instructions, operating instructions and messages for Unicenter Implementation and User Common Services. Guide CA-Earl Reference Guide Contains detailed information about CA-Earl statements, parameters and coding rules. Also explains the CA-Earl Reporting Service. CA-Earl User Guide CA-Earl System Programmer's Guide CA-Earl Example Guide Designed for users interested in learning about CA-Earl. It presents an introduction to CA-Earl features and capabilities. Lists the installation options for CA-Earl and instructions for modifying them. Also describes size requirements and program execution. Contains sample programs that show a variety of common applications. We do not create or maintain the following guides, but they are referenced in this guide or are recommended reading: Name OS/390 UNIX System Services User's Guide OS/390 UNIX System Services Planning Catalog Number SC28-1891-10 SC28-1890-11

Introduction

1­3

Command Notation

Command Notation

This guide uses the following command notation. Enter the following exactly as they appear in command descriptions: UPPERCASE MIXed Symbols Identifies commands, keywords, and keyword values that must be coded exactly as shown. Identifies command abbreviations. The uppercase letters are the minimum abbreviation; lowercase letters are optional. All symbols (such as equal signs) must be coded exactly as shown.

The following clarify command syntax; do not type these as they appear: Lowercase [] {} Underlining | ... Indicates that you must supply a substitution (a user-supplied value). Identifies optional keywords or parameters. Requires choosing one of the keywords or parameters listed. Shows default values that need not be specified. Separates alternative keywords and/or parameters, choose one. Means the preceding items or group of items can be repeated more than once.

Sample Command

DEComp {*|ruleid|Like(ruleidmask)} [Into(dsname)]

Explanation: DEC--Command abbreviation. *--Required alternative keyword. ruleid--Required alternative keyword. Like(ruleidmask)--Required alternative keyword. Into(dsname)--Optional parameter.

1­4

z/OS and OS/390 Security Cookbook

Introduction to eTrust CA-ACF2

Introduction to eTrust CA-ACF2

eTrust CA-ACF2 protects information systems and the data they manage from unauthorized disclosure, modification, and destruction. Since its introduction, eTrust CA-ACF2 has maintained leadership in the z/OS and OS/390 marketplace through aggressive delivery of new versions, high-quality technical support services, and adaptation to the ever-changing mainframe marketplace. z/OS and OS/390 lets you install as a package the components that you would normally select when building your base operating system and major subsystems such as VTAM, Data Facility Product, UNIX System Services (USS), and JES. With each new z/OS and OS/390 release, additional components are added. eTrust CA-ACF2 provides full support of each new component. The required maintenance and administrative changes to eTrust CA-ACF2 are fully documented in the upgrade solutions, which we provide (see Upgrade Solutions later in this chapter). The majority of z/OS and OS/390 changes that affect security are related to UNIX System Services. This guide discusses this topic in detail.

z/OS and OS/390 Compatibility

When IBM releases a new version of z/OS and OS/390, we provide an upgrade solution that describes the maintenance required in eTrust CA-ACF2 to make it compatible with the new release. From then on, each version of eTrust CA-ACF2 incorporates any compatibility maintenance for the releases of z/OS and OS/390. A Version of eTrust CA-ACF2 currently supports all features of z/OS and OS/390. If you require compatibility prior to the supporting maintenance version of eTrust CA-ACF2, you can get the information from the upgrade solutions through StarTCC on the Computer Associates Web site or from Computer Associates Technical Support.

Upgrade Solutions

Upgrade (informational) solutions exist for each GA release of z/OS and OS/390. eTrust CA-ACF2 documentation changes are distributed with each new eTrust CA-ACF2 genlevel. Changes to the support of z/OS and OS/390 that occur between eTrust CA-ACF2 genlevels are documented in these upgrade solutions. Upgrade solutions exist for each release of z/OS and OS/390. They provide a list of the latest recommended maintenance and include release-specific information.

Introduction

1­5

Introduction to eTrust CA-ACF2

To receive the latest updates:

Download from StarTCC® (Computer Associates Technical Support on the Internet) at http://support.cai.com/catotalclientcare.html Call Computer Associates Technical Support and request the specific z/OS and OS/390 upgrade solution

To download from StarTCC, follow these steps from the StarTCC main menu: 1. 2. 3. 4. Select SEARCH CA KNOWLEDGE BASE ­ SIMPLE. Select UPGRAD - GENERAL UPGRADE from the product drop-down window. Enter ACF2 as the keyword. Click the SEARCH button.

The returned list will include all of the eTrust CA-ACF2 upgrade solutions. In addition to the z/OS and OS/390 specific solutions, each version of eTrust CA-ACF2 includes a general MVS UPGRADE informational solution. It is important that you review both the z/OS and OS/390 and MVS upgrade solutions. To determine if an upgrade solution has been recently updated, perform the following steps from the StarTCC main menu: 1. 2. Select DISPLAY NEWS ITEMS. The STARTCC NEWS ITEMS screen is displayed. Select the appropriate UPGRAD SOLUTIONS UPDATED SINCE xx/xx/xxxx from the list. The news items are updated on a periodic basis. The list indicates which solutions have been updated during the period. Select and view any eTrust CA-ACF2 solution that has changed.

3.

The news items list provides three weekly "updated since" options at any given time. We recommend that you check this option twice a month.

Hyper Solution Delivery

StarTCC provides the option to receive an e-mail message automatically whenever an eTrust CA-ACF2 APAR is published as a Hyper. This includes any z/OS and OS/390-related Hyper solutions.

1­6

z/OS and OS/390 Security Cookbook

Introduction to eTrust CA-ACF2

To set up this Hyper Solution Delivery option under StarTCC, follow these steps from the StarTCC main menu: 1. 2. 3. Select Hyper Solution Delivery. Select ACF2MS ­ 6.4 (or the appropriate release) ­ ACF2MS from the product group drop-down window. Click the CHECKOFF button.

Once you have completed the above steps, an e-mail message is sent automatically to your Internet e-mail address, as specified in your StarTCC profile, as soon as any new maintenance or product announcements are made. Your StarTCC profile is created when you register. You can change this profile by clicking the Update Your StarTCC Profile button.

Introduction

1­7

Chapter

2

Implementing eTrust CA-ACF2 in a z/OS and OS/390 Environment

This chapter explains how to implement the basic UNIX System Services (OMVS) functions in an eTrust CA-ACF2 Security for z/OS and OS/390 (hereafter referred to as eTrust CA-ACF2) environment. Additional information regarding the administrative commands used in this chapter can also be found in the Administrator Guide.

z/OS and OS/390 Release-Specific Security Concerns

Several z/OS and OS/390 releases have specific security requirements for eTrust CA-ACF2 users. In addition to the information provided below, it is important that you review the solutions discussed in the Upgrade Solutions section of this document. These solutions contain the latest z/OS and OS/390 release-specific implementation procedures and the latest recommended eTrust CA-ACF2 maintenance.

z/OS V1R1 and Above

EJBROLE and GEJROLE Resource Classes WebSphere 4.0 introduced the EJBROLE and GEJROLE resource classes. eTrust CA-ACF2 now allows resource names to be in mixed case to support the functioning of these resource classes. See WebSphere Application Server for z/OS and OS/390. R_cacheserv and R_proxyserv Callable Services Support has been added to eTrust CA-ACF2 for the two new SAF callable services, R_cacheserv and R_proxyserv.

Implementing eTrust CA-ACF2 in a z/OS and OS/390 Environment

2­1

z/OS and OS/390 Release-Specific Security Concerns

New Resource Added to SERVAUTH The SERVAUTH class has added the EZB.NETSTAT resource to control access to NETSTAT command output from TSO and USS shell environments.

OS/390 V2R10

SERVAUTH Resource Class OS/390 V2R10 introduces support of the SERVAUTH class to protect TCP/IP resources from unauthorized access. eTrust CA-ACF2 uses resource rules to allow sites to define this access. See TCP/IP SERVAUTH Class section.

OS/390 V2R9

DFS/SMB Password OS/390 V2R9 introduces support for the DFS/SMB password. eTrust CA-ACF2 has added this support by providing an additional field in the DCE user profile record. The DCE.PASSWORD.KEY record of the KEYSMSTR profile SSIGNON segment provides a means for indicating how the DFS/SMB password should be stored. See the KEYSMSTR Profile Record section of the Administrator Guide for additional information. Digital Certificate Key Ring and Filtering OS/390 V2R9 and introduces support for Digital Certificate Key Ring and Filtering functionality. See the "Implementing USS Applications in an eTrust CAACF2 Environment" chapter for more details.

OS/390 V2R8

Superuser Authorities OS/390 V2R8 introduces support for a more granular approach to securing superuser authorities. eTrust CA-ACF2 can be used to grant limited or selected subsets of superuser privileges to specific users, rather than having to grant complete superuser authority.

2­2

z/OS and OS/390 Security Cookbook

z/OS and OS/390 Release-Specific Security Concerns

User Limits OS/390 V2R8 introduces support for user limits. With this support, you can control the amount of resources consumed by an individual OS/390 or z/OS UNIX user. The BPXPRMxx member of PARMLIB determines resource limits for z/OS and OS/390 UNIX users as a global setting. eTrust CA-ACF2 can store user limit settings for each individual logonid. Lotus Domino OS/390 V2R8 introduces support to map an external security userid with the Lotus Domino user ID. eTrust CA-ACF2 has added the LNOTES profile record, which lets the eTrust CA-ACF2 logonid be mapped to a specific Lotus Domino user ID.

OS/390 V2R7

Fastpath File Checking If access is allowed to the BPX.SAFFASTPATH resource, internal checking is done without any external calls. Mount NOSECURITY Feature When you mount a file system or part of a file system with the NOSECURITY option, validation is done using system credentials, which are treated as a superuser allowing access. UNIXMAP Class The UNIXMAP class allows RACF to find the userid associated with a UID without reading the entire database. eTrust CA-ACF2 never had this problem and this new class is not applicable to eTrust CA-ACF2.

Implementing eTrust CA-ACF2 in a z/OS and OS/390 Environment

2­3

UNIX System Services (USS) Support

UNIX System Services (USS) Support

In environments where users move across multiple hardware platforms and operating systems to access numerous applications, security is a major concern. Sites need the same control over data and resources accessed in an open system as they have in their mainframe environment. eTrust CA-ACF2 offers security for such open environments by supporting UNIX System Services (USS) and the standards developed for a Portable Operating System Interface (POSIX). Specifically, eTrust CA-ACF2 supports these services in a USS environment:

Callable Services Hierarchical File System (HFS) A SAF Router and Interface Userid (UID) and Groupid (GID) definitions Home and Path definitions Audit Records for USS USS Security Trace Facility Digital Certificate Support

The following sections explain:

Controlling access to USS Creating eTrust CA-ACF2 logonid and profile records for USS

Controlling access to the Hierarchical File System (HFS) is described in Implementing eTrust CA-ACF2 in a z/OS and OS/390 Environment. For general information about profile records, see the Administrator Guide. For operator commands, see the Systems Programmer Guide. For information on the reporting facilities available, see the Reports and Utilities Guide.

Starting eTrust CA-ACF2 in a USS Environment

When z/OS and OS/390 starts up the address spaces associated with USS, there exists a potential for various external security calls. If the external security manager is not active, results of these calls can lead to various error messages or initialization failure. Because of this, we highly recommend that eTrust CA-ACF2 be started using the CAISEC00 member in SYS1.PARMLIB. For more information see the "Installing eTrust CA-ACF2 " chapter of the Getting Started Guide.

2­4

z/OS and OS/390 Security Cookbook

Controlling Access to USS

Controlling Access to USS

When a user attempts to enter the USS shell, eTrust CA-ACF2 verifies that the user is a USS user before initializing the shell. It also verifies that the user associated with a program attempting to access USS resources is a USS user before allowing access to the requested resource. To define a USS user, you must:

Define the user to eTrust CA-ACF2 Assign a USS GID to the group

Defining USS Users

USS recognizes users by their assigned user identification (UID) and group identification (GID) numbers. (The USS UID is not the same as eTrust CA-ACF2 UID.) UIDs and GIDs can have numeric values of zero to 2,147,483,647. A GID and UID should be unique to the user or group that it represents. Generally, you should reserve the lower number range for system use. The UID is defined in a profile record. This profile record defines a user's UID, the user's home directory, and the initial program that the user will run. The initial program is generally the shell program that the user invokes. For more information about creating profile records, see Creating eTrust CAACF2 Logonid Records for USS later in this chapter. Superusers A superuser is a special user under USS. The superuser is a trusted user who can maintain the USS system and administer security in the Hierarchical File System (HFS). A superuser's UID has a value of zero. Use caution when assigning users the superuser authority. A superuser passes all security checks and can access any file in the file system. This type of authority is similar to that of an unscoped security officer, although it does not give the user any added authority outside of USS. USS provides controls such that users need not be assigned a UID of zero. They can still retain the ability to switch to superuser status when this is required. See Controlling Access to Superuser Status later in this chapter for more information.

Implementing eTrust CA-ACF2 in a z/OS and OS/390 Environment

2­5

Controlling Access to USS

Defining USS Groups

USS security is based on user and group ownership of files and processes. eTrust CA-ACF2 uses the GROUP field of the logonid record to assign the user to a USS group. Users can also specify the group they want to be associated with at system entry time. A group profile record assigns the GID to the group. For more information about group profile records, see Creating eTrust CA-ACF2 Logonid Records for USS later in this chapter. We recommend that you assign a unique GID to each group. If you assign the same GID value to multiple groups, the groups share ownership of and access to the same files. This could cause unreliable results. For example, if you assign multiple groups the same GID and a getgrgid() service request is made, only one group name is returned in response to the request. eTrust CA-ACF2 searches its cross-reference tables and returns the first group that matches the GID; it does not return all the groups associated with that GID, nor can it distinguish the specific group for which you intended the request to be made. Supplemental Groups Under USS and eTrust CA-ACF2, a user is a member of the group defined in the GROUP field of his logonid, and a member of any other group that he has access to through a resource rule. These groups are called supplemental groups and a list of the allowed groups is built for each signon. When group access checks are performed for HFS file access, eTrust CA-ACF2 compares the GID of the file to the GID of the group defined in the logonid. If those GIDs do not match, eTrust CA-ACF2 checks to see if the file's GID matches the GID of any of the supplemental groups. If it matches, then eTrust CA-ACF2 uses the GROUP permissions to determine the user's access to the file. To grant a user access to a supplemental group, you must create a TYPE(TGR) resource rule. The $KEY of the rule identifies the one to eight character group name. This field is maskable. The following is an example of a resource rule that grants access to group OMVSGRP to users in groupa and groupb.

$KEY(OMVSGRP) TYPE(TGR) UID(groupa) ALLOW UID(groupb) ALLOW

It is required that the TGR rules be resident, so you must create an entry for the TGR type code in the GSO INFODIR record and rebuild the resident directory. For details, see the "Maintaining Global System Options Records," chapter in the Administrator Guide. You do not have to specify the GROUP field as part of the eTrust CA-ACF2 UID string for it to be used with USS. For more information about setting the owner, group, and other permissions for a file, see the IBM OS/390 UNIX System Services User's Guide.

2­6

z/OS and OS/390 Security Cookbook

Creating eTrust CA-ACF2 Logonid Records for USS

Note: The list of groups associated with a specific user's ACEE is pointed to by the ACEECGRP The UNIXOPTS GSO record NGROUPS parameter sets the maximum size of the supplemental group list created for each signon. The number of entries is set within the range of 0 through 8192 with 300 being the default.

Creating eTrust CA-ACF2 Logonid Records for USS

During the installation of USS, you must create a logonid for the OMVS started task and a logonid with USS superuser authority for one or more security administrators. In addition, any user accessing USS also must be defined. Use the steps outlined below to create these logonids.

Logonids Needed to Install USS

ServerPac and SystemPac Security Requirements

ServerPac and SystemPac Installation must be performed from a user ID that:

Is a superuser (UID=0). Notice that you must be a superuser; just having access to the BPX.SUPERUSER facility class is not sufficient. This is because the pax utility is used to unload the ServerPac HFS and this utility does not use the BPX.SUPERUSER facility class to establish superuser identification. The following example shows how to define user OMVSUSR as a superuser. Since HOME and OMVSPGM are not explicitly specified, the defaults are taken for these fields.

SET PROFILE(USER) DIV(OMVS) INSERT OMVSUSR UID(0)

Is permitted read access to facility classes BPX.FILEATTR.APF and BPX.FILEATTR.PROGCTL. The following BPX Facility class rule can be coded to accomplish this:

$KEY(BPX) TYPE(FAC) FILEATTR.- UID(user's_ uid) SERVICE(READ) ALLOW SUPERUSER UID(user's_uid) ALLOW

Note: If the FACILITY class BPX rule already exists, simply add the rule entries to the existing rule set.

Implementing eTrust CA-ACF2 in a z/OS and OS/390 Environment

2­7

Logonids Needed to Install USS

Security Requirements for z/OS and OS/390 Installs Using the CBPDO Method

When you use the CBPDO method of installing OS/390 or z/OS, you install in four stages called waves. This section describes the driving system requirements for each wave. In Wave 1 you establish an activated OMVS address space with OS/390 UNIX kernel services operating in full function mode. This installation should be performed from a user ID that:

Is a superuser (UID=0) or has access to the BPX.SUPERUSER facility resource. Is permitted read access to facility classes BPX.FILEATTR.APF and BPX.FILEATTR.PROGCTL. The following BPX Facility class rule can be coded to accomplish this:

$KEY(BPX) TYPE(FAC) FILEATTR.- UID(user's_ uid) SERVICE(READ) ALLOW SUPERUSER UID(user's_uid) ALLOW

Note: If the FACILITY class BPX rule already exists, simply add the rule entries to the existing rule set.

Defining the OMVS Started Task Logonid

First, make sure you are running with STC set in the GSO OPTS record. Then, use the following steps to create the OMVS started task logonid. For detailed information about the administrative tasks of inserting logonids or checking GSO record settings, see the Administrator Guide. 1. Create the USS kernel started task logonid and profile records by issuing the following eTrust CA-ACF2 subcommands:

SET LID INSERT OMVS NAME(USS ID) GROUP(OMVSGRP) STC UID(0) HOME(/) OMVSPGM(/bin/sh) NOMAXVIO

This example shows logonid OMVS created as a started task (STC is specified) and assigned to a group called OMVSGRP. Remember that the OMVS started task, as with any address space, needs access to the resources that it uses. Ensure that the OMVS started task has access to any resource or data set that it needs. In accordance with USS requirements, giving logonid OMVS a UID of zero designates it as a superuser. Also, the NOMAXVIO attribute prevents eTrust CA-ACF2 from canceling the OMVS address space due to violations it might encounter in processing. 2. Create a group profile record to define a GID for the group to which the logonid belongs by issuing the following eTrust CA-ACF2 subcommands:

SET PROFILE(GROUP) DIV(OMVS) INSERT OMVSGRP GID(1)

In this example, the group OMVSGRP is given a GID value of one.

2­8

z/OS and OS/390 Security Cookbook

Logonids Needed to Install USS

3.

A logonid and profile record must be defined for the BPXOINIT started task as follows:

SET LID INSERT BPXOINIT NAME(BPXOINIT STCID) STC GROUP(OMVSGRP) UID(0) HOME(/) OMVSPGM(/bin/sh)

4.

A logonid must be defined for the BPXAS started task as follows:

SET LID INSERT BPXAS NAME(BPXAS STCID) STC GROUP(OMVSGRP)

5.

The HFS file system and the files contained within this system are defined to OS/390 or z/OS as data sets. The OMVS started task must be given WRITE and ALLOCATE access to the data sets that make up the HFS mountable files. Be aware that your naming conventions for the data sets containing HFS mountable files affect how you write the eTrust CA-ACF2 access rules giving the OMVS started task access to these data sets. For example, if you mount the data set USER1.HFS.FILE to the /u/USER1 mount point, you must add an entry in the USER1 access rule allowing OMVS access to the data set. However, if you use a single high level index, such as OMVS, you only need one rule set to allow access to all of your mountable files. For example, if the data set name is OMVS.USER1.HFS.FILE, you could write a generic rule entry to allow access to multiple data sets as follows:

$KEY(OMVS) - UID(omvs) R(A) W(A) A(A)

For more information about mountable files, see the IBM document entitled OS/390 UNIX System Services Planning. 6. The use of profile records requires that eTrust CA-ACF2 build resident directories for these records. To implement this, add the following to the GSO INFODIR record:

SET CONTROL(GSO) CHANGE INFODIR TYPES(R-PUSR,R-PGRP)

To activate the new records, issue the following operator commands:

F F F F ACF2,REFRESH(INFODIR) ACF2,REBUILD(USR),CLASS(P) ACF2,REBUILD(GRP),CLASS(P) ACF2,OMVS

Note: This process is required anytime profile records are created or changed to place the changes into effect. This process is automatic when eTrust CA-ACF2 is started. 7. OMVS issues a SAF call at initialization that checks to see if access is authorized for OMVS to the FACILILTY class resource BPX.SAFFASTPATH. If access is allowed, OMVS performs permission bit checking bypassing an audit trail for any violations. If access is denied, then the external security manager performs the permission bit checking maintaining an audit trail of violations. This is referred to as FASTAUTH processing.

Implementing eTrust CA-ACF2 in a z/OS and OS/390 Environment

2­9

Logonids Needed to Install USS

You must create a FAC type rule with a $KEY of BPX as BPX is the high level for a number of facility checks related to USS processing authorization. To initially set up this rule, you must create the following control card and compile the rule:

$KEY(BPX) TYPE(FAC)

Then add the following rule entry to the BPX rule to turn off the FASTAUTH processing.

SAFFASTPATH UID(*) PREVENT

If you give the OMVS logonid the NON-CNCL privilege, the check always gets a zero return code, which activates the FASTAUTH processing. To circumvent this, you must insert the following SAFDEF record:

INSERT SAFDEF.OEFSTART FUNCRET(8) ID(OEFSTAUT) JOBNAME(OMVS) MODE(IGNORE) ­ RB(BPX-) RACROUTE(REQUEST=AUTH CLASS=FACILITY ENTITY=BPX.SAFFASTPATH) REP

Defining Additional Started Task Logonids

If your site is using TCP/IP, the INETD daemon, or a started task that monitors OMVS, such as RMFGAT, you must create started task logonids for them and define these IDs to OMVS. 1. Create the logonid and user profile records by issuing the following subcommands:

SET LID INSERT TCPIP NAME(TCPIP STCID) STC GROUP(OMVSGRP) UID(0) HOME(/) OMVSPGM(/bin/sh) INSERT INETD NAME(INETD STCID) STC GROUP(OMVSGRP) UID(0) HOME(/) OMVSPGM(/bin/sh) INSERT RMFGAT NAME(RMFGAT STCID) STC GROUP(OMVSGRP) UID(0) HOME(/) OMVSPGM(/bin/sh)

2.

Create an additional TTY group profile record. This is a default group used by OMVS and needs to be assigned a GID:

SET PROFILE(GROUP) DIV(OMVS) INSERT TTY GID(nn)

Replace the nn with an appropriate GID number. 3. Define additional started tasks logonids and their associated OMVS profile records:

INSERT INSERT INSERT INSERT INSERT INSERT INSERT INSERT INSERT OMPROUTE NAME(OMPROUTE STC Logonid) STC GROUP(OMVSGRP) UID(0) HOME(/) OROUTED NAME(OROUTED STC Logonid) STC GROUP(OMVSGRP) UID(0) HOME(/) OSNMPD NAME(OSNMPD STC Logonid) STC GROUP(OMVSGRP) UID(0) HOME(/) PAGENT NAME(PAGENT STC Logonid) STC GROUP(OMVSGRP) UID(0) HOME(/) PAGTSNMP NAME(PAGTSNMP STC Logonid) STC GROUP(OMVSGRP) UID(0) HOME(/) PORTMAP NAME(PORTMAP STC Logonid) STC GROUP(OMVSGRP) UID(0) SENDMAIL NAME(SENDMAIL STC Logonid) STC GROUP(OMVSGRP) UID(0) HOME(/) SNMPQE NAME(SNMPQE STC Logonid) STC GROUP(OMVSGRP) UID(0) HOME(/) SYSLOGD NAME(SYSLOGD STC Logonid) STC GROUP(OMVSGRP) UID(0) HOME(/)

2­10

z/OS and OS/390 Security Cookbook

Controlling Access to Superuser Status

INSERT TRAPFWD NAME(TRAPFWD STC Logonid) STC GROUP(OMVSGRP) UID(0) HOME(/) INSERT NAMED NAME(NAMED STC Logonid) STC GROUP(OMVSGRP) UID(0) HOME(/) INSERT DCAS NAME(DCAS STC Logonid) STC GROUP(OMVSGRP) UID(0) HOME(/)

4.

The SYSLOGD logonid needs access to the facility class resource BPX.SMF so that SYSLOGD can write records to SMF. Add the following entry to the facility class BPX resource rule:

SMF UID(syslog_uid) ALLOW

5.

Various servers also require access to the facility class resource BPX.DAEMON. Add the following rule entries to the facility class BPX resource rule:

DAEMON DAEMON DAEMON DAEMON UID(tcpip_uid) ALLOW UID(ftpd_uid) ALLOW UID(osnmpd_uid) ALLOW UID(syslogd_uid) ALLOW

Controlling Access to Superuser Status

The su command lets users under OMVS switch to the identity of another user. If no ID is specified, the user switches to a superuser, UID(0). You might want to use this facility as an alternative to assigning a user a UID of zero. The ability to switch to superuser status is controlled through the FACILITY class resource BPX.SUPERUSER. To control which users have the ability to use the su command, add rule entries to the BPX FACILITY resources rule, similar to this one, as appropriate:

SUPERUSER UID(user_uid) ALLOW

Controlling Access to Daemons

Daemons are long-running OMVS tasks that perform tasks on behalf of the users that use the daemons. They often use USS processes such as setuid(), seteuid(), setreuid() and spawn(). These services allow the daemon to change the caller's OS/390 or z/OS user identity. The FACILITY class resource BPX.DAEMON regulates who can use these powerful services. The OMVS kernel, OMVS, requires daemon authority. Daemons always run as superusers so they require a UID of 0. To allow daemon processes to invoke setuid() for superusers, define a superuser with a userid of BPXROOT on all systems. Note: BPXROOT is the default userid used in the z/OS and OS/390 documentation. If your site has changed this default userid, substitute that userid for BPXROOT.

Implementing eTrust CA-ACF2 in a z/OS and OS/390 Environment

2­11

Controlling Access to Daemons

Give daemon authority to the OMVS kernel by adding the following rule entry to the BPX FACILITY resource rule:

DAEMON UID(omvs) SERVICE(READ) ALLOW

Use the following commands to define the BPXROOT logonid and user profile records:

SET LID INSERT BPXROOT GROUP(OMVSGRP) UID(0) HOME(/) OMVSPGM(/bin/sh)

Note: The main difference between the OMVS logonid and the BPXROOT logonid is that BPXROOT does not have access to the FACILITY class resource BPX.DAEMON. BPXROOT is used when a daemon process invokes setuid() to change the UID to 0 and the user name has not been previously identified by getpwnam() or by the _passwd() function. This prevents giving daemon authority to a superuser who is not defined to the BPX.DAEMON resource. For more information about granting access to daemons, see the IBM document entitled OS/390 UNIX System Services Planning.

Defining Servers to Use Thread-Level Security

The FACILITY class resource BPX.SERVER controls access to the pthread_security_np service. This service lets the server establish a security context (task level ACEE) similar to an eTrust CA-ACF2 MUSASS environment. This process is called surrogation and it validates access to resources using the eTrust CA-ACF2 logonid of the user (client) instead of the server's own logonid. This resource check establishes users for whom the server can act as a surrogate. BPX.SERVER is also used to determine z/OS and OS/390 resources that the server can access while acting as a surrogate for its clients. When a server is given UPDATE access to the FACILITY class resource BPX.SERVER, this server can act as a surrogate for any client. The identity of the thread associated with the request from the server's client runs with the OS/390 or z/OS logonid of the client. All access control decisions to resources that are accessed by the client's thread are made using the eTrust CA-ACF2 logonid of the client. To define this level of security to eTrust CA-ACF2, add the necessary rule entry for each server to the BPX FACILITY resource rule:

SERVER UID(server1) SERVICE(READ,UPDATE) ALLOW

2­12

z/OS and OS/390 Security Cookbook

TSO ISHELL Support

If you give the server only READ access to the FACILITY class resource BPX.SERVER, the thread associated with the request from the server's client runs with the OS/390 or z/OS logonid of the client. However, access control decisions to resources that are accessed by the client's thread depend on whether a password is supplied by the client. If the application obtains the client's password and supplies this password when using the security service, the task level ACEE created is for an authenticated client. In this case, the server is capable of acting as a surrogate for the client. Access control decisions made by the client use the eTrust CA-ACF2 logonid of the client. If a password is not supplied, the task level ACEE created is for an unauthenticated client. In this case, both the eTrust CA-ACF2 logonid of the client and the eTrust CA-ACF2 logonid of the server are used when making access control decisions to OS/390 or z/OS resources. When a password is not supplied, resource rules must be written for BPX.SRV.userid in the SURROGAT class to allow the server to act as surrogate for clients that do not supply passwords. The following example gives READ access to BPX.SERVER for the SERVER1 application. Add the following rule entry to the BPX FACILITY resource rule:

SERVER UID(server1) SERVICE(READ) ALLOW

The following example allows SERVER1 to act as a surrogate for the unauthenticated client USER1:

SET RESOURCE(SUR) COMPILE $KEY(BPX) TYPE(SUR) SRV.USER1 UID(server1) ALLOW

Note: If the SURROGAT class BPX resource rule already exists, add the appropriate rule entries to the existing resource rule.

TSO ISHELL Support

IBM provides a TSO REXX exec, BPXWIRAC, which is used to interface between the OMVS ISHELL and RACF. eTrust CA-ACF2 provides a substitute for this exec in the eTrust CA-ACF2 CLIST data set or the CAIEXEC data set. This file contains a member with the name BPXWIRAC. To install this, ensure that the eTrust CA-ACF2 CLIST data set is added to the desired TSO PROC and ensure that this data set is concatenated ahead of the data set containing the IBM version of BPXWIRAC. The BPXISEC1 CLIST also contains the initial commands to set up required USS definitions. An eTrust CA-ACF2 version of this is supplied in CAI.SAMPJCL member ACFISEC.

Implementing eTrust CA-ACF2 in a z/OS and OS/390 Environment

2­13

Creating an Administrator ID

Note: The logonid being used to process these execs requires the appropriate eTrust CA-ACF2 and TSO authorities to execute the commands contained within the exec.

Creating an Administrator ID

The USS shell and utilities installation process creates directories in the Hierarchical File System (HFS). To perform the installation steps, the user must have superuser authority. To create a superuser administrator logonid and give it the authority it needs, follow these steps (logonid assumed to already exist): 1. Define the logonid as a superuser by issuing the following eTrust CA-ACF2 subcommands:

SET LID CHANGE sysadmin-lid UID(0) HOME(/) OMVSPGM(/bin/sh)

Logonid SYSADMIN is defined as a superuser by setting the UID value to zero. 2. Define the existing logonid as a member of a group by issuing these eTrust CA-ACF2 subcommands:

SET LID CHANGE sysadmin-lid GROUP(sysadmin-group)

The example shows a logonid changed to give it a group value so that this user can sign on and be validated as a member of that group. The members of this group would be a special subset of users who perform system-related tasks. 3. Assign the group a GID value by issuing these eTrust CA-ACF2 subcommands:

SET PROFILE(GROUP) DIV(OMVS) INSERT sysadmin-group GID(19)

In this example, the selected group is assigned a GID of 19, defining it for use in USS. 4. Set up the GROUP and USER profile records for residency by adding them to the GSO INFODIR record as follows:

CHANGE INFODIR TYPES(R-PGRP) CHANGE INFODIR TYPES(R-PUSR)

5.

Refresh the INFODIR record to make the change effective immediately by issuing this command:

F ACF2,REFRESH(INFODIR)

2­14

z/OS and OS/390 Security Cookbook

Creating an Administrator ID

6.

Rebuild the user and group profile directories to pull the changes into storage and then rebuild the OMVS table by issuing the following commands:

F ACF2,REBUILD(GRP),CLASS(P) F ACF2,REBUILD(USR),CLASS(P) F ACF2,OMVS

USER Profile Records

USS UIDs are defined to eTrust CA-ACF2 in user profile records in the eTrust CA-ACF2 Infostorage database. Specifically, you define the UID information in the OMVS segment of the user profile record. This segment contains three basic fields: UID, HOME, and OMVSPGM and six override fields.. See Profile support for user limit overrides for details on the six override fields.

UID is a numeric field that accepts values from zero to 2,147,483,647. A UID defined with a value of zero indicates that this user is a superuser. For additional information on superusers, see the IBM OS/390 UNIX System Services User's Guide. This field does not have to be unique, but we recommend that you make it unique; otherwise, individual accountability and control are lost. You should generally reserve the lower number range for system use. This field is required. Note: Do not include commas when entering a number in profiles.

The HOME field defines the initial directory pathname. This is the initial directory used when a user enters the OMVS command or enters the ISPF shell. The HOME field accepts values that are from one to 1023 characters in length. Both upper and lower case characters are allowed. If HOME is not defined, USS sets the initial directory for the user to the root directory. This field is optional. The OMVSPGM field defines the pathname of the user's USS shell program, which is the first program started when the OMVS command is entered or when a USS batch job is started using the BPXBATCH program. The OMVSPGM field accepts values that are from one to 1023 characters in length. Both upper and lower case characters are allowed. If a value is PROGRAM is not entered in the omvspgm field, USS gives control to the default shell program. This field is optional.

The following example shows how to define user OMVSUSR as a superuser. Since HOME and OMVSPGM are not explicitly specified, the defaults are taken for these fields.

SET PROFILE(USER) DIV(OMVS) INSERT OMVSUSR UID(0)

Implementing eTrust CA-ACF2 in a z/OS and OS/390 Environment

2­15

Creating an Administrator ID

This example shows how to define user OMVSU2 as a regular user. The HOME and OMVSPGM fields are defined.

SET PROFILE(USER) DIV(OMVS) INSERT OMVSU2 UID(199) HOME(/u/omvsu2) OMVSPGM(/bin/sh)

After inserting or changing any user profile records, rebuild the user profile directory as documented in the Operator Commands for USS section later in this chapter. This directory must be rebuilt before the new or changed logonid attempts to access USS resources; otherwise, the change is not recognized and access is denied. Also, remember that eTrust CA-ACF2 requires that profile user records be resident in storage. Before doing any rebuilds, ensure that these records are designated resident. To accomplish this, add them to the GSO INFODIR record with the R parameter as follows:

CHANGE INFODIR TYPES(R-PUSR)

Profile Support for User Limit Overrides The user profile record contains six fields that are used to support user limit overrides that are available at the OS/390 2.8 level. These fields supply values needed by UNIX System Services to verify a user's access. These fields are: CPUTIME--This field overrides for this user the MAXCPUTIME parameter in the BPXPRMxx member of parmlib. The value can be from 7 to 2,147,483,647. This field is not set when the record is inserted. If the field is not set, a RACROUTE EXTRACT will return a length of 4 and a value of X'FFFFFFFF'. UNIX System Services will take the system defaults set in BPXPRMxx when this field is not set. You can remove this field from the record by changing it to a null value (change user CPUTIME()). CPUTIME is only valid at OS/390 2.8 and above. ASSIZE--This field overrides for this user the MAXASSIZE parameter in the BPXPRMxx member of parmlib. The value can be from 10,485,760 to 2,147,483,647. This field is not set when the record is inserted. If the field is not set, a RACROUTE EXTRACT will return a length of 4 and a value of X'FFFFFFFF'. UNIX System Services will take the system defaults set in BPXPRMxx when this field is not set. You can remove this field from the record by changing it to a null value (change user ASSIZE()). ASSIZE is only valid at OS/390 2.8 and above. FILEPROC--This field overrides for this user the MAXFILEPROC parameter in the BPXPRMxx member of parmlib. The value can be from 3 to 65,535. This field is not set when the record is inserted. If the field is not set, a RACROUTE EXTRACT will return a length of 4 and a value of X'FFFFFFFF'. UNIX System Services will take the system defaults set in BPXPRMxx when this field is not set. You can remove this field from the record by changing it to a null value (change user FILEPROC()). FILEPROC is only valid at OS/390 2.8 and above.

2­16

z/OS and OS/390 Security Cookbook

Creating an Administrator ID

PROCUSER--This field overrides for this user the MAXPROCUSER parameter in the BPXPRMxx member of parmlib. The value can be from 3 to 32,767. This field is not set when the record is inserted. If the field is not set, a RACROUTE EXTRACT will return a length of 4 and a value of X'FFFFFFFF'. UNIX System Services will take the system defaults set in BPXPRMxx when this field is not set. You can remove this field from the record by changing it to a null value (change user PROCUSER()). PROCUSER is only valid at OS/390 2.8 and above. THREADS--This field overrides for this user the MAXTHREADS parameter in the BPXPRMxx member of parmlib. The value can be from 0 to 100,000. This field is not set when the record is inserted. If the field is not set, a RACROUTE EXTRACT will return a length of 4 and a value of X'FFFFFFFF'. UNIX System Services will take the system defaults set in BPXPRMxx when this field is not set. You can remove this field from the record by changing it to a null value (change user THREADS()). THREADS is only valid at OS/390 2.8 and above. MMAPAREA--This field overrides for this user the MAXMMAPAREA parameter in the BPXPRMxx member of parmlib. The value can be from 1 to 16,777,216. This field is not set when the record is inserted. If the field is not set, a RACROUTE EXTRACT will return a length of 4 and a value of X'FFFFFFFF'. UNIX System Services will take the system defaults set in BPXPRMxx when this field is not set. You can remove this field from the record by changing it to a null value (change user MMAPAREA()). MMAPAREA is only valid at OS/390 2.8 and above. While these fields are only honored by UNIX System Services at the OS/390 V2R8 level, eTrust CA-ACF2 lets you set these fields at any z/OS and OS/390 level. The following is an example of using these new fields:

SET PROFILE(USER) DIV(OMVS) CHANGE OMVSU2 CPUTIME(200) ASSIZE(10485760) FILEPROC(3) ­ PROCUSER(3) THREADS(10) MMAPAREA(1) OMVS / OMVSU2 LAST CHANGED BY TLC250 ON 05/17/99 ­ 13:38 ASSIZE(10,485,760) CPUTIME(200) FILEPROC(3) HOME(/u/omvsu2) MMAPAREA(1) PROCUSER(3) OMVSPGM(/bin/sh) THREADS(10) UID(199)

Normally, you cannot remove values from binary fields in eTrust CA-ACF2. However, the override fields in the user profile record have been designed to allow this. You can remove values by specifying a null value for the field. This results in eTrust CA-ACF2 ignoring the field, and causes UNIX System Services to pick up the default value specified in the BPXPRMxx member. The following example shows how to remove a value from a field.

SET PROFILE(USER) DIV(OMVS) CHANGE OMVSU2 CPUTIME() THREADS() ASSIZE() OMVS / OMVSU2 LAST CHANGED BY TLC250 ON 05/21/99 ­ 10:48 FILEPROC(3) HOME(/u/omvsu2) MMAPAREA(1) PROCUSER(3) OMVSPGM(/bin/sh) UID(199)

Implementing eTrust CA-ACF2 in a z/OS and OS/390 Environment

2­17

Creating an Administrator ID

GROUP Profile Records

USS groups are defined to eTrust CA-ACF2 as group profile records in the eTrust CA-ACF2 Infostorage database. Specifically, you define the group in the OMVS segment, which contains one field, the GID field. GID is a numeric field that accepts values from zero to 2,147,483,647. This value does not need to be unique, but we recommend that you make the GID unique; otherwise, control over a particular group is lost. Note: Do not include commas when entering numbers in eTrust CA-ACF2 profiles. This example shows how to define an OMVS group profile record for a group called OMVSGRP and assign it a GID of 20.

SET PROFILE(GROUP) DIV(OMVS) INSERT OMVSGRP GID(20)

After inserting or changing any group profile records, rebuild the group profile directory as documented in the Operator Commands for USS section later in this chapter. This directory must be rebuilt before the new or changed logonid attempts to access USS resources; otherwise, the change is not recognized and access is denied. Also, remember that eTrust CA-ACF2 requires that profile GROUP records be resident in storage. Before doing any rebuilds, ensure that the records are designated resident. Add them to the GSO INFODIR record with the R parameter as follows:

CHANGE INFODIR TYPES(R-PGRP)

Assigning Users to Groups under eTrust CA-ACF2 You assign a user's default group by setting the GROUP field in that user's eTrust CA-ACF2 logonid. The example below shows you how to assign logonid OMVSU2 to group OMVSGRP:

SET LID CHANGE OMVSU2 GROUP(OMVSGRP)

Note: Users can change their group by specifying GROUP(groupname) with their logonid and password when they log on to TSO. Resource rules control the users' access to groups not specified in their logonids.

2­18

z/OS and OS/390 Security Cookbook

Creating an Administrator ID

Displaying UID and GID Numbers

SHOW OMVS[ALL | GROUPS(mmmm[-nnnn]) | SUPERUSERS | USERS(mmmm[-nnnn]) The SHOW OMVS displays OpenEdition MVS users and/or groups.

ALL--displays all defined UIDs and GIDs along with their associated userids. GROUPS(mmmm[-nnnn])--displays a range of GID values along with their associated uersids. SUPERUSERS--displays all superusers (UID of ero(0)) along with their associated userids. USERS(mmmm[-nnnn])--displays a range of UID values along with their associated userids.

ALL is the default.

SHOW OMVS ALL ---------- OPENEDITION MVS DISPLAY ------------ OMVS USERS -UID ================ 0 0 0 7 101 8,888,888 NAME ======== BPXAS BPXOINIT BPXROOT GUEST3 TEST OMVSC

-- OMVS GROUPS -GID ================ 0 0 11 44,444 99,999,999 NAME ======== NULLGRP ZEROGRP LDAPGRP OMVSG OMVSDGRP

Defining a Default OMVS UID and GID

USS requires that users attempting to signon be defined with a valid UID and GID. If they do not have both of these, access is denied. If desired, a default OMVS userid and group can be defined allowing users without a UID or GID to access USS. The DFTUSER and DFTGROUP fields of the GSO UNIXOPTS record provide this capability. These defaults require that eTrust CA-ACF2 profile records be defined for them. In addition, USS issues a SAF EXTRACT call for the entity BPX.DEFAULT.USER. No rules are needed for this, but, in order for eTrust CA-ACF2 to satisfy this call, the default OMVS logonid must exist.

Implementing eTrust CA-ACF2 in a z/OS and OS/390 Environment

2­19

Controlling Superuser Functions

Following is an example of setting up defaults for OMVS:

SET LID INSERT OMVSUSER NAME(OMVS DEFAULT USERID) UID(99999999) HOME(/) OMVSPGM(/bin/sh) SET CONTROL(GSO) CHANGE UNIXOPTS DFTUSER(OMVSUSER) DFTGROUP(OMVSDGRP) SET PROFILE(GROUP) DIV(OMVS) INSERT OMVSDGRP GID(99999999)

Note: If the GSO PSWD record has the password required (PSWDREQ) set, the default logonid needs the RESTRICT bit set for it also. In cases where the default user is defined to grant access to facilities such as FTP, but where access to the rest of USS is not desired, you can define the program value for the UID profile as /bin/echo. This will allow the default to function for use with FTP, but disallow access to the OMVS shell (access is allowed to the ISHELL through TSO). It will also stop the OMVS command, telneting using OTELNET, RLOGIN connections, the OSHELL command, BPXBATCH using the sh parm and a command send to the shell via ISHELL using ISHELL's Run Shell command facility. When a user that does not have an OMVS USER PROFILE record attempts to access USS, eTrust CA-ACF2 uses the userid defined in the DFTUSER field of the UNIXOPTS record. If a user attempting to access USS does not have a value in his logonid GROUP field or the value in the GROUP field is not defined to USS, eTrust CA-ACF2 uses the group value defined in the DFTGROUP field of the UNIXOPTS record. The NO-OMVS logonid attribute lets a site specify that the logonid is not eligible to use OMVS. A logonid with the NO-OMVS attribute set is denied access at signon.

Controlling Superuser Functions

OMVS requires that users performing certain functions have a UID(0) or superuser status. Once a user is given superuser status, they have complete access to the system. The UNIXPRIV class allows specific control of the individual functions usually performed by a user with superuser authority. This is referred to as superuser granularity. The following table lists the new resources and what access or function is controlled by that resource: Note: See RACF Attribute Translation in the appendix "RACF to eTrust CAACF2 Translation," for more information about the access levels allowed for the resources.

2­20

z/OS and OS/390 Security Cookbook

Controlling Superuser Functions

Resource name SUPERUSER.FILESYS (READ access or higher) SUPERUSER.FILESYS (Update access or higher) SUPERUSER.FILESYS (Control access)

Access Given Allows a user to read any HFS file and read or search any HFS directory. Allows a user to write to any existing HFS file. Allows a user to write to any HFS directory. Allows a user with access to SUPERUSER.FILESYS to override an ACL that denies access

Affected Functions Open() for read, opendir(), readlink(), stat(), and realpath() Open() for write Link(), mkdir(), rename(), rmdir(), symlink(), unlink() ch_access()

SUPERUSER.FILESYS.ACLOVERRIDE

SUPERUSER.FILESYS.CHANGEPERMS Allows a user to change the access (READ access or higher) mode of any file. SUPERUSER.FILESYS.CHOWN SUPERUSER.FILESYS.MOUNT Allows a user to change ownership of any file. Allows a user to issue mount, unmount, quiesce, and unquiesce requests. Allows a user to call pfsctl(). Allows a user to issue vregister() to register as a vfs file server.

chmod() Chown() Mount(), unmount(), quiesce(), unquiesce() Pfsctl() Vregister()

SUPERUSER.FILESYS.PFSCTL SUPERUSER.FILESYS.VREGISTER SUPERUSER.IPC.RMID

Allows a user to do ipcrm calls to Ipcrm command use of clean up leftover IPC mechanisms. IPC_RMID for msgctl(), semctl(), shmctl() Allows a user to see all processes. Allows a user to send signals to any process. Allows a user to use dbx to trace any process. Allows a user to increase his priority. Getpsent() ­ ps command Kill() Dbx Setpriority(), nice()

SUPERUSER.PROCESS.GETPSENT SUPERUSER.PROCESS.KILL SUPERUSER.PROCESS.PTRACE SUPERUSER.SETPRIORITY

Using the UNIXPRIV class means that a user does not need superuser authority to perform an individual function from the above table. When a user attempts to perform the function without a UID(0) or superuser authority, eTrust CA-ACF2 issues a resource check to see if that user is allowed to perform the function. If the resource rule allows access to the resource associated with the function, the user is allowed to perform the function even though they do not have UID(0).

Implementing eTrust CA-ACF2 in a z/OS and OS/390 Environment

2­21

Operator Commands for USS

The following example shows a rule that allows USERA to read all HFS files, change the ownership of any file, and see all processes using the ps command:

SET RESOURCE(UNI) LIST SUPERUSER ACF75052 RESOURCE RULE SUPERUSER STORED BY USER01 ON 05/04/99 ­ 12:26 $KEY(SUPERUSER) TYPE(UNI) FILESYS UID(usera) SERVICE(READ) ALLOW FILESYS.CHOWN UID(usera) ALLOW PROCESS.GETPSENT UID(usera) ALLOW ACF75051 TOTAL RECORD LENGTH = 268 BYTES, 6 PERCENT UTILIZED

The UNIXPRIV class uses FASTAUTH calls so the type code used for the UNIXPRIV class must be added to the GSO INFODIR record and rules must be made resident:

SET CONTROL(GSO) CHANGE INFODIR TYPES(R-RUNI)

Once the INFODIR record has been updated, issue the following commands to activate the changes:

F ACF2,REFRESH(INFODIR) F ACF2,REBUILD(UNI),CLASS(R)

Operator Commands for USS

Rebuilding Directories

Any time you create, change, or delete a user or group profile record, you must rebuild the directories for the profile records so that the changed are recognized. Also, remember that the profile records must be designated resident in the INFODIR record before you rebuild the user or group profile directory. To rebuild the directory for user profile records, issue this command:

F ACF2,REBUILD(USR),CLASS(P)

To rebuild the directory for group profile records, issue this command:

F ACF2,REBUILD(GRP),CLASS(P)

During initialization eTrust CA-ACF2 also builds cross-reference tables to associate UIDs with their eTrust CA-ACF2 logonids and GIDs with the eTrust CA-ACF2 group name. If you add, change, or delete entries in user or group profile records, these tables must be rebuilt so that the associations are accurate and current. Issue this operator command to rebuild these tables after you have rebuilt the directories:

F ACF2,OMVS

2­22

z/OS and OS/390 Security Cookbook

Operator Commands for USS

Tracing USS SAF Requests

The SECTRACE facility, used to trace SAF requests in the eTrust CA-ACF2 environment, is also available to trace SAF requests made by OMVS. For complete details on the SECTRACE syntax see the Special Usage Considerations chapter in the System Programmers Guide. To start SECTRACE for OMVS, issue the following command:

ST SET,TYPE=OMVS,ID=aaaa,FUNC=xxxx,end

Note: FUNC= is a required parameter. ID names the SECTRACE trap and can be from one to eight characters. FUNC can be one of seven values. Each of the functions traces a set of related OMVS services. The seven functions and the services that they trace are: ALL--Traces all OMVS services. CHANGE--Traces R_chown, R_chaudit, and R_chmod. CHECK--Traces ck_access, ck_priv, ck_process_owner, ck_file_owner, R_ptrace, ck_IPC_access, ck_owner_two_files, R_IPC_ctl, and R_dceauth. GET--Traces getUMAP, getGMAP, R_getgroups, R_getgroupsbyname, get_uid_gid_supgrps, R_dceinfo, R_dcekey, R_dceruid, and R_usermap. INIT--Traces initACEE, initUSP, deleteUSP, and R_fork. MAKE--Traces makeFSP, makeISP, and make_root_FSP. MISC--Traces audit, query_file_security_options, and query_system_security_options. SET--Traces R_umask, R_setegid, R_seteuid, R_setgid, R_setuid, R_exec, clear_setid, and R_admin. The OMVS SECTRACE will accept other parameters on the ST SET statement, but will ignore them. Output from the OMVS SECTRACE can only be routed to the console. The OMVS services are documented in the IBM OS/390 Security Services Callable Services guide. You should only use the OMVS SECTRACE when instructed to by eTrust CA-ACF2 Technical Support due to the large volume of trace entries possible in the OMVS environment. It is usually easier to debug an OMVS problem using the ACFRPTOM report, because it shows more information than the trace. All of the OMVS services write SMF records when the service returns with a non-zero return code. The services can be easily found using the ERROR parameter of the ACFRPTOM report.

Implementing eTrust CA-ACF2 in a z/OS and OS/390 Environment

2­23

GSO UNIXOPTS Record

To stop the SECTRACE for OMVS, issue the following command, where xxxx is the identifier assigned to the SECTRACE:

ST DEL,ID=xxxx,end

GSO UNIXOPTS Record

The UNIXOPTS record defines the system options related to UNIX System Services. Record ID UNIXOPTS Fields CHOWNRES|NOCHOWNRES DFTGROUP(defaultgroup) DFTUSER(defaultuser) DIRACC|NODIRACC DIRSRCH|NODIRSRCH FSOBJ|NOFSOBJ FSSEC|NOFSSEC IPCOBJ|NOIPCOBJ HFSACL|NOHFSACL HFSSEC|NOHFSSEC NGROUPS(NGROUP_MAX) PROCACT|NOPROCACT PROCESS|NOPROCESS

Field Descriptions

CHOWNRES|NOCHOWNRES--CHOWNRES implements POSIX CHOWN RESTRICTED which states that only the super user can modify the owner (UID) of a file. NOCHOWNRES implements POSIX CHOWN UNRESTRICTED which allows the current owner to modify the owning UID of file. DFTGROUP(defaultgroup)--Specifies the name of the default group used by UNIX System Services (OMVS) if a user does not have a valid OMVS group in the logonid record. DFTUSER(defaultuser)--Specifies the name of the logonid and OMVS user profile record name that defines the defaults for UNIX System Services (OMVS). If a user accesses OMVS services and does not have an OMVS user profile record, the defaults defined in this ID are used. If a user has NO-OMVS defines in his logonid, the user cannot use OMVS services and the default is not used. This is equivalent to specifying NOUID in RACF.

2­24

z/OS and OS/390 Security Cookbook

GSO UNIXOPTS Record

DIRACC|NODIRACC--Specifies if SMF records are to be cut for UNIX system services that control directory searches. Some of the functions that search directories are chmod, chown, chaudit, getcwd, link, mkdir, open, opendir, stat, ttyname and vlink. The Security Server callable service that controls cutting this SMF record is ck_access. Be aware that auditing directory searches will generate an extremely large amount of SMF records in a short period of time. FSOBJ|NOFSOBJ--Specifies if SMF records are to be cut for UNIX system services that control the auditing of the creation and deletion of system objects. It also cuts SMF records for all access check except directory searches. Some of the functions that will do this are chdir, link, mkdir, open, mount, rename, rmdir, symlink, vmakedir, and vcreate. The Security Server callable services that control cutting of this SMF record are ck_access, ck_owner_2_files, makeFSP, make_root_FSP, makeISP, and R_audit. FSSEC|NOFSSEC--Specifies if SMF records are to be cut for UNIX system services that control the auditing of changes to the security data (FSP) for file system objects. Some of the functions that modify the FSP are chaudit, chmod, chown, chattr, write, fachaudit, and fchmod. The Security Server callable services that control cutting of this SMF record are R_chaudit, R_chown, R_chmod, and clear_setid. HFSACL|NOHFSACL--When HFSACL is specified, Access Control Lists are used in the z/OS UNIX security access validation process in addition to the checking of file permission bits and superuser status. When NOHFSACL is specified, normal z/OS or OS/390 UNIX security access validation is done, including the checking of file permission bits and superuser status. Access Control Lists (ACL's) are supported in z/OS release 1.3 and above. If HFSSEC is also specified, ACL's are not used regardless of the setting of this field. See "Controlling Access to the Hierarchical File System" for more information about Access Control Lists. HFSSEC|NOHFSSEC--When HFSSEC is specified, CA SAF HFS security is activated. Normal z/OS and OS/390 UNIX security access validation is bypassed. This includes checking of file permission bits, superuser status and normal z/OS and OS/390 UNIX Security Services. When NOHFSSEC is specified, CA SAF HFS security is not active. Normal z/OS and OS/390 UNIX sercurity access validation is enabled. This includes checking of file permission bits, superuser status and normal z/OS and OS/390 UNIX Security Services. NOHFSSEC is the default. See Controlling Access to the Hierarchical File System for more information on CA SAF HFS security. CA SAF HFS security can also be controlled using the F ACF2,HFS (STATUS| ENABLE|DISABLE) command. See the Systems Programmer's Guide for more information.

Implementing eTrust CA-ACF2 in a z/OS and OS/390 Environment

2­25

GSO UNIXOPTS Record

IPCOBJ|NOIPCOBJ--Specifies if SMF records are to be cut for UNIX system services that control the auditing of the access control, IPC object changes and the creation and deletion of IPC objects. Some of the functions that will do this are msgctl, msggest, msgsnd, semctl, semget, semop, shmat, shmget and shmctl. The Security Server callable services that control cutting of this SMF record are ck_IPC_access, R_PIC_ctl, and makeISP. NGROUPS(NGROUPS_MAX)--The maximum size of the supplemental group list created for each signon. Supplemental groups are currently used with UNIX System Services support. The value for NGROUPS is a number in the range of 0 to 8192. The default is 300. PROCACT|NOPROCACT--Specifies if SMF records are to be cut for UNIX system services that control the auditing of services that look at data from or effect other processes. Some of the functions that affect other processes are getpsent, kill, ptrace, recv, recvmsg and sendmsg. The Security Server callable services that control cutting of this SMF record are ck_process_owner and R_ptrace. PROCESS|NOPROCESS--Specifies if SMF records are to be cut for UNIX system services that control the dubbing and undubbing of processes, changes to the UIDs and GIDs of processes, and changes to the thread limits and other privileged options. Some of the functions that dub processes or change process values are exec, setuid, setgid, seteuid, setegid, dub, undub, and vregister. The Security Server callable services that control cutting of this SMF record are R_exec, R_setuid, R_setgid, R_seteuid, R_setegid, ck_priv, initUSP, initACEE, and deleteUSP.

Displaying the UNIXOPTS Record

SHOW UNIXOPTS--Displays UNIX options on the system.

show unixopts -- UNIXOPT OPENEDITION/MVS/UNIX/SYSTEM SERVICES (USS) SUMMARY -OMVS DEFAULT USER: OMVSDFLT OMVS DEFAULT GROUP: OMVSUSRG MAX NUMBER OF OMVS GROUPS: 300 HFS SECURITY ACTIVE: YES HFSACL ACTIVE: YES -- AUDIT FLAG STATUS -CHOWN _RESTRICTED: NO DIRACC_ACTIVE: NO DIRSRCH_ACTIVE: NO FSOBJ_ACTIVE: NO FSSEC_ACTIVE: NO IPCOBJ_ACTIVE: NO PROCACT_ACTIVE: NO PROCESS_ACTIVE: NO

2­26

z/OS and OS/390 Security Cookbook

Chapter

3

Implementing USS Applications in an eTrust CA-ACF2 Environment

This chapter presents information regarding the implementation of various applications that run under USS. The details show what is necessary to set up these applications up in an eTrust CA-ACF2 protected environment. Additional information regarding the administrative commands used in this chapter can also be found in the Administrator Guide. The required set up usually follows three basic steps: 1. 2. 3. Define the required logonids and associated profile information. Define any required group profiles. Allow access to any of the protected resources used by the application.

Any additional information or set up requirements are noted in the respective section following the basic set up steps. Each section below covers a separate application.

TCP/IP

TCP/IP (Transmission Control Protocol/Internet Protocol) is a telecommunications protocol commonly used for communicating among distributed systems. TCP/IP allows computers to talk to each other and is well established on the UNIX and PC platforms.

Implementing USS Applications in an eTrust CA-ACF2 Environment

3­1

TCP/IP

Communications Server IP for z/OS and OS/390 (TCP/IP)

If you are running Communications Server IP for OS/390 or z/OS, appropriate OMVS authorities are required for the logonids under which the TCP/IP servers run. Create the TCP/IP logonid and the needed OMVS credentials by entering the following commands:

SET LID INSERT TCPIP NAME(TCP/IP STC LOGONID) STC MUSASS GROUP(OMVSGRP) UID(0) HOME(/) SET PROFILE(GROUP) DIV(OMVS) INSERT OMVSGRP GID(nn)

Note: Reports have come in indicating that use of the lpr command has required that the user have superuser authority. This has been traced to the RESTRICTLOWPORTS setting in TCP/IP being set to YES. This forces the lpr command to use a port below 1024, requiring superuser authority. Set this option to NO to remove the superuser requirement.

TCP/IP SERVAUTH Class

With OS/390V2R10, TCP/IP uses the SERVAUTH class to protect various TCP/IP resources from unauthorized access. There are four functions protected under the SERVAUTH class: Stack Access--Controls which users can access TCP/IP stack using a constructed resource name similar to EZB.STACKACCESS.sysname.tcpipid. Net Access--Controls which users can access individual networks using a constructed resource name similar to EZB.NETACCESS.sysname.tcpipid.netname. Port Access--Controls which users can use TCP and UPD ports using a constructed resource name similar to EZB.PORTACCESS.sysname.tcpipid.portname. Netstat Access--Controls access to Netstat command output from TSO and USS shell environments using a constructed resource name similar to EZB.NETSTAT.sysname.tcpname.netstatoption. TN3270--Controls which users can use secured ports using a constructed resource name similar to EZB.TN3270.sysname.tcpipid.PORTnnnn. where sysname is the name of the system:

tcpipid is the name of the TCPI/IP started task. netname is the network named defined in the PROFILE.TCPIP file. portname is the port name defined in the PPOFILE.TCPIP file nnnn is the port number with leading zeros.

3­2

z/OS and OS/390 Security Cookbook

TCP/IP

STACK ACCESS resources are validated automatically while the other three resource types require activation via settings in the PROFILE.TCPIP file. See the OS/390 V2R10 IP Configuration Guide for additional information. Users attempting to use TCP/IP via a protected access request that they have read access to the specific resource being validated. To allow access to any or all of these resources, create and store a resource rule with the appropriate rule entries. For example, the following rule would allow USERA access to all the SERVAUTH class resources:

SET RESOURCE(SER) COMPILE* $KEY(EZB) TYPE(SER) NETACCESS.- UID(user_uid) SERVICE(READ) ALLOW STACKACCESS.- UID(user_uid) SERVICE(READ) ALLOW PORTACCESS.- UID(user_uid) SERVICE(READ) ALLOW TN3270.- UID(user_uid) SERVICE(READ) ALLOW NETSTAT.- UID(user)uid) SERVICE(READ) ALLOW STORE

The type code selected is based on the value set up for the default CLASMAP for SERVAUTH. You can change the type code by creating your own local CLASMAP records using the following commands:

SET CONTROL(GSO) INSERT CLASMAP.SERVAUTH RESOURCE(SERVAUTH) RSRCTYPE(type_code) ENTITYLN(64)

The SERVAUTH resource rules must be resident. You set this up be defining the type code as resident in the INFODIR GSO record. The following commands are an example of doing this using the SER default type code:

SET CONTROL(GSO) CHANGE INFODIR TYPES(R-RSER)

To activate these changes immediately, enter the following commands:

F ACF2, REFRESH(ALL) F ACF2, REBUILD(SER)

Securing IP Addresses

Securing an IP address using eTrust CA-ACF2 (or any external security product) requires that the installed TCP/IP product pass the IP address packet. However, not all TCP/IP vendor products pass this information. IBM's TCP/IP product does pass the IP address. IP address protection is not available if your TCP/IP product does not pass the IP address packet.

Implementing USS Applications in an eTrust CA-ACF2 Environment

3­3

z/OS and OS/390 FTP

The IP packet passed is generated from the user's originating IP address. Thus, these IP packets often have no resemblance to standard LU names. Each node of the IP address is translated into a character representation of the hex value of the node. For example, the IP address 141.202.201.56 would appear as terminal 8DCAC938. The hex value of 141 is 8D, the hex value of 202 is CA, and so forth. eTrust CA-ACF2 provides two mechanisms to implement security of an IP address. The standard IP address is converted to hex pairs. If you want to restrict a particular user to enter the system only through a specific IP address, use source restriction on their logonid. For example:

SET LID CHANGE usera SOURCE(8DCAC938) equivalent to 141.202.201.56

If you want to allow more than one IP address or an IP address range, use a source group restriction. Add each allowable source or use masking. For example, to allow the use of all IP addresses starting with 141.202 and 141.201.201.55, enter:

SET XREF(SGP) INSERT IPGROUP INCLUDE(8DCA**** 8DC9C937) SET LID CHANGE usera SOURCE(IPGROUP)

To activate changes to the XREF records immediately, issue:

F ACF2,NEWXREF,TYPE(SGP)

z/OS and OS/390 FTP

Packaged with TCP/IP OE Application Services, FTP is an OMVS application that executes under USS to facilitate the file transfer of OMVS HFS files, as well as MVS data sets, throughout a TCP/IP network. FTP under USS typically executes under a started task named FTPD. To complement FTP, TCP/IP OE Application Services includes an optional message-log daemon (called SYSLOG-D) that can be used to log past and present message traffic related to FTP. This optional logging task should be considered since, without it, there is no ongoing log of FTP activity.

3­4

z/OS and OS/390 Security Cookbook

z/OS and OS/390 FTP

Installing FTP with eTrust CA-ACF2

Per IBM documentation, the installation of FTP has considerations for the mainframe security administrator. The following information describes the deviations from and adjustments to IBM documentation when installing FTP with eTrust CA-ACF2 : 1. Create a logonid for the FTP started task typically named FTPD. The FTPD logonid must be assigned superuser status, UID(0).

SET LID INSERT FTPD NAME(OE/FTP STCID) STC GROUP(OMVSGRP) UID(0) HOME(/) OMVSPGM(/bin/sh)

2.

Give the FTPD logonid access to the required BPX FACILITY class resources. The FTPD logonid needs access to the BPX.DAEMON resource. To accomplish this, add the following rule line to the existing BPX FACILITY resource rule:

DAEMON UID(ftpd) SERVICE(READ) ALLOW

ANONYMOUS Logon Feature

Users accessing FTP must log on to the service before using it. This requires them to supply their userids and passwords, and for their userids to have access to TCP/IP. FTP supports anonymous logons if the ANONYMOUS parameter is set in the FTPDATA configuration file in one of the following ways:

ANONYMOUS ANONYMOUS userid ANONYMOUS userid/password

If the ANONYMOUS parameter is specified without a userid and an FTP user specifies anonymous at logon time, a SAF VERIFY is issued for the logonid ANONYMOU. If this logonid is defined to eTrust CA-ACF2, the user is allowed to log on and run under the authority of the ANONYMOU logonid. If the ANONYMOUS parameter is specified with a userid, the user is prompted for a password and must provide the correct password for this userid. If the ANONYMOUS parameter is specified with both userid and password, both values are used to sign on. The use of ANONYMOUS logon should be carefully considered. It can be a candidate for auditing.

Implementing USS Applications in an eTrust CA-ACF2 Environment

3­5

TELNET

TELNET

TELNET is a feature of TCP/IP that allows users terminal access to a system over a TCP/IP network. TELNET runs under both native MVS and USS. If running under native MVS, users can be forced to log on to TELNET itself. This will occur if the TELNET configuration statements in the TCP/IP profile data set do not specify a DFLTAPPL. Alternatively, DFLTAPPL can be specified, which directs all logons to a session manager such as CA-TPX. The session manager then controls access through its security interface.

Securing TELNET for USS

When using TELNET under OMVS, RLOGIN runs under its own logonid until the user successfully signs on. The name of this logonid is specified in the configuration file /etc/inetd.conf. It is delivered with a default ID of OMVSKERN. Consider changing this default to one that conforms to installation standards and is not common knowledge. This userid must be defined with both superuser and daemon authority. The following commands define such a logonid:

SET LID INSERT omvskern NAME(TELNET OMVS ID) STC GROUP(OMVSGRP) UID(0) HOME(/) OMVSPGM(/bin/sh)

If you have not already defined the OMVSGRP group to OMVS, issue the following commands using an available group number:

SET PROFILE(GROUP) DIV(OMVS) INSERT OMVSGRP GID(nn)

If you are using OMVSKERN, it is likely that this logonid was defined as part of your OMVS installation. In addition, if you are securing daemon authority, the TELNET server logonid must have access to the FACILITY class resource BPX.DAEMON resource. Add the following rule entry to the BPX FACILITY resource rule:

DAEMON UID(omvskern) SERVICE(READ) ALLOW

3­6

z/OS and OS/390 Security Cookbook

z/OS and OS/390 Infoprint Server

z/OS and OS/390 Infoprint Server

The z/OS and OS/390 Infoprint Server allows for consolidation of print files from multiple servers to one central server. Control of the resources defined under the Print Server requires the definition of two groups: AOPOPER and AOPADMIN. These are the IBM defaults. AOPOPER is the operator group with authority to start and stop the print interface. AOPADMIN provides authority to administer the printer inventory and controls. If the separation of authority is not necessary, then one group name can be defined for both functions. Use the following steps to define the security environment for eTrust CA-ACF2: 1. Define logonids for the started tasks used by the Infoprint server using the following commands:

SET LID INSERT AOPSTART NAME(AOPSART PROC) STC INSERT AOPSTOP NAME(AOPSTOP PROC) STC

2.

Define group profile records using the following example:

SET PROFILE(GROUP) DIV(OMVS) INSERT AOPOPER GID(nn) INSERT AOPADMIN GID(nn)

Replace nn with an appropriate GID number. 3. The Infoprint Server limits access to the printer configuration using the FACILITY class. To let users access this resource to perform administrative functions, create the following resource rule under the FACILITY type:

$KEY(AOPADMIN) TYPE(FAC) UID(uid) ALLOW

4.

To let users access the groups through the supplemental group facility, write TGR resource rules that grant access to the specified groups as appropriate.

$KEY(AOPOPER) TYPE(TGR) UID(uid) ALLOW $KEY(AOPADMIN) TYPE(TGR) UID(uid) ALLOW)

5.

If the FAC type or TGR type rules are maintained in a directory, be sure to issue the rebuild command after compiling and storing the rules:

F ACF2,REBUILD(FAC),CLASS(R) F ACF2,REBUILD(TGR),CLASS(R)

6.

To correctly perform security checking in the PostScript and PDF to AFP transform requires an ownership change to its executable ps2afpd. As installed, ps2afpd has an owner with a UID of 0. Ownership of this file must be changed to a UID that is not a superuser. The z/OS and OS/390 Infoprint Server Customization Guide details the steps necessary to accomplish this.

Implementing USS Applications in an eTrust CA-ACF2 Environment

3­7

DOMINO for z/OS and OS/390 (Lotus Notes) Server

You can use an existing UID and GID or create one specifically for this purpose using the following commands:

SET LID INSERT lid_name NAME(PS2AFPD owner) GROUP(group_name) UID(nn) SET PROFILE(GROUP) DIV(OMVS) INSERT group_name GID(nn) END

Replace nn in the UID and GID operands with an appropriate UID and GID values. To immediately activate these changes, issue the following commands:

F ACF2,REBUILD(USR),CLASS(P) F ACF2,REBUILD(GRP),CLASS(P) F ACF2,OMVS

DOMINO for z/OS and OS/390 (Lotus Notes) Server

DOMINO for z/OS and OS/390, revered to as The Lotus Notes (Email), runs in a z/OS and OS/390 environment. While DOMINO has its own internal security, which does not interface with external security, there are a number of tasks that must be done to define DOMINO to external security. 1. Define a logonid for the DOMINO with a valid USS UID and GID. The USS UID should not be UID(O) as suggested in the DOMINO documentation. The following example shows sample commands to accomplish this:

ACF SET LID INSERT domino NAME(DOMINO server) STC GROUP(notes) UID(nn) OMVSPGM(/bin/sh) HOME(/u/domino) SET PROFILE(GROUP) DIV(OMVS) INSERT notes GID(nn)

Note: The values used are based on the sample defaults in the DOMINO documentation. Be sure to use the appropriate values for your installation. 2. The DOMINO server might need access to various FACILITY resources. If the DOMINO server is going to create SMF records, it needs READ access to the resource of BPX.SMF. If you are going to make the DOMINO server non-swappable, DOMINO needs READ access to the BFX.STOR.SWAP resources. If the server is going to spawn jobs with a name not matching its id, then it needs READ access to the resource BPX.JOBNAME. Add the following rule entries as appropriate to the BPX FACILITY resource rule:

SMF UID(domino) SERVICE(READ) ALLOW STOR.SWAP UID(domino) SERVICE(READ) ALLOW JOBNAME UID(domino) SERVICE(READ) ALLOW

3­8

z/OS and OS/390 Security Cookbook

DOMINO for z/OS and OS/390 (Lotus Notes) Server

z/OS and OS/390 Console for Domino

DOMINO for z/OS and OS/390 provides a facility (DOMINO console interface) for sending commands from z/OS and OS/390 to start, stop, and manage a DOMINO server running under UNIX System Services. The code provided to implement this support is named DOMCON. To define the environment to eTrust CA-ACF2 , do the following: 1. Create a logonid and profile record for DOMINO console user:

SET LID INSERT DOMCNSL NAME(COMINO console user) GROUP(NOTES) UID(O) OMVSPGM(/bin/sh) HOME(/u/domcnsl)

2.

The DOMINO console logonid needs access to the FACILITY class resources of BPX. DAEMON and BPX.JOBNAME. Add the following rule entries to the BFX FACILITY rule:

DAEMON UID(domcnsl_uid) SERVICE(READ) ALLOW JOBNAME UID(domcnsl_uid) SERVICE(READ) ALLOW

3.

Users that are authorized to enter domoe commands will need update access to the FACILITY class resource BPX.SERVER. Add the following rule entry as necessary for the users to the BFX FACILITY rule:

SERVER UID(domoe_cmd_user_uid) SERVICE(READ,UPDATE) ALLOW

4.

These same users also need access to the SURROGAT class resources for each server. The default server name of DOMINO would result in a SURROGAT resource name of BPX.SRV.DOMINO. This would be accomplished using commands similar to the following:

SET RESOURCE(SUR) COMPILE $KEY(BPX) TYPE(SUR) SRV.DOMINO UID(domino_cmd_user_uid) SERVICE(READ) ALLOW STORE

Note: If the BPX SURROGAT rule already exists at your site, simply add the appropriate rule entry to it. 5. If the SURROGAT or FAICLITY rules were made resident via the GSO INFODIR record, issue the following commands to activate the changes:

F ACF2,REBUILD(SUR) F ACF2,REBUILD(FAC)

z/OS and OS/ 390 Console for Domino 5.0.6 and Higher

With DOMINO for OS/390 servers release 5.0.6 and higher the set up process has changed. The command process has split into multiple procedures as follows:

DOMINC ­ Issues command to the Domino servers. DOMINK ­ Stops the Domino servers.

Implementing USS Applications in an eTrust CA-ACF2 Environment

3­9

DOMINO for z/OS and OS/390 (Lotus Notes) Server

DOMINM ­ Enables and disables the monitor. DOMINS ­ Starts the Domino servers.

To define this environment to eTrust CA-ACF2 , do the following: 1. Create logonid and profile records for DOMINO procedures:

SET LID INSERT DOMINC NAME(DOMINC procedure) GROUP(NOTES) UID(O) OMVSPGM(/bin/sh) HOME(/u/domcnsl) INSERT DOMINK NAME(DOMINK procedure) GROUP(NOTES) UID(O) OMVSPGM(/bin/sh) HOME(/u/domcnsl) INSERT DOMINM NAME(DOMINM procedure) GROUP(NOTES) UID(O) OMVSPGM(/bin/sh) HOME(/u/domcnsl) INSERT DOMINS NAME(DOMINS procedure) GROUP(NOTES) UID(O) OMVSPGM(/bin/sh) HOME(/u/domcnsl)

2.

The DOMINO console logonids need access to the FACILITY class resource of BPX. DAEMON. Add the following rule entry to the BFX FACILITY resource rule for each procedure:

DAEMON UID(procedure_uid) SERVICE(READ) ALLOW

3.

The logonid used for running the install script for the console support must be UID 0 and have read access to the facility class resources BPX.FILEATTR.PROGCTL and BPX.FILEATTR.APF. This is required to set the extended attributes for console support to APF authorized and program controlled. Add the following rule entry to the BFX FACILITY resource rule:

FILEATTR.PROGCTL UID(installing_lid's_uid) SERVICE(READ) ALLOW FILEATTR.APF UID(installing_lid's_uid) SERVICE(READ) ALLOW

4.

Users that are authorized to enter domoe commands will need update access to the FACILITY class resource BPX.SERVER. Add the following rule entry as necessary for the users to the BFX FACILITY rule:

SERVER UID(domoe_cmd_user_uid) SERVICE(READ,UPDATE) ALLOW

5.

These same users also need access to the SURROGAT class resources for each server that a command is sent to. The default server name of DOMINO would result in a SURROGAT resource name of BPX.SRV.DOMINO. This would be accomplished using commands similar to the following:

SET RESOURCE(SUR) COMPILE $KEY(BPX) TYPE(SUR) SRV.DOMINO UID(domino_cmd_user_uid) SERVICE(READ) ALLOW STORE

Note: If the BPX SURROGAT rule already exists at your site, simply add the appropriate rule entry to it.

3­10

z/OS and OS/390 Security Cookbook

z/OS and OS/390 Component Broker Series (SOMobjects) Support

6.

A server that is started with the OS/390 console support use the _BPX_JOBNAME environment variable to assign an unique job name for itself and each task associated with the server. To authorize this, the server logonid must be permitted to the facility class resource BPX.JOBNAME. Add the following rule entry to the BFX FACILITY resource rule for each server logonid:

JOBNAME UID(server_lid_uid) SERVICE(READ) ALLOW

7.

If the SURROGAT or FAICLITY rules were made resident via the GSO INFODIR record, issue the following commands to activate the changes:

F ACF2,REBUILD(SUR) F ACF2,REBUILD(FAC)

Defining Lotus Notes Users

Each user of the Lotus Notes Server must be defined to eTrust CA-ACF2 using an lnotes profile record. This profile record connects the user's logonid with the user definition name used within Lotus Notes. To create lnotes profile records for Lotus Notes users, use the following commands:

SET PROFILE(USER) DIV(LNOTES) INSERT logonid SNAME(lotus_notes_user_name)

After creating the lnotes profile record, refresh the user profile records as described in Operator Commands for USS, Rebuilding Directories, earlier in this chapter.

z/OS and OS/390 Component Broker Series (SOMobjects) Support

eTrust CA-ACF2 supports all functionality for the changes in SAF calls to handle OS/390 Component Broker Series (SOMobjects). The changes include parameters in the RACROUTE EXTRACT calls as well as modifications to the InitACEE callable service. There is also a security server provided that protects the resources used in SOMobjects. These resources include access to a particular SOM server, access to SOM objects, and access to SOM object methods. The security process uses three classes (CBIND, SERVER, and SOMDOBJ) to validate access to the resources used with SOMobjects. These three classes have been predefined to eTrust CA-ACF2 with an assigned resource type code of SAF.

Implementing USS Applications in an eTrust CA-ACF2 Environment

3­11

z/OS and OS/390 Component Broker Series (SOMobjects) Support

To set up SOMobjects with eTrust CA-ACF2, perform the following steps: 1. 2. Ensure that you are running with STC set in the GSO OPTS record. Create the logonids and profiles for the started tasks needed by SOMobjects, including the SOM server, the naming and security server, any object server, and any application servers. The following example command shows how to create started task logonids:

SET LID INSERT SOM NAME(SOM started task) GROUP(somgroup) STC UID(nn) HOME(home-path-name) OMVSPGM(/bin/sh INSERT server NAME(SOM server) GROUP(somgroup) STC UID(nn) HOME(home-path-name) OMVSPGM(/bin/sh INSERT appserver NAME(Application server) GROUP(somgroup) STC UID(nn) HOME(home-path-name) OMVSPGM(/bin/sh

Where server is the name for the naming, security, or object server, and appserver is the name of the application server. Do the same for any other logonids and assign a unique UID number to each user. 3. Allow the started task logonids created in step one access to the SOMMVS data sets.

SET RULE COMPILE * $KEY(SOMMVS)

4.

Define group profiles used for the SOM subsystem, the associated object servers, and SOM object clients to USS by creating the required user and group profile records:

SET PROFILE(GROUP) DIV(OMVS) INSERT somgroup GID(nn)

Assign a unique GID number to each group. 5. When a SOMobjects server is started, SOMobjects determines whether that server is allowed to communicate with the SOM subsystem. The resource used in the validation is SOM.subsystem-name.server-alias-name under the SERVER class. Allow the SOMobjects server subsystem access with the following rule:

SET RESOURCE(SAF) COMPILE * $KEY(SOM) TYPE(SAF) subsytem-name.server-alias-name UID(somobject server) SERVICE(READ) ALLOW

7.

Servers will run in a secure mode if this is activated using the REGIMPL utility. For information on the REGIMPL utility, see IBM OS/390 SOMobjects Configuration and Administration. If a SOMobjects client attempts to access a secured server, various levels of validation are performed. The first check determines whether the client is allowed access to the server. A resource check is made against the SOM.subsytem-name.server-alias-name in the CBIND class.

3­12

z/OS and OS/390 Security Cookbook

z/OS and OS/390 Security Server

The following rule allows this access:

SET RESOURCE(SAF) COMPILE * $KEY(SOM) TYPE(SAF) subsytem-name.server-alias-name UID(client) SERVICE(READ) ALLOW

If SAF validation is active for the APPL class, the following rule is also required:

SET RESOURCE(SAF) COMPILE * $KEY(SOM) TYPE(SAF) UID(client) ALLOW

When a client accesses a SOMobject method, a validation is performed against the SOMDOBJ class with a resource name of classname.methodname. The following rule is required to allow access to the SOMDOBJ resource:

SET RESOURCE(SAF) COMPILE * $KEY(classname) TYPE(SAF) methodname UID(client) ALLOW

If the classname is larger than 40 characters, write the rule as follows:

$KEY(classname) TYPE(SAF) `remainder-classname.methodname' UID(client) ALLOW

Where the classname in the $KEY is the first 40 character of the classname. The remainder of the classname is on the rule line. If desired, you can change the type code assigned to the various SAF resource classes by defining a CLASMAP record for each class. For example:

SET CONTROL(GSO) INSERT CLASMAP.CBIND RESOURCE(CBIND)RSRCTYPE(CBD) ENTITYLN(50) INSERT CLASMAP.SERVER RESOURCE(SERVER) RSRCTYPE(SRV) ENTITYLN(50) INSERT CLASMAP.SOMDOBJ RESOURCE(SOMDOBJ) RSRCTYPE(SOM)- ENTITYLN(246)

z/OS and OS/390 Security Server

As a separate offering, along with z/OS and OS/390, IBM provides the Security Server. This offering is a bundling of RACF with a number of other products. All of these products perform some security function. Those that interface with RACF do so through standard security calls supported by eTrust CA-ACF2. None are truly dependent on RACF to function.

RACF

Although delivered as part of the security server, RACF must be independently activated and is not required to run the other Security Server components. RACF is IBM's SAF compliant security system. eTrust CA-ACF2 is fully SAF compliant and will process all appropriate SAF calls so the RACF component of the Security Server is not needed in an eTrust CA-ACF2 environment.

Implementing USS Applications in an eTrust CA-ACF2 Environment

3­13

DCE Security Server

Disabling RACF The level of security that you run with depends on your site's specific needs. In an eTrust CA-ACF2 environment, the RACF component must be disabled. To do this in RACF, update the appropriate IFAPRDxx member and change the STATE field as to:

STATE(DISABLED)

Then re-IPL the system to make the change take effect. For example, if you want to disable the RACF component of the security server but continue to use the DCE component of the security server, update the IFAPRDxx entries to look like this:

PRODUCT OWNER('IBM CORP') NAME('OS/390') FEATURENAME('Security Server') ID(5647-A01) VERSION(*) RELEASE(*) MOD(*) STATE(ENABLED) PRODUCT OWNER('IBM CORP') NAME('OS/390') FEATURENAME('RACF') ID(5647-A01) VERSION(*) RELEASE(*) MOD(*) STATE(DISABLED)

Or, if you want to disable the security server completely and run without security, update the IFAPRDxx entry to look like this:

PRODUCT OWNER('IBM CORP') NAME('OS/390') FEATURENAME('Security Server') ID(5647-A01) VERSION(*) RELEASE(*) MOD(*) STATE(DISABLED)

DCE Security Server

The DCE Security Server is a separate security product that provides authentication services for users and servers running DCE applications. It provides an independent or third-party platform in which to validate and authenticate security requests.

3­14

z/OS and OS/390 Security Cookbook

DCE Security Server

In a DCE environment, one DCE Security Server must exist. It provides a central hub for system entry validation and single-sign on authentication for all DCE platforms within a connected DCE environment. When a user passes from one DCE platform to another, the target platform passes information about the user credentials, along with other information, to the DCE Security Server for authentication and authorization. The DCE Security Server authenticates such requests by checking the supplied user credentials against those stored in the DCE Security Server's security repository or security registry. When performing this authentication, the DCE Security Server follows an authentication algorithm, which involves not only the user credentials but also encryption keys known for each platform. The algorithm is standards-based and is platform-independent. As a result, multiple vendors and platforms offer a DCE Security Server. The z/OS and OS/390 DCE Security Server performs its authentication following DCE conventions, not the conventions of RACF or any other mainframe external security manager (ESM). With z/OS and OS/390 DCE Security Server, the ESM is used mainly as a repository for information needed to support the DCE authentication process. In particular, the ESM is used to hold DCE-specific userid information and encryption keys. A DCE segment can be defined for any userid. The DCE userid segment allows six DCE-specific fields to be maintained for any userid. For example, one field named DCEKEY identifies each user's DCE password. During authentication, the DCE Security Server retrieves this and other information from the ESM using standard SAF interfaces. This information is then used separately to authenticate and authorize the DCE Security Server request.

eTrust CA-ACF2 Support for the DCE Security Server

eTrust CA-ACF2 defines a MVS user to OpenEdition DCE through DCE profile records. Record ID recid Fields UUID(uuid) DCENAME(dcename) HOMEUUID(homeuuid) HOMECELL(homecell) AUTOLOG|NOAUTOLOG

Implementing USS Applications in an eTrust CA-ACF2 Environment

3­15

DCE Security Server

Field Descriptions recid--MVS userid; this value cannot be masked. UUID--Specifies the character string form of the user's UUID. This string can have a maximum length of 36 characters. DCENAME--Specifies the character principal name of the user. This field can be a maximum of 1023 characters. HOMEUUID--Specifies the character string form of the user's home cell UUID. This field can contain a maximum of 36 characters. HOMECELL--Specifies the character home cell name. This field can contain a maximum of 1023 characters. AUTOLOG--Indicates that the user should be automatically signed on to OpenEdition DCE. NOAUTOLOG is the default. DCEKEY--A field that is not administered by the ACF command and can never be displayed. The DCEKEY is stored in encoded (masked) or encrypted form in the database depending on how it was originally designated to be stored in the KEYSMSTR profile record. See the Defining DCE under eTrust CA-ACF2 for additional information. eTrust CA-ACF2 automatically creates a UUID/logonid cross-reference table at start-up. If any new profile records are inserted or any changes are made to the UUID or HOMEUUID fields, the cross-reference tables must be refreshed using the F ACF2,OMVS console command. Note: Support for the DFS/SMB encrypted password available in OS/390 V2R9 is included in the DCE profile record. The smbpw command does an EXTRACT REPLACE for the DCEKEY. This value is stored in the DCEKEY field. The DCEKEY is a non-displayable portion of the DCE profile record. Example: An MVS user is defined to OpenEdition DCE by assigning a UUID and HOMEUUID to the user. To do this, create a DCE profile record as follows:

SET PROFILE(USER) DIV(DCE) INSERT JORDAN DCENAME(JORDANM) UUID(uuid) HOMEUUID(homeuuid) HOMECELL(homecell) NOAUTOLOG

Using the MVSEXPT and MVSIMPT Utilities The IBM OpenEdition DCE Administration Guide contains a chapter that discusses security interoperability and the MVSEXPT and MVSIMPT utilities. To successfully run these utilities in an eTrust CA-ACF2 environment, you must perform the following actions for each utility: MVSEXPT--The DCE MVSEXPT utility reads the DCE registry and creates a file containing MVS TSO commands that are used to create corresponding users on MVS. You can use the ACF$DCE EDIT MACRO to convert these commands to eTrust CA-ACF2 command input.

3­16

z/OS and OS/390 Security Cookbook

DCE Security Server

When you use the MVSEXPT utility, run stage one and then edit the output file. While in edit, enter ACF$DCE on the command line to transform the commands into eTrust CA-ACF2 command input to the ACFBATCH utility. Allocate the CLIST library containing the ACF$DCE macro as a SYSPROC library. MVSIMPT--The DCE MVSIMPT utility takes a list of MVS users and creates corresponding entries in the DCE registry. To create the input list of MVS users, first create the eTrust CA-ACF2 user profile DCE records; then run the ACF2UNLD utility. Define a user profile record for each MVS user imported to DCE. By default, MVSIMPT uses the MVS userid as the DCE principal name. To use a different value, specify it in the DCENAME keyword when defining that profile record. Do not specify a UUID because MVSIMPT assumes that the DCE user already exists if a UUID value is present. The following example shows the creation of a user profile DCE record that is retrieved later by the ACF2UNLD utility:

SET PROFILE(USER) DIV(DCE) INSERT JORDAN DCENAME(JORDANM)HOMEUUID(ABBC323C-5CE2-11CF-A61E-08005A470BA1)HOMECELL(/.../CIS TEST1.CIS.DOG.COM)NOAUTOLOG

Once the profile records exist, the ACF2UNLD utility reads these records and creates an output file that is used as input to the MVSIMPT utility. The ACF2UNLD utility can only return those user profile DCE records that the user running the job has the authority to list, so ensure that the user running the utility has the ability to list all user profile DCE records. The output data is placed into the file specified in the ACF2UNLD DD statement. Do not specify any DCB information for the output file. An example of the JCL to run this utility follows:

//jobname JOB job_information //STEP1 EXEC PGM=ACF2UNLD //ACF2UNLD DD DSN=cai.unload.data, // SPACE=(CYL,(1,1)), // UNIT=unit, // DISP=(,CATLG)

The following condition codes can be returned by the utility:

00--Successful completion. 04--No user profile DCE records were returned. Ensure that the user running the utility has the proper authority. 08--An OPEN error occurred.

Implementing USS Applications in an eTrust CA-ACF2 Environment

3­17

DCE Security Server

The output file contains sorted DCE information; no further sorting is needed. Review the output and make any appropriate changes. Copy the file to the HFS file system using the RACFUNLD file name. RACFUNLD is documented in the IBM OpenEdition DCE Administration Guide. Follow the instructions in that guide for the remaining operation of the MVSIMPT utility.

z/OS and OS/390 DCE Support

DCE provides a framework for programs and data on multiple platforms to interoperate following a set of industry-recognized standards. A set of named servers provides central services needed to support the DCE framework. For example, a DCE Time Server maintains a consistent time-of-day clock for all platforms within the DCE environment. A DCE Security Server provides central system entry validation and single-sign on authentication for all DCE users. An IBM mainframe can fully participate in a DCE environment using the DCE support included with z/OS and OS/390. This support allows DCE programs and data to reside on the mainframe under USS and allows the mainframe to interoperate with other DCE platforms. In addition to this support, a separate, optional IBM product enables the mainframe to be a DCE Security Server. While the functions and the administration of a DCE Security Server are completely separate from the mainframe security product (for example, eTrust CA-ACF2, RACF, and so forth), this optional product does allow a limited interface. Defining DCE under eTrust CA-ACF2 Perform the following steps to define DCE under eTrust CA-ACF2: 1. USS must be up and running before DCE support can be configured and activated. The eTrust CA-ACF2 setup of basic USS is separately described but should be reviewed for completeness before continuing. See the Creating eTrust CA-ACF2 Logonid Records for USS section. Define a logonid for the DCEKERN started task (daemon) that executes when DCE is active. Like any other OMVS userid, this logonid must belong to at least one OMVS group ID. The commands that follow define an OMVS group and logonid for DCEKERN using values matching IBM DCE documentation:

SET LID INSERT DCEKERN NAME(DCE KERNEL) STC GROUP(DCEGROUP) UID(0) HOME(/opt/dcelocal/home/dcekern) OMVSPGM(/bin/sh) SET PROFILE(GROUP) DIV(OMVS) INSERT DCEGROUP GID(nn)

2.

3­18

z/OS and OS/390 Security Cookbook

DCE Security Server

3.

The DCEKERN started task requires access to a FACILITY class resource. To accomplish this, create and store the following rule set:

SET RES(FAC) Comp * $KEY(DCEKERN) TYP(FAC) START.REQUEST UID(DCEKERN's UID string) SERVICE(READ) ALLOW STORE

4.

The environment variables (ENVVAR) files for DCE must be updated to disable automatic logon when DCE is started. To make this update, specify _EUV_AUTOLOG=NO in the ENVVAR files in the following directories:

/opt/dcelocal/home/dcekern /opt/dcelocal/home/cdsadv /opt/dcelocal/home/cdsclerk /opt/dcelocal/home/dtsd /opt/dcelocal/home/dced

Failure to make these changes will result in occurrences of the following message when the DCEKERN started task is started.

EUVS00750E AUTOMATIC DCE SIGNON PROCESSING FAILED USER NOT DEFINED TO MVS SECURITY MANAGER CORR: 0 (EUVZUSER)

This message is not a fatal error; even when issued, DCEKERN will fully initialize. 5. eTrust CA-ACF2 lets a DCE segment be optionally defined for any user so that the user's DCE information is reflected if desired. Note that this segment and the information contained within this segment are not required for any user. Users who enter an explicit DCE_LOGIN command under OMVS when beginning their DCE sessions do not use this user information since the DCE_LOGIN command instead relies on the DCE Security Server to provide this data. A user who enters DCE using an already-established DCE session (from another platform) also does not use the DCE segment information, since this data is automatically pre-supplied as part of the user's credentials when the connection is established. The only time that this information is used is when the mainframe houses the DCE Security Server or when an automatic sign-on (implicit DCE_LOGIN) is desired for OMVS users. For the first of these cases, see the IBM documentation on the z/OS and OS/390 DCE Security Server. For the second case, the user segment information must be defined and AUTOLOGIN must be set within the user's DCE profile record.

Implementing USS Applications in an eTrust CA-ACF2 Environment

3­19

Distributed File Service

6.

With release 6.4 of eTrust CA-ACF2, the KEYSMSTR profile record support was added. Perform the following steps to define a KEYSMSTR profile record under eTrust CA-ACF2 for the purposes of designating how the DCEKEY in the DCE record segment (i.e., DFS/SMB password) should be stored, encoded (masked or encrypted): ­ Activate the KEYSMSTR class for DCE administration, by loading the DCE.PASSWORD.KEY record into storage via the addition of an entry for the PKEY infostorage directory in the GSO INFODIR record. For example:

ACF set control(gso) sysid(prod) change infodir types(r-pkey)

­

Insert a KEYSMSTR profile segment record, specifying a 16-igit encryption key mask value as the SSKEY accompanied by one of the following attributes, KEYMASK or KEYCRYPT, to encode (mask) or encrypt the DFS/SMB password. For example:

ACF set profile(keysmstr) div(ssignon) insert dce.password.key sskey(1234567812345678) keymask

­

Refresh the GSO INFODIR record and rebuild the P(KEY) directory. This must be done whenever any changes are made to the DCE.PASSWORD.KEY record. For example:

F ACF2, REFRESH(INFODIR) F ACF2, REBUILD(key),CLASS(p)

Note: If sharing databases with a release 6.3 or lower, eTrust CA-ACF2 systems, you cannot define a KEYSMSTR profile record. See the KEYSMSTR Profile Record section of the Administrator Guide for more information.

Distributed File Service

This Distributed File Service (DFS) is an application that sets up for the DCE access to a set of files and directories on a global basis regardless of machine boundaries. For details and additional information, see the z/OS and OS/390 Distributed File Service Administrator Guide and Reference.

3­20

z/OS and OS/390 Security Cookbook

Distributed File Service

To set up this environment under eTrust CA-ACF2, perform the following: 1. Define logonids and profile records for the DFS associated started tasks:

SET LID INSERT DFSKERN NAME(DFS started task) STC GROUP(DFSGRP) UID(O) HOME(/opt/dfslocal/home/dfscntl) INSERT DFS (DFS started task) STC GROUP(DFSGRP) UID(O) HOME(/opt/dfslocal/home/dfscntl) INSERT DFSCM(DFS started task) STC GROUP(DFSGRP) UID(O) HOME(/opt/dfslocal/home/dfscntl)

2.

Define the group assigned to DFS related logonids as follows:

SET PROFILE(GRP) DIV(OMVS) INSERT DFSGRP GID(nn)

where nn is an appropriate group number. 3. Allow the logonids related to DFS update access to the FACILITY resource DFSKERN.START.REQUEST. The following commands are an example of setting up the appropriate resource rule:

SET RESOURCE(FAC) COMPILE $KEY(DFSKERN) START.REQUEST UID(dfjkern_uid) SERVICE(READ,UPDATE) ALLOW START.REQUEST UID(dfs_uid) SERVICE(READ,UPDATE) ALLOW START.REQUEST UID(dfscm_uid) SERVICE(READ,UPDATE) ALLOW STORE

Note: If the DFSKERN FACILITY resource rule already exists at your site, simply add the appropriate rule entries to it. 4. Issue the following commands to activate the changes specified above:

F F F F ACF2,REBUILD(USR),CLASS(P) ACF2,REBUILD(GRP),CLASS(P) ACF2,OMVS ACF2,REBUILD(FAC)

Note: The last command is only necessary if the FACILITY class resource rules were made resident via the GSO INFODIR record. 5. Individual users are defined via DCE credentials. See the eTrust CA-ACF2 Support for the DCE Security Server section for details.

Implementing USS Applications in an eTrust CA-ACF2 Environment

3­21

Network File System (NFS)

Network File System (NFS)

z/OS and OS/390 Network File System (NFS) enables remote access to z/OS and OS/390 data sets and UNIX System Services HFS files and directories. NFS can protect file systems on MVS using four protection schemes. These setting are defined within the NFS "Site Attributes' Security". The possible settings are:

NONE--Do not restrict access. NO MVS userid required. EXPORTS--Restrict access by client IP address. NO SAF check. SAF--Use SAF to control access to data sets or HFS data. SAFEXP--Use SAF and EXPORTS to control access. This is the most secure setting.

Both SAF and SAFEXP require the user to use the `mvslogin' process to validate access through a SAF call. For this reason, eTrust CA-ACF2 recommends a minimum of security (saf). Users who attempt to access HFS data must have a valid OMVS segment assigned to their MVS logonid. Access to HFS files is determined by validating the client's UID and group against the file UNIX permission bits. Under normal circumstances, access to z/OS and OS/390 data sets requires the z/OS and OS/390 NFS server and client user to pass a security check for the resource. The exception to this is when DataCaching is enabled. Data caching causes data to be stored on the z/OS and OS/390 NFS client system. When data caching is enabled, the first user attempting to access a z/OS and OS/390 data set must pass a SAF security check. This SAF call is issued by the z/OS and OS/390 NFS Server. Once passed, the data set is stored in the OS/390 NFS Client server. Subsequent requests will let all users access the cached data without further restrictions. Data caching by default is enabled. eTrust CA-ACF2 recommends that DataCaching be disabled. With DataCaching(N), no client data caching takes place, therefore each user must pass the OS/390 NFS Security server check prior to being granted access to data. z/OS and OS/390 NFS Server `Site Attribute' `checklist' lists the files and or directories for which SAF security is bypassed, even when SAF or SAFEXP is specified. For this reason, proper care must be taken to secure this data set. The checklist data set is defined using the CHKLIST DD in the MVSNFS procedure.

3­22

z/OS and OS/390 Security Cookbook

Firewalls

eTrust CA-ACF2 Support for z/OS and OS/390 NFS

To define eTrust CA-ACF2 support for z/OS and OS/390 NFS, use the following procedure: 1. Create logonids and user profile records for the NFS Server, the NFS Client, the NFS Lock Manager (NLM), and the NFS Network Status Monitor (NSM) started tasks (these logonids require a UID(0)):.

SET LID INSERT MVSNFS NAME(NFS Server) STC GROUP(OMVSGRP) NON-CNCL UID(0) HOME(/u/mvsnfs) OMVSPGM(/bin/sh) INSERT MVSNFSC NAME(NFS Client) STC GROUP(OMVSGRP) UID(0) HOME(/u/mvsnfsc) OMVSPGM(/bin/sh) INSERT MVSNLM NAME(NFS Lock Manager) STC GROUP(OMVSGRP) UID(0) HOME(/u/mvsnlm) OMVSPGM(/bin/sh) INSERT MVSNSM NAME(NFS Network Status Monitor) STC GROUP(OMVSGRP) UID(0) HOME(/u/mvsnsm) OMVSPGM(/bin/sh)

2.

If the group assigned to these started tasks has not been previously created, create a group profile record:

SET PROFILE(GROUP) DIV(OMVS) INSERT OMVSGRP GID(nn)

Replace nn with the appropriate GID value. 3. The logonids associated with the started tasks require access to data sets that the remote users are accessing. Ensure that these logonids have the appropriate authority to access these data sets. To activate the changes made for NFS, issue the following commands:

F ACF2,REBUILD(USR),CLASS(P) F ACF2,REBUILD(GRP),CLASS(P) F ACF2,OMVS

4.

Firewalls

z/OS and OS/390 provides the ability to run a firewall under UNIX System Services. Support is distributed in part with the communication server and in part with the security server. The z/OS and OS/390 firewall can reduce, but not necessarily eliminate the need for a non-z/OS and OS/390 platform firewall. The firewall itself is not configured using eTrust CA-ACF2. Administration is performed through configuration files.

Implementing USS Applications in an eTrust CA-ACF2 Environment

3­23

Firewalls

Follow these steps to set up the z/OS and OS/390 firewall with eTrust CA-ACF2: 1. Define the firewall startup address space logonid and user profile record:

INSERT FWKERN NAME(Firewall Startup Id) STC GROUP(FWGRP) UID(0) HOME(/usr/lpp/fw/home/fwkern) OMVSPGM(/bin/sh)

2.

Define the additional started task logonids used by the firewall daemons and their user profile records:

INSERT ICAPSLOG NAME(Firewall Daemon Id) STC GROUP(FWGRP) UID(0) HOME(/u/fwkern) OMVSPGM(/bin/sh) INSERT ICAPSOCK NAME(Firewall Daemon Id) STC GROUP(FWGRP) UID(0) HOME(/u/fwkern) OMVSPGM(/bin/sh) INSERT ICAPPFTP NAME(Firewall Daemon Id) STC GROUP(FWGRP) UID(0) HOME(/u/fwkern) OMVSPGM(/bin/sh) INSERT ICAPCFGS NAME(Firewall Daemon Id) STC GROUP(FWGRP) UID(0) HOME(/u/fwkern) OMVSPGM(/bin/sh) INSERT ICAPSTAK NAME(Firewall Daemon Id) STC GROUP(FWGRP) UID(0) HOME(/u/fwkern) OMVSPGM(/bin/sh) INSERT ICAPIKED NAME(Firewall Daemon Id) STC GROUP(FWGRP) UID(0) HOME(/u/fwkern) OMVSPGM(/bin/sh)

3.

Add a profile record to define the group used by the firewall logonid using any unused GID number:

SET PROFILE(GROUP) DIV(OMVS) INSERT FWGRP GID(nn)

4.

Allow FWKERN to issue start commands:

SET RESOURCE(FAC) COMPILE $KEY(FWKERN) TYPE(FAC) START.REQUEST UID(fwkern) ALLOW STORE

5.

Allow FWKERN access to READ the TCP/IP data sets using the standard data set access rules:

COMPILE $KEY(TCPIP) - UID(fwkern) R(A) STORE

Note: The high level qualifier of these data sets might have been renamed from "TCPIP" when installed on your system. 6. Allow the FWKERN logonid access to the SMF logging facility and the BPX.DAEMON facility. Add the following rules entries to the BPS FACILITY rule:

SMF UID(fwkern) SERVICE(READ) ALLOW DAEMON UID(fwkern) SERVICE(READ) ALLOW

3­24

z/OS and OS/390 Security Cookbook

Firewalls

7.

Any user specified on the configuration GUI must be given permission to update the FACility resource ICA.CFGSRV even if the user has superuser status. Create the following resource rule to allow the required users access to this resource:

$KEY(ICA) TYPE(FAC) CFGSRV UID(userid_uid) SERVICE(READ,UPDATE) ALLOW

8.

If FWKERN uses the ISAKMP server to allow secure communications through non-secure networks, the following needs to be done with eTrust CA-ACF2: a) Allow the FWKERN logonid access to the FACility resources CDS.CSSM, CDS.CSSM.CRYPTO, and CDS.CSSM.DATALIB as follows:

$KEY(CDS) TYPE(FAC) CSSM UID(fwkern) SERVICE(READ) ALLOW CSSM.CRYPTO UID(fwkern) SERVICE(READ) ALLOW CSSM.DATALIB UID(fwkern) SERVICE(READ) ALLOW

b) If the system operates with USS, let FWKERN access the FACility resource BPX.SERVER so that the ISAKMP server can use OSCF services as follows. Add the following rule entry to the BPX FACILITY rule:

SERVER UID(fwkern) SERVICE(READ) ALLOW

c)

So the ISAKMP server can use the OCEP services, allow FWKERN access to the FACility resources IRR.DIGTCERT.LIST and IRR.DIGTCERT.LISTRING as follows:

$KEY(IRR) TYPE(FAC) DIGTCERT.LIST UID(fwkern) SERVICE(READ) ALLOW DIGTCERT.LISTRING UID(fwkern) SERVICE(READ) ALLOW

d) The ISAKMP server supports peer authentication using RSA signature mode. RSA signatures require that digital certificates be stored in eTrust CA-ACF2 and connected onto a key ring. e) See the SHOW CRITMAP section. Show CRITMAP displays information contained in CRITMA records as laid out in the internal CRITMAP table. The diplay shows the record id, SYSID, APPLID, USERID, and associated application variables.

sho critmap - CRITERIA TABLE ­ Record key SYSTEMID APPLID ================== ======== ====== =============================== CRITMAP.PUBLIC2 * CICSAPPL CRITMAP.PLATINUM CRITMAP.UCCEL CRITMAP.PUBLIC1 * * * HRAPPL HRAPPL WEBAPPL USERID ====== PUBLIC2 PLATUSER UCCUSER PUBLIC1 COMPANY=PLATINUM COMPANY=UCCEL APPLICATION VARS

Implementing USS Applications in an eTrust CA-ACF2 Environment

3­25

Integrated Cryptographic Service Facility

Adding Firewall Administrators to FWGRP

Firewall administrators must be members of the group FWGRP or have superuser authority. The following commands give an administrator access to the firewall group:

SET RESOURCE(TGR) COMPILE $KEY(FWGRP) TYPE(TGR) UID(adminid) ALLOW STORE

Firewalls can invoke z/OS and OS/390 Integrated Cryptographic facilities to perform internal security functions. These services are protected using the resource class CSFSERV. This is accomplished using the following commands:

SET RESOURCE(SAF) COMPILE $KEY(service-name) TYPE(SAF) UID(userid) SERVICE(READ) ALLOW STORE

Note: The CSFSERV class defaults to SAF and should be changed to a type code unique to the CSFSERV class via an eTrust CA-ACF2 CLASMAP record. See the Integrated Cryptographic Service Facility section for additional information. Users must be permitted to the necessary individual services. The individual service-names are documented in the appropriate IBM firewall manuals and the IBM ICSF/MVS Administrators Guide. Also see Integrated Cryptographic Service Facility in this chapter.

Integrated Cryptographic Service Facility

The Integrated Cryptographic Service Facility (ICSF) from IBM is a high-powered cryptographic coprocessor that allows z/OS and OS/390 applications to use cryptography. The z/OS and OS/390 security server provides APIs to invoke ICSF rather than use software algorithms to perform the same functions. ICSF also provides various functions involved with the management of keys. These services combine to provide a site with the ability to manage public keys.

3­26

z/OS and OS/390 Security Cookbook

Integrated Cryptographic Service Facility

The interface to ICSF and the security manager consists of two areas: the ability for an application to read a key and the APIs to manage keys. ICSF makes SAF calls to external security to allow ICSF to be secured and audited. There are two resource classes that provide this support:

CSFKEYS--This class is used to secure encryption keys. The value, which is owned and permitted, is the key label. The key label is specified in the CKDS or PKDS when a key is defined. CSFSERV--This class is used to secure the various cryptographic services needed to encrypt data and manage keys. The services are listed in the IBM z/OS and OS/390 Integrated Cryptographic Service Facility: Administrator's Guide.

These two classes are predefined in the internal CLASMAP records and specify a default type code of SAF for any resource rules. For example, if a user needs to use the ANSI X9.17 key export callable service, the SAF call would validate a resource of CSFAKEX, as indicated in the ICSF documentation. To allow access to this resource quoted in the example, a resource rule, similar to the one presented below, should be coded:

SET RESOURCE(SAF) COMPILE $KEY(CSFAKEX) TYPE(SAF) UID(userid) ALLOW STORE

Note: You can separate the ICSF resource rules into unique type codes, if desired, by defining CLASMAP records and specifying a different rsrctype as suggested below:

SET CONTROL(GSO) INSERT CLASMAP.CSFKEYS RESOURCE(CSFKEYS) RSRCTYPE(CSK) ENTITYLN(73) INSERT CLASMAP.CSFSERV RESOURCE(CSFSERV) RSRCTYPE(CSF) ENTITYLN(8)

It has been noted that security calls pertaining to ICSF issued in a CICS environment are validating the logonid of the CICS region not the logonid of the user making the call. IBM has noted that ICSF currently works by picking up the userid from the associated TCB, which contains the CICS region userid. ICSF does not currently have the ability to pick up the signed in userid that actually made the call in a CICS environment.

Implementing USS Applications in an eTrust CA-ACF2 Environment

3­27

Novell Network Services

Novell Network Services

Novell Network Services are available starting with OS/390 Release 2.6. Novell Network Service allows a workstation to share files, printers, and other resources among various PCs running on DOS and Windows. Support has been added to map a Novell Directory Services (NDS) application user identity to an eTrust CA-ACF2 logonid. Novell Network Services requires these special logonids for processing: NWROOT, NWUSER, and NOBODY. The following example shows how to set up the Network Services logonids and their associated profile records:

SET LID INSERT NWROOT GROUP(NWGROUP) RESTRICT UID(nn) HOME (/) OMVSPGM(/bin/sh) INSERT NWUSER GROUP(NWGROUP) RESTRICT UID(nn) HOME (/) OMVSPGM(/bin/sh) INSERT NOBODY GROUP(NOGROUP) RESTRICT UID(nn) HOME (/) OMVSPGM(/bin/sh)

Replace nn with the appropriate UID value.

SET PROFILE(GROUP) DIV(OMVS) INSERT NWGROUP GID(xx) INSERT NOGROUP GID(yy)

Replace xx and yy with appropriate GID values. To support Novell Network Services, insert a NDS user profile record for each user using Novell Network Services:

SET PROFILE(USER) DIV(NDS) INSERT NWROOT UNAME(nwroot) INSERT NWUSER UNAME(nwuser) INSERT NOBODY UNAME(nobody) INSERT USERA UNAME(usera on Novell)

Anytime changes are made to USER or GROUP profile records, the following commands must be issued to activate the changes immediately:

F ACF2,REBUILD(USR),CLASS(P) F ACF2,REBUILD(GRP),CLASS(P) F ACF2,OMVS

Kerberos

Network Authentication and Privacy Service, known as Kerberos, uses eTrust CA-ACF2 to store and administer information about principals and realms. KERB and KERBLINK USER profile records and REALM GSO records have been incorporated into eTrust CA-ACF2 to store this information.

3­28

z/OS and OS/390 Security Cookbook

Kerberos

The KERB USER profile record is used to store information about Network Authentication and Privacy Service principals on your local system. The KERBLINK USER profile record lets you map principals to eTrust CA-ACF2 logonids on your system, and GSO REALM record defines the local Network Authentication and Privacy Service realm and its trust relationships with foreign realms. eTrust CA-ACF2 also provides support for callable services, namely R_ticketserv and R_kerbinfo for OS/390 applications servers that use Kerberos services. Note that as Kerberos is being incorporated into eTrust CA-ACF2, some terminology and naming structures might change.

Authentication of Principals

Kerberos for OS/390 verifies requests as a trusted third-party authentication service. Using conventional shared secret key cryptography, Kerberos confirms the identities of principals (users), without relying on authentication by the host operating system, without basing trust on host addresses, without necessitating physical security of all hosts on the network, and under the premise that packets traveling along the network can be read, changed, and inserted at will. Kerberos uses electronic tickets to authenticate a user to a server. A ticket, which is good only for a single server and a single user during a certain period of time, is an encrypted message containing the name of the user and server, the user's network address, a time stamp, and a session key. Once the user gets this ticket, he can use it to access the server as many times as desired until the ticket expires. The user cannot decrypt the ticket but can only present it to the server. Nobody listening in on the network can read or modify the ticket as it passes through the network without detection or invalidation. The Kerberos protocol involves two servers, the Kerberos Authentication Server and one or more TGSes (Ticket-Granting Servers). The steps involved in the Kerberos process are as follows. 1. To obtain a ticket to a particular target server, the user first requests from the Kerberos Authentication Server a ticket to the Kerberos TGS. This request takes the form of a message containing the user's name and the name of his TGS (there can be several). The Authentication Server looks up the user in its database and then generates a session key to be used between the user and the TGS. Kerberos encrypts this session key using the user's secret key (a one-way hash of the user's password). Then it creates a TGT (ticket-granting ticket) for the user to present to the TGS and encrypts the TGT using the TGS's secret key (which is known only to the Authentication Server and the TGS). The Authentication Server sends both of these encrypted messages back to the user.

2.

Implementing USS Applications in an eTrust CA-ACF2 Environment

3­29

Kerberos

3.

The user decrypts the first message and recovers the session key. Next, the user creates an authenticator consisting of his name and address and a time stamp, all encrypted with the session key just generated by the Kerberos Authentication Server. The user then sends a request to the TGS for a ticket to a particular target server. This request contains the name of the server, the TGT received from Kerberos (which is already encrypted with the TGS's secret key), and the encrypted authenticator. The TGS decrypts the TGT with its secret key and then uses the session key included in the TGT to decrypt the authenticator. It compares the information in the authenticator with the information in the ticket, the user's network address with the address the request was sent from, and the time stamp with the current time. If everything matches, it allows the request to proceed. The TGS creates a new session key for the user and target server and incorporates this key into a valid ticket for the user to present to the server. This ticket also contains the user's name, network address, a time stamp, and an expiration time for the ticket--all encrypted with the target server's secret key--and the name of the server. The TGS also encrypts the new user-target session key using the session key shared by the user and the TGS. It sends both messages to the user. The user decrypts the message and extracts the session key for use with the target server. The user is now ready to authenticate himself to the server. He creates a new authenticator encrypted with the user-target session key that the TGS generated. To request access to the target server, the user sends along the ticket received from Kerberos (which is already encrypted with the target server's secret key) and the encrypted authenticator. Because this authenticator contains plain text encrypted with the session key, it proves that the sender knows the key. Just as important, encrypting the time of day prevents an eavesdropper who records both the ticket and the authenticator from replaying them later. The target server decrypts and checks the ticket and the authenticator, also checking the user's address and the time stamp. If everything checks out, the server now knows the user is who he claims to be, and the two share an encryption key that they can use for secure communication. (Since only the user and the server share this key, they can assume that a recent message encrypted in that key originated with the other party.) For those applications that require mutual authentication, the server sends the user a message consisting of the time stamp plus 1, encrypted with the session key. This serves as proof to the user that the server actually knew its secret key and was able to decrypt the ticket and the authenticator.

4.

5.

6.

7.

8.

3­30

z/OS and OS/390 Security Cookbook

Kerberos

Realms

The Kerberos protocol functions across organizational boundaries. An organization running on a Kerberos server must establish its own realm. A client's name contains the name of the realm in which a client is registered, so that the application server can use the realm name to determine whether to grant a request. With the establishment of inter-realm keys, the administrators of the two realms can permit a client authenticated in one realm to use its credentials in the other realm. Exchanging inter-realm keys registers the ticket-granting service of each realm as a principal in the other. A client can then procure a ticket-granting ticket for the remote realm's ticket-granting service from its local ticket-granting service. Tickets distributed to a service in the remote realm indicate that the client was authenticated from another realm. This procedure can be used to authenticate throughout an organization across multiple realms. In order to construct an authentication path to a foreign realm, the local realm must share an inter-realm key with the target realm or with an intermediate realm that communicates with the target realm or with another intermediate realm. Realms are often organized hierarchically. A realm shares a key with its parent and different key with each child. In a hierarchical organization, an authentication path can be easily established if two realms do not share an inter-realm key. If a hierarchical organization is not in place, referring to a database in order to build an authentication path between realms can be required. Although realms are often hierarchical, intermediate realms can be overridden, resulting in cross-realm authentication through alternate authentication paths. The end-service must know which realms were transited when determining how much confidence to have in the authentication process. To aid this process, a field in each ticket includes the realm names that helped authenticate the client. Before setting up the eTrust CA-ACF2 definitions to support the Network Authentication and Privacy Service Implementation, you must understand the records that must be defined and how and their relationship. REALM records define your local foreign realms. The local realm name (REALM field on the REALM GSO record) is used in the construction of the key generated for foreign realms and local principals. This is very important especially in a shared database environment. Care must be taken when changing the local realm name. If the local realm name is changed after creating the keys for your principals and realms, the keys are invalid and must be reset.

Implementing USS Applications in an eTrust CA-ACF2 Environment

3­31

Kerberos

Shared Database Environment

Keys for principals are kept in the eTrust CA-ACF2 Logonid database. Keys for foreign realms are kept in the eTrust CA-ACF2 Infostorage database. When you share the eTrust CA-ACF2 Logonid database between multiple systems, the REALM GSO record used on each system must contain the same local realm name on both systems. This will allow the same key to be generated on all systems sharing the eTrust CA-ACF2 Logonid database.

Defining Your Local Realm

You must define your local realm to eTrust CA-ACF2 before you define local principals. This is because the local realm is used to generate keys for local principals. You define your local realm by creating a REALM GSO record called KERBDFLT. You can specify the following information about your local realm: Command syntax:

INSERT REALM.qualifier REALM(Kerberos-realm-name) MINTKTLF(Min-ticket-life) MAXTKTLF(Max-ticket-life) DEFTKTLF(Default-ticket-life) KERBPASS(Kerberos-password)

Qualifier--A label-name to identify the GSO realm record. You must specify the name of KERBDFLT for the local realm. REALMNAME--(Kerberos realm name) Specifies the unqualified name of the local realm for Network Authentication and Privacy Service Server. The maximum length of this field is 117 characters. The fully qualified name of the local realm, /.../Kerberos_realm_name/krbtgt/Kerberos_realm_name, must not be specified. The name assigned to the local realm limits the length of local principal names, since fully qualified principal names/.../Kerberos_realm_name/Principal_name, cannot exceed 240 characters. Regardless of the case in which it is entered, ETrust CA-ACF2 rolls the name of the local Network Authentication and Privacy Service realm to upper case. However, ETrust CA-ACF2 does not ensure that a valid Kerberos-realm-name has been specified. Note: Because the relationship between the REALM value and generating Kerberos tickets for principal users is based, in part, on the local REALM value, care must be taken when choosing a REALM value. Renaming the REALM should be avoided at all costs. MAXTKTLF--Specifies the maximum ticket life in seconds and is represented by a numeric value between 1 and 2 147 483 647. Note that 0 is not a valid value. This keyword is only applicable when defining the KERBDFLT GSO REALM record. If MAXTKTLF is specified, DEFTKTLF and MINTKTLF must also be specified.

3­32

z/OS and OS/390 Security Cookbook

Kerberos

MINTKTLF--Specifies the minimum ticket life in seconds, and is represented by a numeric value between 1 and 2 147 483 647. Note that 0 is not a valid value. This keyword is only applicable when defining the KERBDFLT GSO REALM record. If MINTKTLF is specified, DEFTKTLF and MAXTKTLF must also be specified. DEFTKTLF--Specifies the default ticket life in seconds, and is represented by a numeric value between 1 and 2 147 483 647. Note that 0 is not a valid value. This keyword is only applicable when defining the KERBDFLT GSO REALM record. If DEFTKTLF is specified, MINTKTLF and MAXTKTLF must also be specified. KERBPASS--Specifies a password for the default realm. The maximum length of this value is 8 characters. The PASSWORD keyword is applicable to all REALM GSO record definitions. A password is required in order for the local realm to grant ticket-granting-tickets and a password must be associated with the definition of an inter-realm trust relationship, or the definition is incomplete. The Kerberos password that you define to eTrust CA-ACF2 might consist of any character. It is highly recommended that use of any of the EBCDIC variant characters be avoided to prevent problems with different code pages. Passwords are case-sensitive and are maintained in the case in which they are entered. Note: This password is not an eTrust CA-ACF2 user password and is not constrained by password rules that might be specified to control user passwords. Command example:

Set control(GSO) Insert realm.kerbdflt realm(lisle.ca.com) min(30) max(86400) def(36000) kerb(children) XE41 / REALM.KERBDFLT LAST CHANGED BY ADMIN01 ON 08/28/00-11:28 CURKEYV(1) DEFTKTLF(36000) MAXTKTLF(86400) MINTKTLF(30) REALM(LISLE.CAI.COM)

In this example, the realm name is KERBDFLT, which identifies this record as the default realm record. The Kerberos realm name is Local.ca.com, with a password of children. The default ticket life is 10 hours, a minimum ticket life of 30 seconds, and a maximum ticket life of 24 hours. See the Administrator Guide for any additional information about GSO REALM records.

Defining Local Principals

eTrust CA-ACF2 logonids can become Kerberos local principals by defining a KERB segment USER profile record. The KERB segment maps a Kerberos for z/OS and OS/390 application user identity to an eTrust CA-ACF2 logonid. Each local pricipal must have an eTrust CA-ACF2 password so do not define a local principal with the RESTRICT attribute.

Implementing USS Applications in an eTrust CA-ACF2 Environment

3­33

Kerberos

The KERB segment has the following fields: recid--This is a one to eight character logonid that is to be associated with the local principal name. A one to eight character suffix can be appended to the userid to create a unique record key. The suffix must be separated from the userid with a period. KERBNAME--Specifies the local Kerberos principal name. The kerberos-principal-name you define can consist of any character except the @ (X'7'C) character. It is highly recommended that any of the EBCDIC variant characters be avoided to prevent problems between different code pages. This field is case sensitive. eTrust CA-ACF2 will not ensure that a valid Kerberos principal name has been entered. A local Kerberos principal name must not be qualified with a realm name when specified in the KERBNAME parameter. eTrust CA-ACF2 will verify that the local principal name, when qualified with the local realm name, does not exceed 240 characters. For example, if the local realm name is REALM1, fully qualified local principal names are prefixed with/.../RELAM1/ and are limited to 228 characters. If the local realm name is REALM1.LISLE.CA.COM, fully qualified local principal names are prefixed with /.../REALM1.LISLE.CA.COM/ and are limited to 215 characters. The length verification requires that the GSO REALM record for the local realm KERBDFLT be defined and contain the name of the local realm before inserting the KERB USER profile records. Otherwise, the local Kerberos principals might not be properly defined. MAXTKTLF--Maximum ticket life for this field is in seconds. The range of values is from 1 to 2,147,483,647 seconds. If the MAXTKTLF parameter is defined for a principal, the system takes the most restrictive of the values defined for the principal and the value specified on the definition of the local realm (GSO REALM record with REALM(KERBDFLT). If the value in the principal definition exceeds the value in the local realm definition, the value in the local realm definition is used. KERB-VIO--Specifies the number of Kerberos key violations. This field is similar to the PSWD-VIO count and will e used to suspend the user's LID when the count exceeds the global password violation limit. Command example:

Set lid Insert TLC089 kerbname(steven.tlc.com) maxtktlf(86400) KERB / TLC089 LAST CHANGED BY ADMIN01 ON 08/28/01-12:20 KERB-VIO(O) KERBNAME(steven.ca.com) MAXTKTLF(86400)

In this example, a KERB segment was added to user TLC089, with a Kerberos principal name of steven.tlc.com, and a maximum ticket life of 24 hours.

3­34

z/OS and OS/390 Security Cookbook

Kerberos

Generating Keys for Local Principals

Each local principal must have a key registered with the local Network Authentication and Privacy Service server in order to be recognized as a local principal. The user's definition as a local principal is not complete until the key is generated. The key is generated from the principal's eTrust CA-ACF2 user password at the time of the user's password change. If you want to change the password to generate the key, be sure to use a password change facility that will not result in an expired password that the user must change at the next logon. For example, you can use NOPSWD-EXP on the change command. A local principal's key is revoked whenever the user's eTrust CA-ACF2 user id is suspended or the password is expired. If the user's key is revoked, the server will reject ticket requests from this user. Security administrator method: You can change a user's password so that a key can be generated using the CHANGE command with the NOPSWD-EXP option. For example:

Set lid Change tlc089 password(mypass) nopswd-exp

User method: Users can change their own passwords, completing their own definitions as local principals, by using any standard eTrust CA-ACF2 password-change facility, such as the following:

TSO ACF command (Change command) TSO LOGON CICS LOGON

System Considerations for Key Generation

Your installation can share the eTrust CA-ACF2 databases with systems that support KERB User profile records and those that do not. You should not allow users to change their own passwords for key generation from systems that do not support the KERB User profile records. Keys will only be generated when users change their passwords from systems that support the KERB User profile records. Password changes made from systems that do not support the KERB User profile record will not generate keys to complete the user's local principal definitions.

Implementing USS Applications in an eTrust CA-ACF2 Environment

3­35

Kerberos

Customizing your Foreign Environment

Defining Foreign Realms You define foreign realms by creating REALM GSO records. The REALM field of the REALM GOS record contains the fully qualified name of both servers in the relationship. The REALM field uses the following format:

//.../realm_1/krgtgt/realm_2

A foreign realm definition also contains a password. The password is not the same as the eTrust CA-ACF2 user password and is not constrained by the same rules. The password must be defined to create a trust relationship between the realms. For example:

Set Control(GSO) Insert realm.newyork realm(//.../Chicago.ca.com/krbtgt/newyork.ca.com) kerbpswd(abcdefg)

Mapping Foreign Principal Names You map foreign principal names to eTrust CA-ACF2 users on your local system by defining KERBLINK User profile records. You can map each principal in a foreign realm to it's own logonid on the local system or you can map all principals from a foreign realm to the same logonid on your system. eTrust CA-ACF2 users that map to foreign principals do not need KERB User profile records. These id's are intended to be used only to provide local eTrust CA-ACF2 identities to associate with access privileges for local resources that are under control of an application server, such as DB2. KERBLINK User Profile Record The KERBLINK USER profile record defines the foreign principals to a local node by linking it to a defined user. The eTrust CA-ACF2 user mapped to the foreign principal is defined in the recid of the record. KERBLINK profiles can define an individual principal from a foreign realm or all principals from a particular foreign realm. The local logonid does not need to have a KERB User Profile record associated with it. The fields in the KERBLINK record Recid--This is a 1- to 8-character userid that is to be associated with the foreign principal

3­36

z/OS and OS/390 Security Cookbook

Kerberos

Qualifier--A 1- to 8-character qualifier or suffix can be appended to the recid to create a unique record key. The suffix must be separated from the userid with a period. Name--Defines the foreign principal name. The foreign principal must be fully qualified with the name of the foreign realm. eTrust CA-ACF2 will verify that the NAME field starts with /.../ to ensure a valid field. The maximum length of this field is 240-characters. If you wish to map the same eTrust CA-ACF2 LID to all foreign principals in a foreign name, only specify the foreign realm name. The NAME field is folded to uppercase upon entry. Command examples:

Set Profile(user) Div(kerblink) insert tlc696 name(/.../chicago.tlc.com/FamousBear) KERBLINK / TLC696 LAST CHANGED BY TLC250 ON 04/02/02-13:53 NAME(/.../CHICAGO.TLC.COM/FAMOUSBEAR) insert tlcpub name(/.../chicago.ca.com) KERBLINK / TLCPUB LAST CHANGED BY TLC250 ON 04/02/02-13:55 NAME(/.../CHICAGO.TLC.COM)

The first example maps the foreign principal FamousBear from chicago.tlc.com to the logonid TLC696. The second example maps all other principals from chicago.tlc.com to the logonid TLCPUB. Note: All characters in the NAME field are folded to uppercase. Controlling Applications that Invoke the R_ticketserver Callable Service Authorized applications, such as servers, can invoke the R_ticketserv callable service to extract principal names from a GSS-API context token. This enables an application server to determine the client principal who originated an application-specific request, when the request includes a GSS-API context token and the intended receipt is the application server. For detailed information about invoking the R_ticketserv callable service, see the IBM's z/OS SecureWay Security Server RACF Callable Services guide. Applications that run in system key or in supervisor state do not require eTrust CA-ACF2 authorization to use the R_ticketserv callable service. Applications that do not run in system key or in supervisor state require READ access from eTrust CA-ACF2 to the IRR.RTICKETSERV Facility class resource. For example:

Set Resource Compile .$KEY(IRR) TYPE(FAC) .RTICKETSERV UID(***USER1) SERVERIC(READ) ALLOW Store

In order for this rule to take effect you must rebuild the Facility class rules by issuing:

F ACF2,REBUILD(FAC)

Implementing USS Applications in an eTrust CA-ACF2 Environment

3­37

HTTP Server

HTTP Server

The HTTP server, originally known as the Lotus Domino Go Webserver (DGW), and also known as the OS/390 Internet Connection Security Server, is an IBM component that lets the MVS mainframe act as an Internet web server. This component is installed and managed as a USS application. By default, the HTTP server application files are installed in the OMVS environment in a directory named /usr/lpp/internet. As documented by IBM, installation of the HTTP server involves several steps for the security administrator. The following information documents the commands necessary when installing this component under eTrust CA-ACF2.

Prerequisites

To use the HTTP server in an eTrust CA-ACF2 environment, started task (STC) validation must be active.

Installation Steps

Follow these steps to install and implement the HTTP server: 1. Logonids must exist for the OMVS, INETD, and TCPIP started tasks. In addition, these logonids must be connected to an OMVS group record. The HTTP server also requires access to a group called TTY. The following examples reflect default started task (STC) procedure names, and a typical name and GID for the OMVS group ID. Overall, these commands ensure that a valid OMVS UID and GID exist for each of the started tasks necessary to access OMVS. Note: If USS has been previously set up, some or all of this step may already be complete.

To create the necessary logonids and profile records, issue these commands:

ACF SET LID INSERT OMVS GROUP(OMVSGRP) STC UID(0) INSERT INETD GROUP(OMVSGRP) STC UID(0) HOME(/) OMVSPGM(/bin/sh) INSERT TCPIP GROUP(OMVSGRP) STC UID(0)

3­38

z/OS and OS/390 Security Cookbook

HTTP Server

To define the necessary eTrust CA-ACF2 group profile records, issue these commands:

SET PROFILE(GROUP) DIV(OMVS) INSERT OMVSGRP GID(nn) INSERT TTY GID(nn) END

2.

The HTTP server requires logonids for the Web server started task and for a Web administrator. Both of these logonids must be connected to a Web server group ID. The commands below accomplish this and contain values matching IBM examples. Note that the Web server started task is also referred to as the Web server daemon. The Web server STC procedure name is WEBSRV. To create the necessary logonids and profile records for the Web server started task and the Web administrator, issue these commands:

ACF SET LID INSERT WEBSRV NAME(WEBSERVER DAEMON) GROUP(IMWEB) STC UID(0) HOME(/usr/lpp/internet) PROGRAM(/bin/sh) INSERT WEBADM NAME(WEB ADMINISTRATOR) GROUP(IMWEB) PASSWORD(password) UID(nn) HOME(/usr/lpp/internet) PROGRAM(/bin/sh) SET PROFILE(GROUP) DIV(OMVS) INSERT IMWEB GID(205) END

Note: Since the WEBSRV logonid is accessed via a RACROUTE EXCTRACT request, the access information in this logonid is not updated. If your site monitors the access information to determine inactive logonids, please note this fact. Note: If the WEBSRV logonid is given NO-SMC to improve the through put in the address space, you must ensure that the WEBSRV address space is never cancelled or forced from the system. 3. The IBM documentation discusses the probable need for several surrogate userids. Three suggested logonids and their associated group definitions are mentioned in the documentation. The names of the userids, groups, and the suggested UID and GID values are shown below:

ACF SET LID INSERT PUBLIC NAME(WEB SURROGATE ID) GROUP(EXTERNAL) RESTRICT UID(998) HOME(/) PROGRAM(/bin/sh) INSERT INTERNAL NAME(WEB SURROGATE ID) GROUP(EMPLOYEE) RESTRICT UID(537) HOME(/) PROGRAM(/bin/sh) INSERT PRIVATE NAME(WEB SURROGATE ID) GROUP(SPECIAL) RESTRICT UID(416) HOME(/) PROGRAM(/bin/sh)

Implementing USS Applications in an eTrust CA-ACF2 Environment

3­39

HTTP Server

SET PROFILE(GROUP) DIV(OMVS) INSERT EXTERNAL GID(999) INSERT EMPLOYEE GID(500) INSERT SPECIAL GID(255) END

4.

The logonid for the Web server started task (daemon) requires access in both the FACILITY and SURROGAT resource classes. The following rules use the default type code values specified in the CLASMAPs shipped with eTrust CA-ACF2 . Be sure to verify that your site has not added local CLASMAP records to change these type code values. For the FACILITY resource class, add the following rule entries to the existing BPX FACILITY resource rule:

DAEMON UID(websrv) SERVICE(READ) ALLOW DAEMON UID(inetd-lid) SERVICE(READ) ALLOW SERVER UID(websrv) SERVICE(READ,UPDATE) ALLOW

For the SURROGAT resource class, create a resource rule similar to the example below, using the following commands:

ACF SET RESOURCE(SUR) COMPILE $KEY(BPX) TYPE(SUR) SRV.INTERNAL UID(websrv) SERVICE(READ) ALLOW SRV.PRIVATE UID(websrv) SERVICE(READ) ALLOW SRV.PUBLIC UID(websrv) SERVICE(READ) ALLOW SRV.WEBADM UID(websrv) SERVICE(READ) ALLOW STORE END

Note: If the SURROGAT (TYPE SUR) rule already exists, add the necessary rule entries to it and recompile the rule. If either the FAC or SUR rules are made resident via the GSO INFODIR record, issue the following commands, as appropriate:

F ACF2,REBUILD(FAC) F ACF2,REBUILD(SUR)

5.

Users need access to web server related libraries. See the appropriate IBM documentation and/or site naming conventions for the names of the data sets. Install steps that discuss permission bits and the "sticky bit" are related to OMVS file security itself. Follow these steps as described. Your site can run web server with optional functions. The first is running the web server in scalable server mode to support WLM and the other is allowing the web server access to SMF.

6. 7.

3­40

z/OS and OS/390 Security Cookbook

WebSphere Application Server for z/OS and OS/390

To support WLM, the web sever needs access to the FACILITY resources BPX.WLMSERVER and MVSADMIN.WLM.POLICY. Do the following in eTrust CA-ACF2 to enable this: Add the following rule entry to the BPX FACILITY resource rule:

WLMSERVER UID(websrv_uid) SERVICE(READ) ALLOW

Create the following MVSADMID FACILITY rule:

SET RESOURCE(FAC) COMPILE $KEY(MVSADMIN) TYPE(FAC) WLM.POLICY UID(webserv_uid) SERVICE(READ,UPDATE) ALLOW STORE

To support access to SMF, add the following rule entry to the BPX FACILITY resource rule:

SMF UID(websrv_uid) SERVICE(READ) ALLOW

If the FACILITY class resources were made resident via the GSO INFODIR record, enter the following command to activate any changes:

F ACF2,REBUID(FAC)

WebSphere Application Server for z/OS and OS/390

The WebSphere Application Server for z/OS, originally known as the Lotus Domino Go Webserver (DGW), and also known as the OS/390 Internet Connection Security Server, is an IBM component that lets the MVS mainframe act as an Internet Web server. This component is installed and managed as a USS application. WebSphere for z/OS supports access to resources by clients and servers in a distributed network. Part of your security strategy should be to determine how to control access to these resources and prevent inadvertent or malicious destruction of the system or data. These are the pieces in the distributed network that you must consider:

You must authorize servers to the base operating system services in z/OS or OS/390. These services include eTrust CA-ACF2 , database management, and transaction management. For the servers, you must distinguish between control regions and server regions. Control regions run authorized system code, so they are trusted. Server regions run application code and are given access to resources, so you should carefully consider the authorizations you give server regions. You must also distinguish between the level of authority given to run-time servers compared to your own application servers. For example, the System Management server needs the authority to start other servers, while your own application servers do not need this authority.

Implementing USS Applications in an eTrust CA-ACF2 Environment

3­41

WebSphere Application Server for z/OS and OS/390

You must authorize clients (users) to servers and objects within servers. The characteristics of each client requires special consideration: Is the client on the local system or is it remote? The security of the network becomes a consideration for remote clients. Will you allow unidentified (unauthenticated) clients to access the system? Some resources on your system might be intended for public access, while others must be protected. In order to access protected resources, clients must establish their identities and have authorization to use those resources. What kind of objects will the client access? Enterprise beans and CORBA objects have differing authorization mechanisms.

If you must protect resources, identifying who accesses those resources is critical. Thus, any security system requires client (user) identification, also known as authentication. In a distributed network supported by WebSphere for z/OS, clients can be accessing resources from: 1. 2. 3. 4. Within the same system as a server Within the same sysplex as the server Remote z/OS or OS/390 systems Heterogeneous systems, such as WebSphere on distributed platforms, CICS, or other CORBA-compliant systems.

Additionally, clients can request a service that requires a server to forward the request to another server. In such cases the system must handle delegation, the availability of the client identity for use by intermediate servers and target servers. Finally, in a distributed network, how do you ensure that messages being passed are confidential and have not been tampered? How do you ensure that clients are who they claim to be? How do you map network identities to z/OS or OS/390 identities? These issues are addressed by the following support in WebSphere for z/OS: 1. 2. 3. The use of SSL and digital certificates Kerberos Distributed Computing Environment (DCE)

Network security is not required for your initial installation and customization of WebSphere for z/OS. This information is provided to introduce you to WebSphere for z/OS security and allow you to make early planning decisions about system security. The following topics describe how WebSphere for z/OS supports security. The descriptions are organized under the following subtopics:

Authorization Checking User Identification, Authentication and Network Security

3­42

z/OS and OS/390 Security Cookbook

WebSphere Application Server for z/OS and OS/390

Authorization Checking

Each control region, server region, and client must have its own eTrust CA-ACF2 logonid (more about user identification and authentication later). When a request flows from a client to the server or from a server to a server, WebSphere for z/OS passes the user identity (client or server) with the request. Thus each request is performed on behalf of the user identity and the system checks to see if the user identity has the authority to make such a request. The following is an outline of the set up requirements for WebSphere. See ACFCSEC section for sample details of the set up information (the number below refers to the steps in ACFCSEC). 1. 2. 3. 4. 5. 6. 7. 8. 9. Define the basic logonids and group profiles. Define the IVP1 logonids and group profiles. Define the IVP2 logonids and group profiles. Define server access to the FACILITY PBX resources. Define the LOGSTRM class permissions for logonids writing to the error log stream. Define CBIND class resources access to allow a client to bind to a control region. Define access to the OPERCMDS class resources necessary to start and stop server jobs. Define access to the SOMDOBJS class resources to allow access to installation-defined methods. Define access to the EJBROLES class resources to allow access to installation-defined methods.

10. Define access to the FACILITY class resource IRR.RDCEUID for DCE and IRR.RUSERMAP for KERBEROS. For information regarding DCE or KERBEROS set up see the Defining DCE under eTrust CA-ACF2 and Kerberos section in this guide. 11. Define access to the FACILITY class resource IMSXCF.OTMACI for each server permitted to use the OTMA callable interface. 12. Define access to the SURROGAT class resources logonid.DFHEXCI to servers using CICS EXCI PAALRM. 13. Define server SSL controls to create the certificates, keyrings, and rules needed to support SSL connections between servers. 14. Define client SSL controls to create the IVP client certificates and keyrings needed to run the clients using an SSL connection.

Implementing USS Applications in an eTrust CA-ACF2 Environment

3­43

WebSphere Application Server for z/OS and OS/390

Level of Trust and Authority for Regions

Region Control region Level of Trust and Access Authority Contains WebSphere for z/OS system code.Trusted, deals with multiple users. Greater authorization. Runs APF-authorized. Contains application code. Untrusted. Other than having authorization to get work and to attach to data stores, should run unauthorized.

Server region

Regarding the WebSphere for z/OS run-time servers, the rule of thumb is to give less authority to the Daemon and Naming Server, and greater authority to the System Management Server, as explained in the following table: Run-time Server Daemon Server Region Control Required Authorities STC, access WLM services, access to DNS, OPERCMDS access to START, STOP, CANCEL, FORCE & MODIFY other services STC, access to WLM services STC, READ auth to the SERVER class, DBADM for the LDAP Database STC STC, Read auth. To the SERVER class, OPERCMDS access to START, STOP, CANCEL FORCE, and MODIFY other services STC STC, READ Auth. To the SERVER Class, DBADM for the LDAP database

Naming Server Naming Server Sys. Mgmt. Server Sys. Mgmt. Server

Control Server Control Server

Interface Repository Interface Repository

Control Server

Assigning authorities to WebSphere for z/OS run-time server control and server regions

Remember to protect the RRS log streams. Protect the WebSphere for z/OS environment files, especially if they contain passwords.

3­44

z/OS and OS/390 Security Cookbook

WebSphere Application Server for z/OS and OS/390

User Identification, Authentication and Network Security

LDAP Access Control Lists (ACLs) LDAP uses access control lists to control client access to naming services. Usually, you set up a general ANYBODY user identity with read access to the LDAP name space, allowing any client to access naming services. CBIND Class You can use the CBIND class to restrict a client's ability to access servers. There are two types of resources that WebSphere for z/OS uses in the CBIND class:

One that controls whether a local or remote client can access servers. The name of the resource has this form:

CB.BIND.server_name

where server_name is the name of the server.

One that controls whether a client can use objects in a server. The name of the resource has this form:

CB.server_name

where server_name is the name of the server. Note: When you add a new server, you must authorize all systems management logonids (for example, CBADMIN) to have read access to the CB.server_name and

CB.BIND.server_name resources.

Example: To allow CBADMIN needs read authority to the CB.BBOASR1 and CB.BIND.BBOASR1 resources, add the following to the CBIND class CB resource rule:

BBOASR1 UID(cbadmin_uid) SERVICE(READ) ALLOW BIND.BBOASR1 UID(cbadmin_uid) SERVICE(READ) ALLOW

The CBIND class defaults to a generic type code of SAF. It is recommended that a GSO CLASMAP record be added to change this to a site selected resource unique to the CBIND class such as CBI. The following shows how the suggested change example would be coded:

SET CONTROL(GSO) INSERT CLASMAP.cbind RESOURCE(CBIND) RSRCTYPE(cbi) ENTITYLN(41)

To activate the change immediately, issue the following command:

F, ACF2,REFRESH(CLASMAP)

Implementing USS Applications in an eTrust CA-ACF2 Environment

3­45

WebSphere Application Server for z/OS and OS/390

EJBROLE and GEJBROLE Classes Access to an enterprise bean can be controlled through security roles that are the group of permissions that a user must have to successfully use an application. Using a Java method called isCallerInRole, the application programmer or systems administrator specifies the security role names that are allowed to access a particular bean. Only users having access to these security role names are granted access to the bean. Execution of isCallerInRole in an OS/390 or z/OS environment causes invokes IRRPNL00 profile name list service routine. This routine returns a list of all of the Java security roles that a user has access to. eTrust CA-ACF2 fully supports this use of the IRRPNL00 routine through the use of EJB generalized resource rules. (By default, the internal CLASMAP record maps the EJBROLE resource class to an EJB type code.) When SAF processing passes the IRRPNL00 routine request to external security, eTrust CA-ACF2 processes each EJB resource rule to determine if the specified user has access to each defined role. After processing all of the EJB rules, eTrust CA-ACF2 passes a list of all allowed roles for use by the Java isCallerInRole method, which then allows or prevents access to the bean based on this list. To set up the external security environment, do the following: 1. Identify the security roles specified by your application programmers or OEM/ISV providers and the users that should have access to each role. The role name used in the EJB resource rules is the security role specified in the jar file or for the application. It can be up to 256 characters in length and can contain mixed case characters but can not contain blanks. Write and store EJB resource rules for each security role. There are some special guidelines that apply to EJBROLE resource rules as follows: ­ Since the purpose of the EJB rules is to provide a specific list of allowable roles for each user, each defined role in your environment must have a specific rule for it. This means that masking is not allowed in the resource name of an EJB rule. EJBROLE names use mixed case names. The eTrust CA-ACF2 resource rules now support mixed case resource names. To identify this, the resource class is designated as mixed by using the MIXED operand in the appropriate CLASMAP record. The SHOW CLASMAP output now indicates that MIXED operand is set on by placing a YES in the column labeled MIXED. Once the MIXED keyword is set on, you can use mixed case in the $KEY, the $PREFIX, the $USERDATA, the resource name, and the NEXTKEY parameter. Ensure that the administrative platform used for processing the EJB rules supports the entry and display of mixed case.

2.

­

3­46

z/OS and OS/390 Security Cookbook

WebSphere Application Server for z/OS and OS/390

­

EJBROLE processing can be used to retrieve data for use in an application. To access the APPLDATA, the application performs a SAF EXTRACT call. In an eTrust CA-ACF2 environment, the APPLDATA is stored in the $USERDATA control card of the EJBROLE resource rule. The value placed in the $USERDATA is returned as APPLDATA in response to the EXTRACT call. The value in the $USERDATA can be mixed case.

3.

EJB resource rules must be globally resident by means of a resident directory so that eTrust CA-ACF2 can process them. To accomplish this, enter the following commands:

SET CONTROL(GSO) CHANGE INFODIR TYPES(R-REJB)

4.

When a resident resource rule is created or changed, the directory for it must be rebuilt through the following command:

F ACF2,REBUILD(EJB)

5.

Example: The ACCOUNT bean is an isCallerInRole Java method coded to allow access only by those users having access to the accounting.clerk and the accounting.manager security roles. The following resource rule might be written to accomplish this:

COMPILE $KEY(ACCOUNTING) TYPE(EJB) CLERK UID(uid_string_clerk) ALLOW MANAGER UID(uid_string_manager) ALLOW END STORE

For additional information on the use of EJBROLE security in WebSphere Application Server environment, consult: WebSphere Application Server for z/OS and OS/390: Installation and Customization WebSphere Application Server for z/OS and OS/390: Writing Enterprise Beans in WebSphere. SOMDOBJS Class The application assembler must assign method permissions to the bean or method using the Application Assembly Tool.

Define the roles relevant to the application. Once defined, the role can be assigned to access an application (as a method permission). After the application assembly is complete, the application must be reinstalled using the Administration application.

Implementing USS Applications in an eTrust CA-ACF2 Environment

3­47

WebSphere Application Server for z/OS and OS/390

Use the SOMDOBJS class in eTrust CA-ACF2 to control a client's access to CORBA objects. Resource names in SOMDOBJS have the form:

server_name.home.method

Where server_name is the server name. It must be 8 characters or less. home is the home name. It must be 192 characters or less. method is the method name. It can be up to the length of the remainder of 244 minus the sum of the server and home name lengths. Example: If the server name is 8 characters, and the home name is128 characters, the method name can be 108 (244 - (8 + 128)). If a method is protected by SOMDOBJS, a client must have READ or UPDATE authority depending on the type of access being attempted. If a client program is using the method to update an attribute of an object, give the client UPDATE authorization for the method; if a client program is using the method to read an attribute of an object, give the client READ authorization for the method. All names are folded into uppercase characters, regardless of how you enter them. Thus, there is no difference between MY_server.MY_home.MY_method and MY_SERVER.MY_HOME.MY_METHOD. In addition to the SOMDOBJS definitions, you must specify method-level access checking through the WebSphere for z/OS Administration application. Check the box for method-level access checking when you define your application.s container.

Resource Managers

Resource managers such as DB2, IMS, and CICS have implemented their own resource controls, which control the ability of clients to access resources. When resource controls are used by DB2, use eTrust CA-ACF2 for DB2 or issue the relevant DB2 GRANT statements. Access to OTMA for IMS access is through the FACility class resource IMSXCF.OTMACI. Access to EXCI for CICS is through the SURROGAT class resource logonid.DFHEXCI. You can control access to data sets through the eTrust CA-ACF2 access rules class and HFS files through file permissions or the HFS resource rules.

3­48

z/OS and OS/390 Security Cookbook

WebSphere Application Server for z/OS and OS/390

Protection and Protect Directives

The sample config file provided for WebSphere for z/OS includes two elements that have similar names that relate to how security is implemented for files. One is called Protection directives and the other is called Protect directives. Protection directives tell the HTTP Server how to secure a particular file. The following example is for a protection directive called PROTECTED_INFO and indicates, among other things, that a certificate is required when accessing files protected with this directive.

Protection PROTECTED_INFO { ServerId Security_Administration AuthType Basic PasswdFile %%SAF%% Userid %%CERTIF%% Mask anybody }

Protect directives associate a file or group of files with a specific Protection directive. The following example indicates anyone accessing files in the /secret directory through the Http Server will fall under the PROTECTED_INFO Protection directive and must supply a certificate that is trusted by ACF2.

Protect /secret/* PROTECTED_INFO

Protect directives identify specific directories or files that are accessed by different users than the default. The default Protection directive is PUBLIC. For more information regarding this server configuration see the HTTP Server Planning, Installing and Using Guide.

Prerequisites

To use the WebSphere application server in an eTrust CA-ACF2 environment, started task (STC) validation must be active.

Installation Steps

WebSphere for z/OS documentation points sites to a utility called BBOCBRAC that can be used to generate the set up required for external security but only assumes a RACF environment. eTrust CA-ACF2 support has put together an eTrust CA-ACF2 equivalent batch job. Careful review of the job is necessary because the local site must supply variables unique to their environment as well as the fact that some of the required updates may already be in place by your site. For your convenience a version of the ACFCSEC sample JCL is provided here. See the ACFCSEC member in the eTrust CA-ACF2 SAMPJCL dataset for the actual JCL.

Implementing USS Applications in an eTrust CA-ACF2 Environment

3­49

WebSphere Application Server for z/OS and OS/390

ACFCSEC

//ACFCSEC JOB 40100000,X,CLASS=A,MSGCLASS=X,NOTIFY=HUNRO03 //*============================================================= //* //* A C F C S E C //* //*============================================================= //* //* LICENSE: THIS CODE IS PART OF THE CA-ACF2 SYSTEM, //* A LICENSED PROGRAM PRODUCT OF COMPUTER ASSOCIATES //* INTERNATIONAL, INC. //* //*============================================================= //* //* The following material has been taken from the "CA-ACF2 For //* OS/390 Security Cookbook". //* //* This document may be found at the following web site: //* //* http://esupport.ca.com //* //* This is a sample ACFBATCH job which provides all the CA-ACF2 //* commands needed for the setup of IBM OS/390 Component Broker 4.0 //* in a CA-ACF2 secured environment. This job replicates options //* defined in IBM JOB in SBBOJCL(BBOCBRAC). //* //* The intent of the job is to get IBM OS/390 Component Broker 4.0 //* up and running in a test environment. Please review the //* CA-ACF2 RV Report as an aid to taylor the rules needed at your //* site. //* //* NOTES: //* -----//* 1. Please read through the comments carefully before //* running this job to determine what commands will be //* needed to setup your own customized environment. //* //* 2. If this is an migration from CB release 3.02 to //* CB 4.0 comment out steps 1 and 2. //* //* 3. All steps except for the first three, have been coded //* with PGM=IEFBR14. If you want to perform this step //* change this to PGM=IKJEFT01. Update passwords as required. //* //* 4. If you did not use default proc names, update the //* appropriate logonid definitions. //* //* 5. All steps should finish with a return code of zero. //* //* 6. Please review the results of this job carefully. //* //* This batch job is provided for your convenience. //* //*============================================================= //* Step 1 - Define Basic logonids and groups //*============================================================= //CB40BASE EXEC PGM=IKJEFT01,REGION=0K //SYSPRINT DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSTSIN DD *

3­50

z/OS and OS/390 Security Cookbook

WebSphere Application Server for z/OS and OS/390

ACF SET PROFILE(GROUP) DIV(OMVS) INSERT CBCTL1 GID(2211) INSERT CBSR1 GID(2201) INSERT CBCFG1 GID(2300) INSERT CBCLGP GID(2202) INSERT CBADMGP GID(2203) SET LID INSERT CBGUEST INSERT STCRACF INSERT CBADMIN INSERT BB0DMN INSERT BB0SMS INSERT BB0SMSS INSERT BB0NM INSERT BB0NMS INSERT BB0IR INSERT BB0IRS NAME(CB390 GUEST) GROUP(CBCLGP) UID(2102) HOME(/tmp) OMVSPGM(/bin/sh) PASSWORD(CBGUEST) NAME(CB390 TRACE WRITER) GROUP(SYS1) STC NAME(CB390 ADMINISTRATOR) GROUP(CBADMGP) PASSWORD(CBADMIN) NOEXP-PWD UID(2103) HOME(/tmp) OMVSPGM(/bin/sh) NAME(CB390 DAEMON CR) GROUP(CBCTL1) STC MUSASS UID(2111) HOME(/tmp) OMVSPGM(/bin/sh) NAME(CB390 SYSMGT CR) GROUP(CBCTL1) STC MUSASS UID(2112) HOME(/tmp) OMVSPGM(/bin/sh) NAME(CB390 SYSMGT SR) GROUP(CBSR1) STC MUSASS UID(2104) HOME(/tmp) OMVSPGM(/bin/sh) NAME(CB390 NAMING CR) GROUP(CBCTL1) STC MUSASS UID(2113) HOME(/tmp) OMVSPGM(/bin/sh) NAME(CB390 NAMING SR) GROUP(CBSR1) STC MUSASS UID(2105) HOME(/tmp) OMVSPGM(/bin/sh) NAME(CB390 INTFRP CR) GROUP(CBCTL1) STC MUSASS UID(2114) HOME(/tmp) OMVSPGM(/bin/sh) NAME(CB390 INTFRP SR) GROUP(CBSR1) STC MUSASS UID(2106) HOME(/tmp) OMVSPGM(/bin/sh)

-

F ACF2,REBUILD(USR),CLASS(P) F ACF2,REBUILD(GRP),CLASS(P) F ACF2,OMVS END //*============================================================= //* Step 2 - Define IVP1 userids and groups //*============================================================= //CB40IVP1 EXEC PGM=IKJEFT01,REGION=0K //SYSPRINT DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSTSIN DD * ACF SET PROFILE(GROUP) DIV(OMVS) INSERT CBASR1 GID(2205) INSERT CBIVPGP GID(2209) SET LID INSERT CBACRU1 INSERT CBASRU1 INSERT CBIVP NAME(CB390 IVP1 CR) GROUP(CBCTL1) STC UID(2107) HOME(/tmp) OMVSPGM(/bin/sh) NAME(CB390 IVP1 SR) GROUP(CBASR1) STC UID(2110) HOME(/tmp) OMVSPGM(/bin/sh) NAME(CB390 IVP1 USER) GROUP(CBIVPGP) PASSWORD(CBIVP) NOEXP-PWD UID(2109) HOME(/tmp) OMVSPGM(/bin/sh)

F ACF2,REBUILD(USR),CLASS(P) F ACF2,REBUILD(GRP),CLASS(P) F ACF2,OMVS END //*============================================================= //* Step 3 - Define IVP2 userids and groups //*=============================================================

Implementing USS Applications in an eTrust CA-ACF2 Environment

3­51

WebSphere Application Server for z/OS and OS/390

//CB40IVP2 EXEC PGM=IKJEFT01,REGION=0K //SYSPRINT DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSTSIN DD * ACF SET PROFILE(GROUP) DIV(OMVS) INSERT CBASR2 GID(2216) INSERT CBIVPGP2 GID(2217) SET LID INSERT CBACRU2 INSERT CBASRU2 INSERT CBIVP2 NAME(CB390 IVP2 CR) GROUP(CBCTL1) STC UID(2115) HOME(/tmp) OMVSPGM(/bin/sh) NAME(CB390 IVP2 SR) GROUP(CBASR2) STC UID(2116) HOME(/tmp) OMVSPGM(/bin/sh) NAME(CB390 IVP2 USER) GROUP(CBIVPGP2) PASSWORD(CBIVP2) NOEXP-PWD UID(2117) HOME(/tmp) OMVSPGM(/bin/sh)

F ACF2,REBUILD(USR),CLASS(P) F ACF2,REBUILD(GRP),CLASS(P) F ACF2,OMVS END //*============================================================= //* Step 4 - Define server access to BPX resources //*------------------------------------------------------------//* There are several other "BPX.xxxxxxxx" resources of the //* FACILITY class which can be controlled via ACF2 resource //* rules. By default CA-ACF2 will deny access to any of these //* resources. A rule MUST be written to grant access. //* //* For each rule line below the UID() parameter must be modified //* to match local standards for the userid specified in lower //* case to be properly allowed access. //* //* NOTE: //* 1. This step will update the existing resource rule, //* if one exists on your system. This is an example of //* what may need to be added to your existing rule(s). //* //* 2. Change the 'DSN7' rule key to match the name of your //* DB2 sub-system. //* //* 3. These changes MUST be resident to be used. The //* commands at the end of this step will make the //* changes active. //* //*============================================================= //CB40BPX EXEC PGM=IEFBR14,REGION=0K //SYSPRINT DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSTSIN DD * ACF SET RESOURCE(FAC) RECKEY BPX ADD(DAEMON UID(BB0*) SERVICE(READ) ALLOW) RECKEY BPX ADD(DAEMON UID(CBACRU*) SERVICE(READ) ALLOW) RECKEY BPX ADD(DAEMON UID(CBASRU*) SERVICE(READ) ALLOW) RECKEY BPX ADD(SERVER UID(BB0*) SERVICE(READ) ALLOW) RECKEY BPX ADD(SERVER UID(CBACRU*) SERVICE(READ) ALLOW) RECKEY BPX ADD(SERVER UID(CBASRU*) SERVICE(READ) ALLOW)

3­52

z/OS and OS/390 Security Cookbook

WebSphere Application Server for z/OS and OS/390

SET RESOURCE(SRV) RECKEY CB ADD(-.CBNAMING UID(*) SERVICE(READ) ALLOW) RECKEY CB ADD(-.CBSYSMGT UID(*) SERVICE(READ) ALLOW) RECKEY CB ADD(-.CBINTFRP UID(*) SERVICE(READ) ALLOW) RECKEY CB ADD(-.BBOASR1 UID(*) SERVICE(READ) ALLOW) RECKEY CB ADD(-.BBOASR2 UID(*) SERVICE(READ) ALLOW) SET RESOURCE(SAF) RECKEY DSN7 ADD(RRSAF UID(*CBCTL1) SERVICE(READ) ALLOW) RECKEY DSN7 ADD(RRSAF UID(*CBSR1) SERVICE(READ) ALLOW) RECKEY DSN7 ADD(RRSAF UID(*CBASR1) SERVICE(READ) ALLOW) RECKEY DSN7 ADD(RRSAF UID(*CBASR2) SERVICE(READ) ALLOW) RECKEY DSN7 ADD(RRSAF UID(*ILDAPSV) SERVICE(READ) ALLOW) RECKEY BBOASR1 ADD(- UID(*CVIVPGP) ALLOW) F ACF2,REBUILD(FAC) END //*============================================================= //* Step 5 - Define LOGSTRM permissions //*------------------------------------------------------------//* The resource rules provided here will allow generic access //* to these resources while logging all services that use //* them. To secure these resources use the CA-ACF2 RV report //* to determine service access requirements. //* //* NOTES: //* 1. This step will update the existing resource rule, //* if one exists on your system. This is an example of //* what may need to be added to your existing rule(s). //* //* 2. These changes MUST be resident to be used. The //* commands at the end of this step will make the //* changes active. //* //*============================================================= //CB40LOG EXEC PGM=IEFBR14,REGION=0K //SYSPRINT DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSTSIN DD * ACF SET RESOURCE(LOG) RECKEY WAS add(ERROR.LOG UID(*) SERVICE(UPDATE) LOG) RECKEY WAS add(ERROR.LOG UID(*) SERVICE(READ) ALLOW) SET CONTROL(GSO) CHANGE INFODIR TYPES(R-RLOG) ADD F ACF2,REFRESH(INFODIR) F ACF2,REBUILD(LOG) END //*============================================================= //* Step 6 - Define Server control permissions //*------------------------------------------------------------//* The resource rules provided here will allow generic access //* to these resources while logging all services that use //* them. To secure these resources use the CA-ACF2 RV report //* to determine service access requirements. //* //* NOTES: //* 1. This step will update the existing resource rule, //* if one exists on your system. This is an example of //* what may need to be added to your existing rule(s). //*

Implementing USS Applications in an eTrust CA-ACF2 Environment

3­53

WebSphere Application Server for z/OS and OS/390

//* 2. These changes MUST be resident to be used. The //* commands at the end of this step will make the //* changes active. //* //*============================================================= //CB40BIND EXEC PGM=IEFBR14,REGION=0K //SYSPRINT DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSTSIN DD * ACF SET RESOURCE(CBI) RECKEY CB add(BIND.- UID(*) SERVICE(DELETE) LOG) RECKEY CB add(- UID(*) SERVICE(read) LOG) SET CONTROL(GSO) CHANGE INFODIR TYPES(R-RCBI) ADD F ACF2,REFRESH(INFODIR) F ACF2,REBUILD(CBI) END //*============================================================= //* The following are examples //*============================================================= //*============================================================= //* Step 7 - Enable console commands //*------------------------------------------------------------//* The resource rules provided here will allow generic access //* to these resources while logging all services that use //* them. To secure these resources use the CA-ACF2 RV report //* to determine service access requirements. //* //* NOTES: //* 1. This step will overwrite the existing resource rule, //* if one exists on your system. This is an example of //* what may need to be added to your existing rule(s). //* //* 2. These changes MUST be resident to be used. The //* commands at the end of this step will make the //* changes active. //* //*============================================================= //CB40OPER EXEC PGM=IEFBR14,REGION=0K //SYSPRINT DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSTSIN DD * ACF SET RESOURCE(OPR) RECKEY MVS ADD(- UID(*) SERVICE(UPDATE) LOG) F ACF2,REFRESH(INFODIR) F ACF2,REBUILD(OPR) END //*============================================================= //* Step 8 - Define Method Level Access Controls //*------------------------------------------------------------//* The resource rules provided here will allow generic access //* to these resources while logging all services that use //* them. To secure these resources use the CA-ACF2 RV report //* to determine service access requirements. //* //* NOTES: //* 1. This step will overwrite the existing resource rule, //* if one exists on your system. This is an example of //* what may need to be added to your existing rule(s).

3­54

z/OS and OS/390 Security Cookbook

WebSphere Application Server for z/OS and OS/390

//* //* 2. These changes MUST be resident to be used. The //* commands at the end of this step will make the //* changes active. //* //*============================================================= //CB40MLA1 EXEC PGM=IEFBR14,REGION=0K //SYSPRINT DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSTSIN DD * ACF SET RESOURCE(SAF) COMPILE * $KEY(SOMDOBJS) TYPE(SAF) UID(*) SERVICE(READ) LOG STORE SET CONTROL(GSO) CHANGE INFODIR TYPES(R-RSAF) ADD F ACF2,REFRESH(INFODIR) F ACF2,REBUILD(SAF) END //*============================================================= //* Step 9 - Define Method Level Access Controls - EJBRoles //*------------------------------------------------------------//* The resource rules provided here will allow generic access //* to these resources while logging all services that use //* them. To secure these resources use the CA-ACF2 RV report //* to determine service access requirements. //* //* NOTES: //* 1. This step will update the existing resource rule, //* if one exists on your system. This is an example of //* what may need to be added to your existing rule(s). //* //* 2. These changes MUST be resident to be used. The //* commands at the end of this step will make the //* changes active. //* //*============================================================= //CB40MLA2 EXEC PGM=IEFBR14,REGION=0K //SYSPRINT DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSTSIN DD * ACF SET RESOURCE(EJB) RECKEY EJBInstallTestRole ADD(UID(*) SERVICE(READ) LOG) SET CONTROL(GSO) CHANGE INFODIR TYPES(R-REJB) ADD F ACF2,REFRESH(INFODIR) F ACF2,REBUILD(EJB) END //*============================================================= //* Step 10 - Define DCE and Kerberos Controls //*------------------------------------------------------------//* The resource rules provided here will allow generic access //* to these resources while logging all services that use //* them. To secure these resources use the CA-ACF2 RV report //* to determine service access requirements. //*

Implementing USS Applications in an eTrust CA-ACF2 Environment

3­55

WebSphere Application Server for z/OS and OS/390

//* NOTES: //* 1. This step will update the existing resource rule, //* if one exists on your system. This is an example of //* what may need to be added to your existing rule(s). //* //* 2. These changes MUST be resident to be used. The //* commands at the end of this step will make the //* changes active. //* //*============================================================= //CB40DCE EXEC PGM=IEFBR14,REGION=0K //SYSPRINT DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSTSIN DD * ACF SET RESOURCE(FAC) RECKEY IRR ADD(- UID(*) SERVICE(READ) LOG) SET CONTROL(GSO) CHANGE INFODIR TYPES(R-RFAC) ADD F ACF2,REFRESH(INFODIR) F ACF2,REBUILD(FAC) END //*============================================================= //* Step 11 - Define IMS OTMA PAA Usage //*------------------------------------------------------------//* The resource rules provided here will allow generic access //* to these resources while logging all services that use //* them. To secure these resources use the CA-ACF2 RV report //* to determine service access requirements. //* //* NOTES: //* 1. This step will overwrite the existing resource rule, //* if one exists on your system. This is an example of //* what may need to be added to your existing rule(s). //* //* 2. These changes MUST be resident to be used. The //* commands at the end of this step will make the //* changes active. //* //*============================================================= //CB40IMS EXEC PGM=IEFBR14,REGION=0K //SYSPRINT DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSTSIN DD * ACF SET RESOURCE(FAC) COMPILE * $KEY(IMSXCF) TYPE(FAC) UID(*) SERVICE(READ) LOG STORE SET CONTROL(GSO) CHANGE INFODIR TYPES(R-RFAC) ADD F ACF2,REFRESH(INFODIR) F ACF2,REBUILD(FAC) END

3­56

z/OS and OS/390 Security Cookbook

WebSphere Application Server for z/OS and OS/390

//*============================================================= //* Step 12 - Define CICS EXCI PAA Usage //*------------------------------------------------------------//* The resource rules provided here will allow generic access //* to these resources while logging all services that use //* them. To secure these resources use the CA-ACF2 RV report //* to determine service access requirements. //* //* NOTES: //* 1. This step will overwrite the existing resource rule, //* if one exists on your system. This is an example of //* what may need to be added to your existing rule(s). //* //* 2. These changes MUST be resident to be used. The //* commands at the end of this step will make the //* changes active. //* //*============================================================= //CB40CICS EXEC PGM=IEFBR14,REGION=0K //SYSPRINT DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSTSIN DD * ACF SET RESOURCE(SUR) COMPILE * $KEY(CICS.region_name) TYPE(SUR) USERid.DFHEXCI UID(*) SERVICE(READ) LOG STORE SET CONTROL(GSO) CHANGE INFODIR TYPES(R-RSUR) ADD F ACF2,REFRESH(INFODIR) F ACF2,REBUILD(SUR) END //*============================================================= //* Step 13 - Define Server SSL Controls //*------------------------------------------------------------//* This step creates the certificates, keyrings, and rules //* needed to support SSL connections between the servers. //* //* NOTES: //* 1. This step will update the existing resource rule, //* if one exists on your system. This is an example of //* what may need to be added to your existing rule(s). //* //* 2. This step will create certificates and keyrings. //* If the certificate or keyring exist it will use //* the one previously defined to the database. //* //* 3. Change 'ILDAPSV' to match the userid assigned //* to IBM LDAP Server. //* //* 4. These changes MUST be resident to be used. The //* commands at the end of this step will make the //* changes active. //* //*============================================================= //CB40SSSL EXEC PGM=IEFBR14,REGION=0K //SYSPRINT DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSTSIN DD * ACF

Implementing USS Applications in an eTrust CA-ACF2 Environment

3­57

WebSphere Application Server for z/OS and OS/390

SET RESOURCE(FAC) RECKEY IRR ADD(DIGTCERT.LIST UID(*) SERVICE(READ) LOG) RECKEY IRR ADD(DIGTCERT.LISTRING UID(*) SERVICE(READ) LOG) SET PROFILE(USER) DIV(CERTDATA) GENCERT CERTAUTH.WASCA SUBJSDN(cn='WAS CertAuth' c=US) LABEL(WAS TestCertAuth) TRUST GENCERT CBNAMCR1 SUBJSDN(cn='WAS z/os Name Server' o=ibm) LABEL(CBNAMING) SIGNWITH(CERTAUTH LABEL(WAS TestCertAuth)) GENCERT CBACRU1 SUBJSDN(cn='WAS z/os IVP1 Server' o=ibm) LABEL(BBOASR1) SIGNWITH(CERTAUTH LABEL(WAS TestCertAuth)) GENCERT CBACRU2 SUBJSDN(cn='WAS z/os IVP2 Server' o=ibm) LABEL(BBOASR2) SIGNWITH(CERTAUTH LABEL(WAS TestCertAuth)) GENCERT ILDAPSV SUBJSDN(cn='LDAP Server' o=ibm) LABEL(IBMLDAP) SIGNWITH(CERTAUTH LABEL(WAS TestCertAuth)) SET PROFILE(USER) DIV(KEYRING) INSERT CBNAMCR1 RINGNAME(CBServer) INSERT CBACRU1 RINGNAME(CBServer) INSERT CBACRU2 RINGNAME(CBKeyring) INSERT ILDAPSV RINGNAME(IBMLDAP) CONNECT CERTDATA(CERTAUTH.WASCA) KEYRING(CBNAMCR1) CONNECT CERTDATA(CBNAMCR1) KEYRING(CBNAMCR1) RINGNAME(CBServer) DEFAULT CONNECT CERTDATA(CERTAUTH.WASCA) KEYRING(CBACRU1) CONNECT CERTDATA(CBACRU1) KEYRING(CBACRU1) RINGNAME(CBServer) DEFAULT CONNECT CERTDATA(CERTAUTH.WASCA) KEYRING(CBACRU2) CONNECT CERTDATA(CBACRU2) KEYRING(CBACRU2) RINGNAME(CBKeyring) DEFAULT CONNECT CERTDATA(CERTAUTH.WASCA) KEYRING(ILDAPSV) CONNECT CERTDATA(ILDAPSV) KEYRING(ILDAPSV) RINGNAME(IBMLDAP) DEFAULT SET CONTROL(GSO) CHANGE INFODIR TYPES(R-RFAC) ADD F ACF2,REFRESH(INFODIR) F ACF2,REBUILD(FAC) F ACF2,REBUILD(USR),class(p) F ACF2,OMVS END //*============================================================= //* Step 14 - Define Client SSL Controls //*------------------------------------------------------------//* This step creates the IVP client certificates and rings //* needed to run the clients using an SSL connection. //* The CERTMAP will allow remote clients with the proper //* certificate subject DN access to the IVP userid. //* //* NOTES: //* 1. This step will create certificates and keyrings. //* If the certificate or keyring exist it will use //* the one previously defined to the database. //* //* 2. These changes MUST be resident to be used. The //* commands at the end of this step will make the //* changes active. //* //*============================================================= //CB40CSSL EXEC PGM=IEFBR14,REGION=0K //SYSPRINT DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSTSIN DD *

3­58

z/OS and OS/390 Security Cookbook

WebSphere Application Server for z/OS and OS/390

ACF SET PROFILE(USER) DIV(CERTDATA) GENCERT CBIVP SUBJSDN(cn='Unauth IVP1 User' o=IVPTest) LABEL(CBIVP) SIGNWITH(CERTAUTH LABEL(WAS TestCertAuth)) GENCERT CBIVP2 SUBJSDN(cn='Unauth IVP2 User' o=IVPTest) LABEL(CBIVP2) SIGNWITH(CERTAUTH LABEL(WAS TestCertAuth)) SET PROFILE(USER) DIV(KEYRING) INSERT CBIVP RINGNAME(CBKeyring) INSERT CBIVP2 RINGNAME(CBKeyring) CONNECT CERTDATA(CERTAUTH.WASCA) KEYRING(CBIVP) RINGNAME(CBKeyring) CONNECT CERTDATA(CBIVP) KEYRING(CBIVP) RINGNAME(CBKeyring) DEFAULT USAGE(CERTAUTH) CONNECT CERTDATA(CBIVP) KEYRING(CBNAMCR1) RINGNAME(CBKeyring) CONNECT CERTDATA(CBIVP) KEYRING(CBACRU1) RINGNAME(CBKeyring) CONNECT CERTDATA(CBIVP) KEYRING(CBACRU2) RINGNAME(CBKeyring) CONNECT CERTDATA(CERTAUTH.WASCA) KEYRING(CBIVP2) RINGNAME(CBKeyring) CONNECT CERTDATA(CBIVP2) KEYRING(CBIVP2) RINGNAME(CBKeyring) DEFAULT USAGE(CERTAUTH) CONNECT CERTDATA(CBIVP2) KEYRING(CBNAMCR1) RINGNAME(CBKeyring) CONNECT CERTDATA(CBIVP2) KEYRING(CBACRU1) RINGNAME(CBKeyring) CONNECT CERTDATA(CBIVP2) KEYRING(CBACRU2) RINGNAME(CBKeyring) SET CONTROL(GSO) INSERT CERTMAP.IVP SDNFILTR('O=IVPTest') label(Client CBIVP) TRUST USERID(CBIVP) F ACF2,REFRESH(INFODIR) F ACF2,REFRESH(CERTMAP) F ACF2,REBUILD(USR),class(p) F ACF2,OMVS END

Implementing USS Applications in an eTrust CA-ACF2 Environment

3­59

Chapter

4

Controlling Access to the Hierarchical File System

With Version 6.3 of eTrust CA-ACF2, there are two processes that a site can use to secure the Hierarchical File System (HFS). The first process is internal to USS and is based on a UNIX model of security. The second process is external security and uses standard eTrust CA-ACF2 security rules to secure the HFS. These processes are mutually exclusive, so your site must select which one to use.

Accessing a HFS Data Set from MVS

If you attempt to access a MVS data set that represents a hierarchical file system (HFS), through ISPF 3.2 or 3.4, it is possible that you will get an "OBTAIN failed" message. The extended message reads: "datasetname has unknown attributes, OBTAIN RC = 12 hex". This occurs if the HFS data set is not mounted to OMVS. This can occur on OS/390 2.7 and higher systems. When data set information is requested for an unmounted HFS data set, OS/390 and z/OS UNIX System Services will write information to the /tmp directory. If the user making the request does not have write access, the error message is displayed. To avoid this error, you must ensure that the public access permission for the /tmp directory is set to allow all access. It is suggested that the permission bits for the /tmp directory be set to 777 to allow all access. Note: Using UNIX System Services security with eTrust CA-ACF2 still requires that access be allowed using resource rules to the /tmp directory.

Controlling Access to the Hierarchical File System

4­1

Controlling HFS Using the UNIX Security Model

Controlling HFS Using the UNIX Security Model

OS/390 and z/OS USS files are organized in a hierarchy as in a UNIX system. All files are members of the directory. Each directory is a member of another directory at a higher level of the hierarchy. The highest level of the hierarchy is the root directory. Security for the file system directories and files is based on a UNIX model of security. Each file and directory is assigned an owning UID and an owning GID. This assignment is defined and saved in the file system, not in the external security product. Normally each file or directory saves the access permissions in the form of four octal numbers nnnn. The first position represents special access flags while the remaining three are the permission categories. The access flags include the sticky bit, the setuid on execution, and the setgid on execution. The other three positions represent the categories of users that can access each directory and file in the HFS. Based on this, users are divided in the following three categories:

The UID that owns the file The GID of the group that owns the file All other users defined to USS

Three different access levels (READ, WRITE, and EXECUTE) can be set for any of these three categories. For example, permissions can be defined so that the file owner gets READ and WRITE access, a member of the file's owning group gets only READ access, and everyone else is denied access. Under eTrust CA-ACF2, you must define a UID for each USS user and a GID for each group that accesses USS. You must also assign a default group in all USS userids and give the users access to any supplemental groups as needed. For more information about the Hierarchical File System and setting file permissions, see the following IBM guides:

OS/390 UNIX System Services User's Guide OS/390 UNIX System Services Planning

4­2

z/OS and OS/390 Security Cookbook

Processes that Affect HFS Security

Processes that Affect HFS Security

When using the UNIX security model, various options can affect the file validation process. The processes and their effect on file security or validation are described in this section.

Access Control Lists

Native HFS file security only allows for 3 sets of file permissions: the file owner, the owning group, and all others. Access Control Lists (ACL) provide more granular control over the HFS file system than native HFS security by allowing additional users and groups to be specified with their own file permission settings. To activate the use of ACLs in the validation process, the only requirement is to specify HFSACL in the GSO UNIXOPTS record. By default, ACLs are not active (NOHFSACL). To activate ACL, use the following ACF command:

SET CONTROL(GSO) CHANGE UNIXOPTS HFSACL

To activate the change, use the following Operator command:

F ACF2,REFRESH(UNIXOPTS)

ACLs are created, deleted, and maintained by using the USS command setfacl. Existing ACLs can be viewed by using the getfacl USS command. See the IBM z/OS 1.3 USS Command Reference manual for more information about these commands. ACLs can be created and maintained even if they are not active (UNIXOPTS NOHFSACL). In order for a user to issue the setfacl command they must be one of the following: 1. 2. 3. Owner of the file or directory Superuser Read access to UNIXPRIV resource SUPERUSER.FILESYS.CHANGEPERMS.

HFS FASTAUTH Checking

As of OS/390 V2R7, OMVS issues a SAF call at initialization. This SAF call checks to see if OMVS has access to the FACILITY resource BPX.SAFFASTPATH. If access is allowed, OMVS performs permission bit checking internally instead of calling the external security manager bypassing any audit trail of violations. This is referred to as FASTAUTH processing.

Controlling Access to the Hierarchical File System

4­3

Processes that Affect HFS Security

Add an entry to the BPX FACILITY rule as follows:

SAFFASTPATH UID(*) PREVENT

If you give the OMVS logonid the NON-CNCL privilege, the check will always get a zero return code, which activates the FASTAUTH processing. To circumvent this, you must insert the following SAFDEF record:

SET CONTROL(GSO) INSERT SAFDEF.OEFSTAUT FUNCRET(8) ID(OEFSTAUT) JOBNAME(OMVS) ­ MODE(IGNORE) RB(BPX-) ­ RACROUTE(REQUEST=AUTH CLASS=FACILITY ENTITY=BPX.SAFFASTPATH) REP

After creating the record, issue the following command to make it active:

F ACF2,REFRESH(ALL)

MOUNT NOSECURITY

With OS/390 V2R7, you now have the option to MOUNT a file system or part of a file system with or without SECURITY. The use of the MOUNT command requires superuser authority. If the file system is mounted with the NOSECURITY option, access checks are made by OMVS using system credentials instead of passing user credentials. OMVS treats system credentials like superusers so access will always be allowed. There are no indications in the mount messages that a file was mounted with the NOSECURITY option. Always review the BPXPRMxx member of parmlib to ensure that none of the file systems are being mounted NOSECURITY. Also, restrict access to the MOUNT command itself to minimize the potential for this being done.

Change Owner Command (CHOWN)

The CHOWN command allows the owner or a superuser to change a file's owner. With release 6.3 of eTrust CA-ACF2, the GSO UNIXOPTS record CHOWNRES parameter controls who can issue this command. CHOWNRES implements POSIX CHOWN RESTRICTED, which states that only a superuser can modify the owner UID of a file. If the option is turned off (NOCHOWNRES), it implements POSIX CHOWN UNRESTRICTED, which lets the current owner modify the owning UID of a file.

4­4

z/OS and OS/390 Security Cookbook

Program Control in the UNIX Environment

Program Control in the UNIX Environment

When the BPX.DAEMON and BPX.SERVER FACILITY resources are active, processing authorized functions, such as SETUID, requires that programs or executables be loaded from an authorized library. In an eTrust CA-ACF2 environment, these authorized data sets are any library in the LPA list, the APF list, the LINKLIST if the LINKLIST has been designated as APF authorized, or the GSO LINKLIST. If a program is loaded from the HFS or an MVS data set not on the approved lists, the TCBNCTL flag, referred to as the "dirty bit," is set. This results in authorized functions failing if attempted in the "dirty" environment. The TCBNCTL flag is only set in the eTrust CA-ACF2 environment if program control is activated. By default, this process is not active. To activate it, you must override the PROGMCHK SAFDEF, which is set to ignore. To override this SAFDEF, create the following SAFDEF:

SET CONTROL(GSO) INSERT SAFDEF.PROGMCHK ID(PROGMCHK) MODE(GLOBAL) REP RACROUTE(REQUEST=FASTAUTH REQSTOR=PROGMCHK SUBSYS=CONTENTS)

This SAFDEF activates validation for each program fetched. Before activating this SAFDEF, you must ensure that appropriate program rules are in place and that these rules are made resident through the INFODIR record. You can accomplish this by doing the following: 1. By default, the PROGRAM class resources are validated under a type code of PGM. If you wish to use a different type code, enter the following CLASMAP record:

SET CONTROL(GSO) INSERT CLASMAP.PROGRAM RESOURCE(PROGRAM) ENTITYLN(8) TYPE(typecode)

2.

The validation check for the PROGRAM class is done using a FASTAUTH call. This type of call requires that the resource rules be resident. If not already included in the INFODIR record, add it to this record by entering the following:

SET CONTROL(GSO) CHANGE INFODIR TYPES(R-RPGM)

Note: If you changed the default type code of PGM to another type code, replace the PGM in the above example with the type code that you assigned to the PROGRAM resource class. 3. Create the PGM type resource rules required to let users access the programs they are using. If you want to allow access to any program and set the environment similar to the one before program checking is activated, you can enter the following resource rule:

SET RESOURCE(PGM) COMPILE * $KEY(********) TYPE(PGM) UID(*) ALLOW

Controlling Access to the Hierarchical File System

4­5

Controlling HFS using CA SAF HFS Security

If you wish more specific controls, then write a rule for each program in your environment. 4. To activate all of the previously described steps, enter the following operator commands:

F ACF2,REFRESH(ALL) F ACF2,REBUILD(PGM)

When an executable or program is requested in an OMVS environment, OMVS finds the executable in the HFS and loads it from there unless the "sticky bit" is turned on. If the sticky bit is set on for the executable file, then OMVS uses normal MVS load processing. To turn the sticky bit on using the OMVS chmod command, a user must own the file or be a superuser. If an executable or a program is to be loaded directly from HFS then the "Program" extended attribute has to be set for the file in order for it to be considered a controlled program. This can be accomplished by using the OMVS extattr command, however, use of this command does require access to the BPX.FILEATTR.PROGCTL resource. To set up the rule to allows this, add the following ruleline to the BPX FACility resource rule:

FILEATTR.PROGCTL UID(chmod_user) ALLOW

Controlling HFS using CA SAF HFS Security

OS/390 and z/OS brings the MVS and UNIX operating systems together onto one hardware platform. Although some interoperability between MVS and UNIX exist, each environment retains its own distinct data structures and methods of access control. UNIX data is kept in a Hierarchical File System (HFS). From the UNIX perspective, the HFS contains many discrete data files. From the MVS perspective, the HFS is one data set and can only be controlled as one data set. In other words, MVS can control access to the entire file system, but not to the individual files within the HFS. HFS files are protected by file permission bit settings. These are set when the file owner creates the file. Centralized administration can only be performed by a superuser, a user privilege that grants much more authority than just security administration. MVS resources are protected by access and resource rules, which are usually set up in advance by security administrators. Security administrators can be scoped in a decentralized environment.

4­6

z/OS and OS/390 Security Cookbook

File Access Security

CA SAF HFS security overcomes the shortcomings of native UNIX security by providing single-point security access control, administration, and reporting for both MVS and UNIX resources. CA ENF services present access events to eTrust CA-ACF2 for validation. Administrators use familiar commands and rules to protect UNIX files and functions, restricting access based upon the eTrust CA-ACF2 UID-string instead of the UNIX UID or GID numbers. HFS access loggings and violations are reported in the standard eTrust CA-ACF2 reports. The following sections explain:

HFS File Access Security using resource rules Securing HFS Functions (system and file) Implementing CA SAF HFS Security The CA SAF HFS Rule Generation Utility The CA SAF HFS Security Modification Utility

File Access Security

When using CA SAF HFS security, native file permission bit security is bypassed, as well as the superuser authority to access any file. File access is validated by eTrust CA-ACF2 security using resource rules. All the benefits of resource rules can be utilized, including masking, NEXTKEY, scoping, %CHANGE, and reporting. Certain extensions are available that allow user directories to be defined and to allow users to maintain rules for their own files.

Path Name Translation

The structure of HFS path names presents a challenge to external security products. A path name can be up to 1023 characters in length, except when used in the JCL PATH= keyword where the limit is 255 characters. The path name is also case-sensitive and can contain special characters. To allow external security to validate HFS files, certain manipulation of path names is required. The benefits of having enhanced security and single-point administration certainly make file name translation acceptable. Before validation, all path names are truncated, if necessary, to 255 characters. An exit point is provided for use when file names reside in paths that are greater than 255 characters. Your site can use the exit to provide a meaningful name. See Exit Processing for more information.

Controlling Access to the Hierarchical File System

4­7

File Access Security

Path names are converted to upper case unless your site inserts a GSO CLASMAP record for the HFSSEC class that specifies the MIXED keyword to indicate that mixed case resource names are to be used. Use the SHOW CLASMAP subcommand of the ACF command to determine if the HFSSEC class specifies MIXED. See the CLASMAP GSO record documentation in the Administrator Guide for more information about the MIXED keyword. eTrust CA-ACF2 resource rule processing considers the period (.) character as a delimiter. This delimiter is used when writing extended resource rules, that is, to provide security for resource names of greater than forty characters. Path names, however, use the slash character as a delimiter. Before a file is validated, the path name will have all slash characters, with the exception of the first, translated into a period delimiter. Other special characters are translated into the dollar sign ($). These include characters that are used as masking characters in resource rules. If not translated, these characters could create undesired results. The special characters include the period, asterisk, dash, plus, blank, and quote. An exit point is provided that can further modify any character to meet special needs, with the exception of the slash character, which will always be translated to a period delimiter. Some examples of path name translation follow: Original Path Name /bin/su /u/user01/proj1/file1.txt /usr/sbin/mknod Security Action Control access to switch user command. Define rule set for user01. Allow system programmers to create character special files. Sample resource rules $KEY(/BIN) TYPE(HFS) SU UID(sysprog) ALLOW $KEY(/U) TYPE(HFS) USER01.- UID(usera) ALLOW $KEY(/USR) TYPE(HFS) SBIN.MKNOD UID(sysprog) ALLOW

Translated Path Name /BIN.SU /U.USER01.PROJ1.FILE1$TXT /USR.SBIN.MKNOD

4­8

z/OS and OS/390 Security Cookbook

File Access Security

Seteuid Permission Bit Programs

In normal HFS, when a program or executable file with the seteuid permission bit on is executed, the seteuid process changes the UID from the actual user to the UID of the owner of the file. This allows users to access files under different permissions from their own. With eTrust CA-ACF2 HFS processing, access to a file is done based on the UID of the person accessing the file. However, due to the seteuid processing described above, the eTrust CA-ACF2 support still allows for this. When eTrust CA-ACF2 HFS support recognizes that the seteuid bit is on, it checks to see if the effective UID is equal to the UID of the file owner. If they match, access is allowed. If they do not match, the normal resource validation is done.

Symbolic Links

When an actual file is accessed via a symbolic link, the file name passed to eTrust CA-ACF2 has been resolved to the actual file name of the file and validation is done based on that actual file name. For most validation situations this is sufficient. However, in the case of the following, eTrust CA-ACF2 validates the link itself rather than the file name:

unlink (delete rename (change readlink (read lchown (change a symbolic link) one symbolic link name to another) a symbolic link to determine what it points to) the owner of a link)

Shared HFS

With OS/390 V2R9, HFS files one system can be accessed by other systems within the sysplex. It is no longer possible to mount a file system that is only accessible from its own system. For more information and details about a shared HFS, see the OS/390 UNIX System Services Planning Guide. There are implications to eTrust CA-ACF2 HFS rule writing inherent with the way USS specifies the path name in a shared HFS sysplex. The path name now contains the system name of the system that owns the file. For example, referring the examples of path name translation above, access to the su command on the system XE77 would have an original path name of /XE77/bin/su. This would be translated to a path name for eTrust CA-ACF2 purposes of /XE77.BIN.SU. This gives us a resource rule similar to the following:

$KEY(/XE77) TYPE(HFS) BIN.SU UID(sysprog) ALLOW

Controlling Access to the Hierarchical File System

4­9

File Access Security

User File Ownership

Another consideration of HFS file validation is how user files are validated. User files are those files that are below a directory entry representing a specific user. CA SAF HFS security lets users maintain their own resource rules, generate resource names that can be identified as existing in a user directory, and bypass validation for access to files within the user's own directory. Ownership of MVS data sets is identified by use of the data set high-level qualifier. In a decentralized security environment, users can create rules to protect their own data sets. This concept has been carried over into HFS file security. When GSO RULEOPTS specifies the NOCENTRAL option, users are able to maintain and store their own HFS resource rules. Ownership is identified in the $KEY by the presence of the userid prefixed by `$$'. This prefixed userid must be the only value within the $KEY. For example, USER01 is able to maintain the HFS resource rule with $KEY($$USER01). The userid must be defined as an OMVS user. Although validation can be directed to a $$userid rule using NEXTKEY, the example in the previous section, Path Name Translation, shows another facility that is available to automatically translate the rule to the $$userid format at validation time. This facility can be used if all user directories are anchored at the same location in the file system. An installation exit defines this location to CA SAF HFS security as the user directory mount point. A common location for user directories to be anchored is at the /u/ mount point. If this is the case, expanding upon the above example, path name /u/user01/proj1/file1.txt is translated to $$USER01.PROJ1.FILE1$TXT. To implement this facility, use an exit as described later in this chapter in the Implementation section. Even if user directories are not anchored in one central location, the exit can be used to create the $$userid format of the resource at validation time. By default, no user directory path is recognized and the resource is not translated into the $$userid format. Additionally, users can access files that reside in their own user directory without incurring a validation for that file. Users are always able to access their own files. This option requires that a user directory anchor point be defined through use of the installation exit. The exit returns an indicator stating that the file ownership option is active. For example, if this option were active, validation is bypassed when USER01 accesses /u/user01/proj1/file1.txt. By default, users do not automatically have access to their own files.

4­10

z/OS and OS/390 Security Cookbook

File Access Security

Rule Considerations

This section describes special considerations to be taken into account when writing rules for HFS resources. In addition to access to HFS files, users might need access to directories. A user requires READ access to a directory to list the contents of that directory. When writing a rule set, you distinguish a rule line protecting the directory from rule lines protecting the files within the directory by not using an extended key in the rule line. For example, the rule used to let users read the /BIN directory, but only allow EXECUTE access to the files contained within the directory is:

$KEY(/BIN) TYPE(HFS) UID(-) SERVICE(READ) ALLOW - UID(-) SERVICE(EXECUTE) ALLOW

Files contained in the root directory must be specified as the $KEY value in a separate rule set, that is, they cannot be specified as an extended rule line within the $KEY(/) root rule set. Therefore, the only valid rule line for the $KEY(/) root rule set is that which allows read access to the directory itself. The following shows the rule set required for the root directory and a sample rule set allowing read and write access to file /rootfile:

$KEY(/) TYPE(HFS) UID(-) SERVICE(READ) ALLOW $KEY(/ROOTFILE) TYPE(HFS) UID(-) SERVICE(READ,UPDATE) ALLOW

Rules written to secure HFS file resources should specify the SERVICE keyword to identify the type of access to the file. If the SERVICE keyword is not used, all access is implied. The SERVICE keywords are: SERVICE Keyword EXECUTE READ UPDATE ADD DELETE Description Allows execute access to a file, usually a program file. Allows read access to a file. Allows write access to a file. Allows the ability to create and delete a file. A special access not used for normal file access validation. This is used in conjunction with HFS function security to let a user change file attributes. See File Functions for more information.

CA SAF HFS security uses fast-path resource validation. Because of this, the HFS resource rules must be defined as resident through use of the GSO INFODIR record. Also, the eTrust CA-ACF2 resource pre- and post- exits are not processed for HFS file validation.

Controlling Access to the Hierarchical File System

4­11

Securing HFS Functions

Reporting

Auditing records created by HFS file access, that is, violation, trace, and logging records, are accessed through the same facilities as all other resource records, namely, ACFRPTRV. In addition to all the standard items reported, the original, unmodified path name, up to 256 characters, is reported. If using your own reporting, the original path name can be found in SMF record field ACVMFXKY.

Securing HFS Functions

In addition to file access security, HFS functions can also be secured. These functions can be a system action, such as setting a ptrace or a job's priority, or they can be file-related, such as changing the file mode or audit settings. A system function is secured by a rule in the FACILITY class, while a file-related function is secured by a combination of a FACILITY class rule and a HFS file resource rule. By following this approach, changes to file attributes can be permitted at a global basis, or restricted to a particular file. The resource name format for HFS FACILITY rules is:

BPX.CAHFS.function

An example of a rule would be:

$KEY(BPX) TYPE(FAC) CAHFS.function UID(user) ALLOW

Values for function are listed in the next section, System Functions.

System Functions

To perform a system function, the user requires READ access to the corresponding FACILITY rule: BPX.CAHFS.CHANGE.FILE.MODE--Allows a user to change any file mode information. This includes changes to file permission settings, setting the execution UID or GID indicators, setting the "stick" bit, and maintaining Access Control Lists. Native z/OS and OS/390 UNIX permission settings are used for validation purposes only when CA SAF HFS is inactive. BPX.CAHFS.CHANGE.PRIORITY--Allows a user to change the scheduling priority of a process, process group, or user. OS/390 UNIX System Services requires that the user be a superuser to use this function. BPX.CAHFS.SET.PRIORITY--Allows a user to set the scheduling priority of a process, process group, or user. OS/390 UNIX System Services requires that the user be a superuser to use this function.

4­12

z/OS and OS/390 Security Cookbook

Securing HFS Functions

BPX.CAHFS.SET.RLIMIT--Allows a user to set the resource limit for the calling process. BPX.CAHFS.MOUNT--Allows a user to mount file systems. OS/390 UNIX System Services requires that the user be a superuser to use this function. BPX.CAHFS.UNMOUNT--Allows a user to remove a virtual file system. OS/390 UNIX System Services requires that the user be a superuser to use this function. BPX.CAHFS.PTRACE--Allows a user to control and debug another process. Although the user need not be defined as a superuser to use this function, access to this resource does not grant the user any authority higher than superuser. Access to the function is denied if the user attempts to debug a program running with SETUID or SETGID, that is, a program that switches user identification. BPX.CAHFS.CREATE.LINK--Allows a user to create a hard link to an existing file. A hard link is essentially another name for the same file data. If the original file is removed, the hard link still points to the file data. The data is not deleted until the last link is removed. In addition to this resource, the user also requires SERVICE(ADD) access to the HFS file resource rule for both the original file and the link file. Important! When data associated with a hard link is accessed, the CA ENF/USS service requests the file name from OS/390 UNIX Services. The file name returned might be the hard link name or the original file name regardless of the actual path accessed. It is unpredictable which name is returned. Therefore, when a hard link exists, you might maintain rules for both the link name and the original name. BPX.CAHFS.CREATE.EXTERNAL.LINK--Allows a user to create an external link to an object outside of the file system, such as an MVS data set. An external link is a file that contains the name of an external object. If the external object is removed, the external link still contains the name of the non-existent object. BPX.CAHFS.CREATE.SYMBOLIC.LINK--Allows a user to create a symbolic link to an existing file. A symbolic link is a file that contains the name of another file. If the original file is removed, the file data is deleted but the symbolic link still contains a pointer to the non-existent file. Symbolic link names are validated when the link is created and deleted. All other accesses are validated with the original file name. In addition to this resource, the user also requires SERVICE(ADD) access to the HFS file resource rule for both the original file and the link file.

Controlling Access to the Hierarchical File System

4­13

Securing HFS Functions

File Functions

File-related functions can be secured to various levels of granularity. This is accomplished by determining a user's highest level of access to a FACILITY resource. The SERVICE keyword of the FACILITY resource rule is used for this purpose. Depending on the SERVICE level defined, a user can be allowed to perform the function, might be denied, or the user might need access to the HFS file resource rule for the function to be permitted. The following actions are taken based upon the SERVICE value: SERVICE Value ADD DELETE Action Taken The user is allowed to perform the function against all files. The user is allowed to perform the function if the user also has SERVICE(DELETE) access to the HFS file resource rule. The service level of DELETE is not used in normal file access. It is utilized here to provide additional controls for file functions. Processing is the same as for DELETE. The user is allowed to perform the function if the user also has SERVICE(DELETE) access to the HFS file resource rule, or if the user is considered the owner of the file. This is ownership as defined by CA SAF HFS security, not UNIX file UID. If the user has no access to the FACILITY resource rule, the function is denied.

UPDATE READ

None

Since the absence of the SERVICE keyword in a rule implies all services, be sure to specify SERVICE in all of the file function FACILITY rules so that you do not inadvertently allow greater access to functions than you intended. HFS file permission settings and UID/GID ownership are not used for validation purposes when CA SAF HFS security is active. However, the following resources restrict changes to these settings for those cases in which they must be maintained.

4­14

z/OS and OS/390 Security Cookbook

Securing HFS Functions

FACILITY Resources for File Functions The following are the file function FACILITY resources: BPX.CAHFS.CHANGE.FILE.ATTRIBUTES--Allows a user to change extended file attributes, such as APF authorization and program control. Native OS/390 UNIX Services will issue a FACILITY resource call to determine authorization to set the specific attribute, but not to specific files. Use of this file function resource provides additional control down to the file level. The FACILITY resource names used by native OS/390 UNIX Services are: BPX.FILEATTR.APF and BPX.FILEATTR.PROGCTL. BPX.CAHFS.CHANGE.FILE.AUDIT.FLAGS--HFS files contain two sets of audit flags: one that can be set by a normal user and the other that can only be set by an auditor. This resource allows a user to change user-audit flags in a file. Auditor-audit flags can only be set by a user with the logonid AUDIT privilege. There is no validation when an auditor is changing a file's auditor-audit flags. BPX.CAHFS.CHANGE.FILE.FORMAT--Allows a user to change the format of a file. Changes include defining text data delimiters or binary file format. BPX.CAHFS.CHANGE.FILE.MODE--Allows a user to change any file mode information. This includes changes to file permission settings, setting the execution UID or GID indicators, and setting the "sticky" bit. Native OS/390 UNIX permission settings are used for validation purposes only when CA SAF HFS security is inactive. BPX.CAHFS.CHANGE.FILE.MODE.STICKY--Allows a user to set the "sticky" bit in the file mode information. The "sticky" bit causes a program to be loaded from MVS libraries instead of the HFS. When setting this bit, the user also requires access to the resource BPX.CAHFS.CHANGE.FILE.MODE. BPX.CAHFS.CHANGE.FILE.MODE.EUID--Allows a user to set the execution-UID indicator in the file mode information. When this indicator is set, the program runs under the UNIX UID of the file owner instead of the UID of the user running the program. When setting this indicator, the user also requires access to the resource BPX.CAHFS.CHANGE.FILE.MODE. BPX.CAHFS.CHANGE.FILE.MODE.EGID--Allows a user to set the execution-GID indicator in the file mode information. When this indicator is set, the program runs under the UNIX GID of the file owner instead of the GID of the user running the program. When setting this indicator, the user also requires access to the resource BPX.CAHFS.CHANGE.FILE.MODE. BPX.CAHFS.CHANGE.FILE.OWNER--Allows a user to change file owner UID setting. Native OS/390 UNIX ownership settings are used for validation purposes only when CA SAF HFS security is inactive. BPX.CAHFS.CHANGE.FILE.GROUP--Allows a user to change file owner GID setting. Native OS/390 UNIX ownership settings are used for validation purposes only when CA SAF HFS security is inactive.

Controlling Access to the Hierarchical File System

4­15

Implementing CA SAF HFS Security

BPX.CAHFS.CHANGE.FILE.TIME--Allows a user to change the last access or modification time to the current time or a user-specified time. If the current time is to be set and the user has write access to the file, the function is allowed. If the user does not have write access or a user-specified time is to be set, access must be allowed to this FACILITY resource.

Sample Rules

The following example shows rule entries for the BPX FACILITY resource rule that let Thelma change the file mode and owner for all files. The rule entry for Louise lets her change the file mode for those files that reside in a certain directory as indicated by the HFS resource rule, but is not allowed to change the file owner in any other files, unless the individual HFS rules are coded with the service delete:

CAHFS.CHANGE.FILE.MODE UID(thelma) SERVICE(ADD) ALLOW CAHFS.CHANGE.FILE.OWNER UID(thelma) SERVICE(ADD) ALLOW CAHFS.CHANGE.FILE.MODE UID(louise) SERVICE(DELETE) ALLOW $KEY(/certain) TYPE(HFS) directory.- UID(louise) SERVICE(DELETE) ALLOW

Implementing CA SAF HFS Security

CA SAF HFS security is an application of CA ENF/USS (UNIX System Services). This security application is activated when the appropriate DCM modules are linked into the ENF database. The implementation steps are as follows: 1. Determine if exit processing is required for path name translation, user path definition or to enable file ownership. See below for specifics regarding exit processing. If using the exit, assemble and link the exit code using the sample SMP/E usermod found in ACFPTFS member UM80001. Define HFS file and function resource rules. We recommend that all the function resource rules be defined. The CA SAF HFS Rule Generation Utility is also provided to assist in creating resource rules. See the Implementing eTrust CA-ACF2 in a z/OS and OS/390 Environment and CA SAF HFS Rule Generation Utility for more information. If you utilize the user file ownership feature of CA SAF HFS security, also define rules for users, or in a decentralized security environment, notify users that they should write rules for themselves. Define the HFS file rules as resident using the GSO INFODIR record:

SET CONTROL(GSO) CHANGE INFODIR TYPES(R-RHFS)

2.

3.

4.

4­16

z/OS and OS/390 Security Cookbook

Implementing CA SAF HFS Security

5.

Verify that the proper level of CA ENF is available to support ENF/USS. This is provided by Unicenter Common Services Note: You must have Unicenter Common Services installed at the 9807 genlevel or higher.

6.

The ENF started task must be a valid OMVS user. Message CARR014E is issued if this is not done. Ensure the NEF logonid specifies a group and that the group is defined in an OMVS GROUP profile record. Define an OMVS USER profile record with UID 0 for the ENF logonid:

SET PROFILE(USER) DIV(OMVS) INSERT enf UID(0)

7.

Install the following DCM modules into the ENF database using the ENFDB utility program: CARRDCM0 and J163DCM0. The DCM modules come from the following CAILIBs: ­ ­ J163DCM0 is in the ACF2.CAILIB. CARRDCM0 is in the Unicenter Common Service USS CAILIB.

8.

Defining a VLF class for use as a cache can enhance performance of ENF/USS. The cache size is determined by the MAXVIRT specification. You can approximate the number of caches entries by dividing the defined amount of VLF storage by the average size of your path names. Add the following to your current COFVLFxx member in SYS1.PARMLIB:

CLASS NAME(CAENFU) EMAJ(PATHCACHE) MAXVIRT(256) /* ENF/USS pathname cache */ /* Major name */ /* 1 megabyte */

See the Unicenter Common Services documentation for additional information on defining a VLF class. 9. Adding the NON-CNCL attribute to the BPXOINIT logonid during initial testing will allows OMVS to successfully initialize without violations. Once appropriate rules are in place, the NON-CNCL attribute should be removed.

10. The following message is issued by CAENF/USS at ENF startup when CA SAF HFS security is successfully initialized:

CARR036I ­ SAFHFINT / J163 Now Initialized

11. Run ACFRPTRV during the implementation phase. Review violations and loggings for HFS and FAC resource types and create appropriate rules.

Exit Processing

An exit point is provided for installation-specific processing. This exit is called for an initialization function, where options involving pathname translation and user path processing can be selected, and a pathname translation function, where final modification to the pathname can be made before validation is performed.

Controlling Access to the Hierarchical File System

4­17

Implementing CA SAF HFS Security

The exit must be reentrant and capable of running AMODE(31) and RMODE(ANY). The exit name is SAFHFUSR and must be linked together with load module SAFHFSEC. A sample SMP/E usermod to perform this can be found in ACFPTFS member UM80001. Upon entry to the exit, register R1 points to a list of addresses. The end of the list is indicated by the high order bit in the last fullword. For an initialization function, the exit is passed the following parameter addresses:

+0--The address of a single byte containing the character `I' indicating that this is an initialization function. +4--The address of a 512-byte work area for the use of the exit program. +8--The address of a 255-byte field in which the user can return the path location where user directories are located. Upon input, this field contains hex zeros. +12--The address of a single byte which, when set to `Y' by the exit, indicates that user ownership of files is in effect. +16--The address of a 256-byte translation table, which is used to translate certain special characters in a path name.

When the exit returns a user directory path location, CA SAF HFS processing uses that path name to determine if the path name to be validated should be translated to a form such that the user ID of the owner of the path becomes the high-level qualifier of the path name. This will allow HFS file rules to be written at the user level and, if running in a decentralized environment, allow users to maintain their own HFS file rules. The default is that no translation takes place for user directories. For example, if the exit returns the value /u/ as the user directory path name location, and the file accessed is /u/user01/xfile, then the resource name validated is $$USER01.XFILE. A rule to allow access to this file could be:

$KEY($$USER01) TYPE(HFS) XFILE UID(*) ALLOW

When the exit returns the character `Y' indicating that user ownership of files within one's own directory is in effect, no validation is performed when the current user's logonid matches that in the user directory. In the above example, validation is bypassed when USER01 accesses file /u/user01/xfile. This option is meaningless if a user directory path location is not also returned.

4­18

z/OS and OS/390 Security Cookbook

Implementing CA SAF HFS Security

The supplied translate table is in a format acceptable as input to the assembler TR instruction. The default translate table translates all slash characters in a path name, with the exception of the leading slash, to a period character. Other special characters are translated into the dollar sign ($). These include characters that are used as masking characters in resource rules. If not translated, these characters could create undesired results. The special characters include the period, asterisk, dash, plus, blank, and quote. The exit can further modify any character in the table to meet special needs, with the exception of the slash character, which will always be translated to a period delimiter. For a path name translation function, the exit is passed the following parameter addresses:

+0--The address of a single byte containing the character `P' indicating that this is a path name translation function. +4--The address of a 512-byte work area for the use of the exit program. +8--The address of a 255-byte field containing the resource name as modified by CA SAF HFS processing. This is the name that is used for validation. The exit can return a modified path name in this same field. +12--The address of a 1023-byte field containing the original, unmodified path name.

The exit can use this exit function to make any specific modifications to the path name beyond that already performed by CA SAF HFS security processing.

Troubleshooting

Reporting and logging is done through the existing eTrust CA-ACF2 resource report, ACFRPTRV. When the TRACE attribute is on in a user's logonid, trace records will also appear on the report. The report will show the translated name of the HFS file used for validation along with the first 256 characters of the original HFS path name. ACFRPTRV should be reviewed when researching validation problems. The CA SAF HFS security interface can be traced by using the SECTRACE command. A trace of internal functions of CA SAF HFS security is enabled through use of the SECTRACE TYPE=HFS keyword. The trace output can be requested by Technical Support. The syntax is:

SecTrace SET,TYPE=HFS

Controlling Access to the Hierarchical File System

4­19

CA SAF HFS Rule Generation Utility

The following keywords are meaningful when TYPE=HFS is specified:

ID= JOBname= USERid= ENable|DISable ACTION= MATCHLIM= DEST=CONSOLE|JOBLOG|SYSLOG CONSid= MSGid|NOMSGid

Other keywords are ignored. If DEST is not specified, the default is DEST=SYSLOG. The SAF validation calls invoked by CA SAF HFS security can also be traced. These SAF calls are the file and function validations that are passed to eTrust CA-ACF2. Enable this tracing by first issuing the SECTRACE SET command detailed below, followed by a reply to the prompt:

ST SET,ID=id,TYPE=SAFP,DEST=dest,END R nn,REQSTOR=SAFHFSEC,END

CA SAF HFS Rule Generation Utility

A utility program is provided to generate eTrust CA-ACF2 resource rules to be used as a starter set of rules for new implementations. The HFS resource rules that are created give access based upon the file permission bits defined for `other' users. In other words, the rules will give users the same default access to files as they have when not running CA SAF HFS security. The generated rules must be modified to allow appropriate users greater access to the file resources than that granted to the general user community. The input file to the utility is created by the OMVS ls command. This file contains a listing of all files and directories in the HFS. The output files contain commands to compile eTrust CA-ACF2 rules sets and to add rules using ACFNRULE. These files are meant to be reviewed, adjusted, and then executed using the batch TMP utility. For more information on the ACFNRULE utility, consult the eTrust CA-ACF2 Reports and Utilities Guide. The first step is to create the input file. This is done by issuing the ls command from the OMVS shell, directing the output to a HFS file. The options ­lRA must be specified (the character following the dash is a lower case letter "L," not the number one). Note that the ls command will only access file systems that are mounted at the time the command is issued. The file can then be copied into an MVS data set using the OGET command.

4­20

z/OS and OS/390 Security Cookbook

CA SAF HFS Rule Generation Utility

The following are examples of these commands. Issue this command under OMVS:

ls -lRA / >directory_information_file

Issue this second command under TSO:

OGET '/directory_information_file' 'mvs.input.file'

The resulting file data should look similar to this:

/: total 232 drwx-----drwxr-xr-x drwx--x--x drwxr-xr-x drwxr-xr-x drwxrwxrwx drwxr-xr-x drwxr-xr-x /JavaS390: total 16 drwxrwxrwx 3 4 2 8 2 2 8 11 USER USER USER USER USER USER USER USER OPENMVS OPENMVS OPENMVS OPENMVS 0 0 0 0 0 0 0 0 Jun May Oct Nov Jan Jan Jan Jan 3 1998 JavaS390 7 1998 bin 1 1997 dev 4 17:05 etc 20 1998 lib 19 11:51 tmp 15 15:47 u 20 1998 usr

7 USER

ZEROGRP

0 Sep 25

1997 J1.1.1

If the data is not in this format, the utility program will terminate. An error message in the SYSPRINT file will display the line that was not recognized. Use the file data as input to the utility. The data set is referenced by the HFSINPUT DD name. Sample JCL follows:

//jobname //stepname //HFSINPUT //SYSPRINT //RULESETS // //ACFNRULE // JOB EXEC DD DD DD DD CLASS=a PGM=SAFHFACF DSN=mvs.input.file,DISP=SHR SYSOUT=* DSN=ruleset.output,DISP=(,CATLG), SPACE=(CYL,(1,1)),UNIT=sysda DSN=acfnrule.output,DISP=(,CATLG), SPACE=(CYL,(1,1)),UNIT=sysda

If mixed case resource names are being used for HFS, code the EXEC statement as follows:

//stepname EXEC PGM=SAFHFACF,PARM=MIXED

The MIXED parameter on the PARM statement causes the program to output the rules in a mixed case format. Alternatively, the input file can point directly to the directory information file created from the ls command. If using this format, the LRECL value specified in the JCL must be at least as large as the largest record in the file. The BLKSIZE value should be a value at least 8 times greater than the LRECL. The PATH name must be the full path name of the file containing the directory information.

Controlling Access to the Hierarchical File System

4­21

CA SAF HFS Rule Generation Utility

A sample statement follows:

//HFSINPUT // // DD PATH='/directory_information_file', PATHOPTS=(ORDONLY),FILEDATA=TEXT, RECFM=VB,LRECL=nnn,BLKSIZE=nnn

After the job is executed, review the data in the RULESETS and ACFNRULE data sets. The RULESETS data set contains commands to compile all rules sets created by the utility. It also contains commands to backup existing HFS or FAC rules by decompiling them into a data set. Some of the rule sets contain rules to allow but log access for 14 days. These rules are meant to assist in the implementation process. After reviewing the loggings reported by ACFRPTRV and writing appropriate rules, these rule lines should be removed. The ACFNRULE data set contains the ACFNRULE commands to add specific rule lines to the rules sets. This data should be edited to remove redundant rule lines. The format of the output should make it fairly obvious which lines could be removed. For example, some directory entries contain example or demo files, which could be consolidated into one rule. Consider the following utility output:

ACFNRULE KEY(/USR/LPP/TCPIP) TYPE(HFS) NOLIST ADD(- SERVICE(READ) UID(*) ALLOW) ­ ADD(X11R6.- SERVICE(READ) UID(*) ALLOW) ­ ADD(X11R6.XAMPLES.- SERVICE(READ) UID(*) ALLOW) ­ ADD(X11R6.XAMPLES.CLIENTS.- SERVICE(READ) UID(*) ALLOW) ­ ADD(X11R6.XAMPLES.CLIENTS.BITMAP.- SERVICE(READ) UID(*) ALLOW) ­ ADD(X11R6.XAMPLES.CLIENTS.XAUTH.- SERVICE(READ) UID(*) ALLOW) ­ ADD(X11R6.XAMPLES.CLIENTS.XCLOCK.- SERVICE(READ) UID(*) ALLOW) ­ ADD(X11R6.XAMPLES.CLIENTS.XLOGO.- SERVICE(READ) UID(*) ALLOW) ­ ADD(X11R6.XAMPLES.CLIENTS.XPROP.- SERVICE(READ) UID(*) ALLOW) ­ ADD(X11R6.XAMPLES.DEMOS.- SERVICE(READ) UID(*) ALLOW) ­ ADD(X11R6.XAMPLES.DEMOS.XSAMP1.- SERVICE(READ) UID(*) ALLOW) ­ ADD(X11R6.XAMPLES.DEMOS.XSAMP2.- SERVICE(READ) UID(*) ALLOW) ­ ADD(X11R6.XAMPLES.MAN.- SERVICE(READ) UID(*) ALLOW) ­ ADD(X11R6.XAMPLES.MAN.CAT1.- SERVICE(READ) UID(*) ALLOW)

Because all of the directories and files are defined with READ access, the rule set can be safely reduced to the following by removing the rules for directories under the XAMPLES directory:

ACFNRULE KEY(/USR/LPP/TCPIP) TYPE(HFS) NOLIST ­ ADD(- SERVICE(READ) UID(*) ALLOW) ­ ADD(X11R6.- SERVICE(READ) UID(*) ALLOW) ­ ADD(X11R6.XAMPLES.- SERVICE(READ) UID(*) ALLOW)

The utility program might issue the message: Warning - $PREFIX maximum length exceeded. This indicates that the $PREFIX value generated for a rule set is greater than the 24 character maximum. This problem can be addressed by using masking at a lower level to eliminate the need for the nextkey rule set, or, by shortening the $PREFIX value by removing file name levels from the end of the $PREFIX value and adding them to the rule lines themselves.

4­22

z/OS and OS/390 Security Cookbook

CA SAF HFS Security Modification Utility

After modifications are made, run the commands contained in the files as input to the batch TMP utility. First run the RULESETS commands, and then the ACFNRULE commands. Sample TMP JCL follows:

//jobname //stepname //SYSTSPRT //SYSTSIN JOB EXEC DD DD CLASS=a PGM=IKJEFT01 SYSOUT=* DSN=command.data.set,DISP=SHR

Examine the output for successful completion. The ACF50035 message will indicate any errors during ACFNRULE processing. After resolving any errors, you can run the modified RULESETS and ACFNRULE commands through the batch TMP once again. Any rules previously created are backed up by the commands in the RULESETS file. As mentioned earlier, the HFS rules that are created give access based upon the file permission bits defined for `other' users. As a final step, the rules must be modified to allow appropriate users greater access to the file resources than that granted to the general user community. The rule set keys should closely represent the various applications using HFS resources. Ownership and administrative responsibilities for the data should be determined so that the rules can be maintained on an ongoing basis.

CA SAF HFS Security Modification Utility

A utility program is provided to allow authorized users to display the status of and to enable or disable CA SAF HFS security. The utility is run in batch with the requested function passed in the PARM field of the JCL EXEC statement. Sample JCL follows:

//jobname //stepname JOB CLASS=a EXEC PGM=SAFHFMOD,PARM=function

Where function can be one of the following: STATUS--Issues a message indicating the current status of CA SAF HFS security. ENABLE--Enables CA SAF HFS security. When enabled, normal OS/390 UNIX security access validation is bypassed. This includes checking of file permission bits, superuser status and normal OS/390 UNIX Security Services. DISABLE--Disables CA SAF HFS security. When disabled, normal OS/390 UNIX security access validation is enabled. This includes checking of file permission bits, superuser status and normal OS/390 UNIX Security Services.

Controlling Access to the Hierarchical File System

4­23

CA SAF HFS Security Modification Utility

The program must reside in an APF-authorized library. If the requested function is STATUS and the user running the job is defined to security as an auditor, no further authorization is required. Otherwise, the user running the job must be allowed to a resource in the SAF FACILITY class. The resource name is:

BPX.CAHFS.SECURITY.function

Where function can be STATUS, ENABLE, or DISABLE.

4­24

z/OS and OS/390 Security Cookbook

Chapter

5

Digital Certificate Support

An X.509 Digital Certificate provides a secure method for identifying a user, typically through a Web-based application. As an alternative to requesting userid and password information, a z/OS and OS/390 Web server can authenticate users based upon their digital certificates. Digital certificates provide a means of authentication through the use of public-key cryptography and a trusted third party, known as a Certification Authority. A digital certificate is generated by the Certification Authority and is identified uniquely by its serial number and by the associated distinguished name of the Certification Authority ("issuer's distinguished name"). If MVS resources are accessed, the certificate is presented to eTrust CA-ACF2. Using the certificate serial number and the issuer's distinguished name, eTrust CA-ACF2 associates the certificate with an MVS userid. An MVS security environment is then created for that user. By using authenticated certificates, passwords are not sent through the network. eTrust CA-ACF2 provides complete functionality to generate, install and maintain digital certificates, key rings, and digital certificate mappings, including the following:

Generate a digital certificate and a public/private key pair Create a PKCS #12 certificate package Create a PKCS #10 certificate request Export a digital certificate or certificate package and private key from eTrust CA-ACF2 to a z/OS and OS/390 dataset Display a certificate that is in a z/OS and OS/390 dataset and determine if it is associated with an eTrust CA-ACF2 user Display a certificate registered with eTrust CA-ACF2 Automatically register a digital certificate with eTrust CA-ACF2 Associate an eTrust CA-ACF2 user with a digital certificate Change, display and delete information about a digital certificate for an eTrust CA-ACF2 user Create, change, display and delete a key ring Add and remove a certificate from a key ring

Digital Certificate Support

5­1

CA SAF HFS Security Modification Utility

Assign an eTrust CA-ACF2 user to a group of certificates via user ID mapping Assign an eTrust CA-ACF2 user to a group of certificates based on system ID, application ID, or application-defined variables Change, delete, and display an eTrust CA-ACF2 user ID mapping

The following Table summarizes all of the eTrust CA-ACF2 commands that can be issued to generate, install and maintain digital certificates, key rings, and digital certificate mappings. ACF Setting/ Component ACF COMMON SUBCOMMAND

Command CHKCERT

Function eTrust CA-ACF2 displays information about an X.509 certificate in a CERTDATA profile record or a z/OS and OS/390 data set (including whether it is registered with eTrust CA-ACF2). eTrust CA-ACF2 associates a certificate with a key ring. eTrust CA-ACF2 exports an X.509 digital certificate from the eTrust CA-ACF2 database and puts it into a z/OS and OS/390 data set.

Syntax

CHKcert {logonid Label(label)| logonid.suffix|Dsname(data-set-name)} [Password(password)] [Nolist] [Dump]

CONNECT

ACF COMMON SUBCOMMAND

EXPORT

ACF COMMON SUBCOMMAND

CONnect Certdata(userid1.suffix) Keyring(userid2.suffix) [Ringname(ringname)] [Label(label)] [Usage(PERSONAL|CERTAUTH|SITE)] [DEFAULT] Export {logonid|logonid.suffix} Dsname(data-set-name) [Label(label)] [Format(CERTDER|CERTB64| PKCS12DER|PKCS12B64)] [Password(password)]

5­2

z/OS and OS/390 Security Cookbook

CA SAF HFS Security Modification Utility

Command GENCERT

Function eTrust CA-ACF2 generates a digital certificate and inserts a CERTDATA profile record into the eTrust CA-ACF2 infostorage database.

ACF Setting/ Component ACF COMMON SUBCOMMAND

Syntax

GENCErt {logonid|logonid.suffix| CERTAUTH|CERTAUTH.suffix| SITECERT|SITECERT.suffix } [Label(label)] [Dsname(data-set-name)] [SUbjsdn([CN=common name] [T=title] [OU=organizational-unit-name] [O=organization-name] [L=locality] [S=state-or-province| SP=state-or-province| ST=state-or-province] [C=country])] [SIZe({key-size|1024})] [ACtive({date-or-date-time| current-date-000000| current-date-time})] [Expire({date-or-date-time| current-date-000000| current-date-time})] [SIGnwith({CERTAUTH Label(label-name)| SITECERT Label(label-name)| CERTAUTH.suffix|SITECERT.suffix)| Label(label-name)}] [Keyusage([HANDSHAKE] [DATAENCRYPT][DOCSIGN] [CERTSIGN])] ALtname([IP=numeric-ip-address] [DOMAIN=internet-domain-name] [EMAIL=email-address] [URI=universal-resource-identifier]) GENReq {logonid|logonid.suffix} Dsname(data-set-name) [Label(label)]

GENREQ

eTrust CA-ACF2 generates a certificate request (PKCS #10) to be sent to a Certification Authority. eTrust CA-ACF2 disassociates a certificate from a key ring.

ACF COMMON SUBCOMMAND

REMOVE

ACF COMMON SUBCOMMAND

REMove Certdata(userid1.suffix) Keyring(userid2.suffix) [Ringname(ringname)] [Label(label)]

Digital Certificate Support

5­3

CA SAF HFS Security Modification Utility

Command INSERT

Function eTrust CA-ACF2 reads an X.509 digital certificate from a z/OS and OS/390 data set and inserts it, along with data from the command input line, into a CERTDATA profile record, which associates a user with a certificate. eTrust CA-ACF2 accepts data from the command input line and, accordingly, changes the CERTDATA profile record(s), which associates a user(s) with a certificate(s). eTrust CA-ACF2 deletes the CERTDATA profile record(s), which associates a user(s) with a certificate(s). eTrust CA-ACF2 displays the CERTDATA profile record(s), which associates a user(s) with a certificate(s).

ACF Setting/ Component PROFILE USER RECORD (CERTDATA)

Syntax

Insert {logonid|logonid.suffix| CERTAUTH|CERTAUTH.suffix|SITECERT| SITECERT.suffix } [Active(date)] Dsn(data-set-name) [Expire(date)] [Label(label)] [Password(password)] [HITRUST|TRUST|NOTRUST]

CHANGE

PROFILE USER RECORD (CERTDATA)

CHAnge {logonid|logonid.suffix| CERTAUTH|CERTAUTH.suffix|SITECERT| SITECERT.suffix } [Active(date)] [Expire(date)] [NEWLABEL(label)] [HITRUST|TRUST|NOTRUST] CHAnge userid ISSUERDN(dn) SERIAL#(serial-number) [Active(date)] [Expire(date)] [NEWLABEL(label)] [HITRUST|TRUST|NOTRUST]

DELETE

PROFILE USER RECORD (CERTDATA)

DELete {logonid LABEL(label)| logonid.suffix| CERTAUTH LABEL(label)|CERTAUTH.suffix| SITECERT LABEL(label)|SITECERT.suffix} DELete userid ISSUERDN(dn) SERIAL#(serial-number) List {logonid LABEL(label)|logonid.suffix| CERTAUTH LABEL(label)|CERTAUTH.suffix| SITECERT LABEL(label)|SITECERT.suffix} List userid ISSUERDN(dn) SERIAL#(serial-number)

LIST

PROFILE USER RECORD (CERTDATA)

5­4

z/OS and OS/390 Security Cookbook

CA SAF HFS Security Modification Utility

Command INSERT

Function eTrust CA-ACF2 inserts a KEYRING profile record, which associates one or more certificates with a single user (logonid). eTrust CA-ACF2 accepts data from the command input line and, accordingly, changes the KEYRING profile record, which associates one or more certificates with a single user (logonid). eTrust CA-ACF2 deletes the KEYRING profile record, which associates one or more certificates with a single user (logonid). eTrust CA-ACF2 displays the KEYRING profile record, which associates one or more certificates with a single user (logonid).

ACF Setting/ Component PROFILE USER RECORD (KEYRING)

Syntax

Insert {recid|recid.suffix } [Default(userid.suffix)] Ringname(ringname)

CHANGE

PROFILE USER RECORD (KEYRING)

CHAnge {recid|recid.suffix } [Default(userid.suffix)] [Ringname(ringname)]

DELETE

PROFILE USER RECORD (KEYRING)

DELete {recid|recid.suffix }

LIST

PROFILE USER RECORD (KEYRING)

List {recid |recid.suffix }

Digital Certificate Support

5­5

CA SAF HFS Security Modification Utility

Command INSERT

Function eTrust CA-ACF2 inserts a CERTMAP GSO record, which defines the IDN (issuer's distinguished name) or SDN (subject's distinguished name) filters used to assign a specific logonid to a group of certificates. eTrust CA-ACF2 accepts data from the command input line and, accordingly, changes the CERTMAP GSO record, which defines the IDN (issuer's distinguished name) or SDN (subject's distinguished name) filters used to assign a specific logonid to a group of certificates.

ACF Setting/ Component CONTROL GSO RECORD (CERTMAP)

Syntax

Insert CERTMAP.recid [SDNFILTR(subject's-dist-name-filter)] [IDNFILTR(issuer's-dist-name-filter)] [DSN(data-set-name)] [CRITERIA(criteria-name-template)] [LABEL(label)] [TRUST|NOTRUST] [USERID(userid-to-map-to) [MULTIID|NOMULTIID]

CHANGE

CONTROL GSO RECORD (CERTMAP)

CHAnge CERTMAP.recid [SDNFILTR(subject's-dist-name-filter)] [IDNFILTR(issuer's-dist-name-filter)] [DSN(data-set-name)] [CRITERIA(criteria-name-template)] [LABEL(label)] [TRUST|NOTRUST] [USERID(userid-to-map-to)] [MULTIID|NOMULTIID]

5­6

z/OS and OS/390 Security Cookbook

CA SAF HFS Security Modification Utility

Command DELETE

Function eTrust CA-ACF2 deletes the CERTMAP GSO record, which defines the IDN (issuer's distinguished name) or SDN (subject's distinguished name) filters used to assign a specific logonid to a group of certificates. eTrust CA-ACF2 displays the CERTMAP GSO record, which defines the IDN (issuer's distinguished name) or SDN (subject's distinguished name) filters used to assign a specific logonid to a group of certificates. eTrust CA-ACF2 displays information contained in CERTMAP records as laid out in the internal CERTMAP table.

ACF Setting/ Component CONTROL GSO RECORD (CERTMAP)

Syntax

DELete CERTMAP.recid

LIST

CONTROL GSO RECORD (CERTMAP)

List CERTMAP.recid

SHOW

ACF COMMON SUBCOMMAND

SHow CERTMAP

Digital Certificate Support

5­7

CA SAF HFS Security Modification Utility

Command INSERT

Function eTrust CA-ACF2 inserts a CRITMAP GSO record, which is used in conjunction with the CRITERIA parameter of the CERTMAP GSO record, to assign a specific logonid to a group of certificates based on the system ID, application ID, or application-defined variables specified in the CRITMAP GSO record. eTrust CA-ACF2 accepts data from the command input line and, accordingly, changes the CRITMAP GSO record, which is used in conjunction with the CRITERIA parameter of the CERTMAP GSO record, to assign a specific logonid to a group of certificates based on the system ID, application ID, or application-defined variables specified in the CRITMAP GSO record.

ACF Setting/ Component CONTROL GSO RECORD (CRITMAP)

Syntax

Insert CRITMAP.recid [APPLID(application-name)] [SYSTEMID(sysid)] [APPLVAR(site-variable-list)] USERID(userid-to-map-to)

CHANGE

CONTROL GSO RECORD (CRITMAP)

CHAnge CRITMAP.recid [APPLID(application-name)] [SYSTEMID(sysid)] [APPLVAR(site-variable-list)] USERID(userid-to-map-to)

5­8

z/OS and OS/390 Security Cookbook

CA SAF HFS Security Modification Utility

Command DELETE

Function eTrust CA-ACF2 deletes the CRITMAP GSO record, which is used in conjunction with the CRITERIA parameter of the CERTMAP GSO record, to assign a specific logonid to a group of certificates based on the system ID, application ID, or application-defined variables specified in the CRITMAP GSO record. eTrust CA-ACF2 displays the CRITMAP GSO record, which is used in conjunction with the CRITERIA parameter of the CERTMAP GSO record, to assign a specific logonid to a group of certificates based on the system ID, application ID, or application-defined variables specified in the CRITMAP GSO record. eTrust CA-ACF2 displays information contained in CRITMAP records as laid out in the internal CRITMAP table.

ACF Setting/ Component CONTROL GSO RECORD (CRITMAP)

Syntax

DELete CRITMAP.recid

LIST

CONTROL GSO RECORD (CRITMAP)

List CRITMAP.recid

SHOW

ACF COMMON SUBCOMMAND

SHow CRITMAP

Digital Certificate Support

5­9

Processing Digital Certificates with ACF Subcommands

Processing Digital Certificates with ACF Subcommands

After you enter the ACF command, you can use the subcommands listed below to create, display, and export digital certificates, create certificate requests, and associate certificates with or disassociate certificates from key rings. These subcommands are common to all settings. A detailed description of each subcommand follows:

CHKCERT EXPORT GENCERT GENREQ CONNECT REMOVE

CHKCERT Subcommand

The CHKCERT subcommand is used to display information about an X.509 certificate in a CERTDATA Profile record or a z/OS and OS/390 data set, including whether it is registered with eTrust CA-ACF2. The certificate can be in DER-encoded or base-64-encoded form (PEM). It can also be a PKCS #12 certificate, which includes the private key associated with the certificate. The CHKCERT subcommand can be issued in any mode of the ACF command. It has the following syntax:

CHKcert {logonid Label(label) |logonid.suffix | Dsname(data-set-name)} [Password(password)] [Nolist] [Dump]

Parameter Descriptions logonid Label(label)--Indicates the eTrust CA-ACF2 user whose label is used to specify which CERTDATA record containing the certificate is displayed. Note: For every one apostrophe desired in the Label value, two consecutive apostrophes must be specified. For example, the Label value, Frank's Certificate, should be specified as, Frank"s Certificate. If a single apostrophe is specified in the Label value, the value will be considered invalid. logonid.suffix--Indicates the eTrust CA-ACF2 record id of the CERTDATA record containing the certificate that is displayed.

5­10

z/OS and OS/390 Security Cookbook

Processing Digital Certificates with ACF Subcommands

Dsname(data-set-name)--Indicates the name of the data set containing the certificate to be checked. If the data set name is enclosed in single quotes, it is considered fully qualified and is used as specified. Otherwise, the user's prefix, as specified by the TSO PROFILE PREFIX command (or defaulted from the DFT-PFX field of the logonid record) is added to the front of the data set name. Password(password)--The password associated with a PKCS #12 certificate. This must be the same password that was specified when the certificate was exported. Nolist--Indicates that the eTrust CA-ACF2 CERTDATA profile record should not be listed, even if the certificate is registered with eTrust CA-ACF2. Dump--Indicates to display a hex dump of the certificate prior to listing the contents of the certificate. Examples The following displays information about the certificate in the FRANK01.MYCERT data set.

CHKCERT DSN(`frank01.mycert')

Since the certificate is registered with eTrust CA-ACF2 and the User Profile Directory has been rebuilt, the CERTDATA profile record is listed.

Data set name: FRANK01.MYCERT Serial number: 02 Issuer's distinguished name: CN=Blue Lock Company Certificate Authority OU=Auditing Department O=Blue Lock Company C=US Subject's distinguished name: CN=Frank Schwinger OU=Sales Department O=Blue Lock Company C=US Not valid before: 2002/02/02 00:00:00 UTC Not valid after: 2003/12/31 00:00:00 UTC This certificate is registered with eTrust CA-ACF2

Digital Certificate Support

5­11

Processing Digital Certificates with ACF Subcommands

The CERTDATA record key is FRANK01.MYCERT CERTDATA / FRANK01.MYCERT LAST CHANGED BY CUNKE01 ON 02/02/02-11:23 ISSUERDN(CN=Blue Lock Company Certificate Authority.OU=Auditing Department.O=Blue Lock Company.C=US) KEYSIZE(1,024) LABEL(Frank01 Cert) SERIAL#(02) SUBJDN(CN=Frank Schwinger.OU=Sales Department.O=Blue Lock Company.C=US) TRUST Certificate is not connected to any keyrings

The following are examples of the CHKCERT command. It can be used to display a certificate contained in a data set or a certificate contained in an eTrust CA-ACF2 User Profile CERTDATA record:

CHKCERT DSN('frank01.mycert') NOLIST CHKCERT frank01.cert DUMP CHKCERT certauth label(Audit CA)

While only a few common attributes usually appear in distinguished names, there are many possible attributes. Attributes that are not recognized by eTrust CA-ACF2 are displayed in the notation recommended by Internet RFC 1779, A string representation of distinguished names. For example, the last attribute of the subject's distinguished name is listed as OID.2.5.4.20==#3535352031323132. It is possible to look up the Object ID (OID) at an OID locator site, such as http://www.alvestrand.no/domen/objectid/top.html and determine that the OID represents a telephone number. The value of the field is displayed in hexadecimal and it is possible to see that it is the ASCII representation of the telephone number: 555 1212.

EXPORT Subcommand

The EXPORT subcommand is used to export an X.509 digital certificate from the eTrust CA-ACF2 database and put it into a z/OS and OS/390 data set. The data set can be used to insert the certificate in another system, or can be downloaded to a personal computer and installed in a web browser. If you send the exported certificate to others that receive messages from you signed with your private key, they can use the public key in the exported certificate to validate those messages, but they cannot forge messages from you because they do not have your private key. Your private key can be exported using the PKCS12DER or PKCS12B64 format options. Using these options will generate a PKCS #12 certificate package containing the user certificate, its private key, and all certificate-authority certificates necessary to complete the chain of certificates from user certificate to root certificate-authority certificate. The EXPORT command can be issued in any mode of the ACF command. It has the following syntax:

Export {logonid|logonid.suffix} Dsname(data-set-name) [Label(label)] [Format(CERTDER|CERTB64|PKCS12DER|PKCS12B64)] [Password(password)]

5­12

z/OS and OS/390 Security Cookbook

Processing Digital Certificates with ACF Subcommands

Parameter Descriptions logonid|logonid.suffix--The record key of the certificate to be exported, if Label is not also specified. This can be a one to eight-character logonid or a logonid, a dot, and a one- to eight-character suffix. Dsname(data-set-name)--The name of the data set into which the certificate is exported. The data set must not already exist. If the data set name is enclosed in single quotes, it is considered fully qualified and is used as specified. Otherwise, the user's prefix, as specified by the TSO PROFILE PREFIX command (or defaulted from the DFT-PFX field of the logonid record) is added to the front of the data set name. Label(label)--The label of the certificate to be exported. Logonid must also be specified to indicate which logonid the label is associated with. Note: For every one apostrophe desired in the Label value, two consecutive apostrophes must be specified. For example, the Label value, Frank's Certificate, should be specified as, Frank"s Certificate. If a single apostrophe is specified in the Label value, the value will be considered invalid. Password(password)--A password used to encrypt the private key and certificates in a PKCS #12 package. This password does not conform to normal eTrust CA-ACF2 password syntax and can be mixed case and up to 255 bytes in length. If password is specified, a PKCS #12 package is generated with the user certificate, private key and CA certificates. If format is not specified, format will default to PKCS12B64. Note that eTrust CA-ACF2 only supports PKCS #12 certificates that adhere to the PKCS #12 v1.0 standard published by RSA. These certificates are defined with a 3 in the version number of the PKCS #12 certificate package. Format(CERTDER)--Indicates that the exported certificate should be encoded using the X.509 Distinguished Encoding Rules (DER). This is the standard form of an X.509 certificate. It is a binary file, so if it is being transferred using FTP, BINARY or IMAGE mode must be used. Format(CERTB64)--Indicates that the exported certificate should be encoded using base-64 encoding. This encoding is applied to the standard X.509 certificate to make it possible to ship the certificate through systems, such as E-mail systems, that cannot handle binary files. This is a text file, so if it is being transferred using FTP, ASCII or TEXT mode must be used. Format(CERTB64) is the default if no format is specified. Format(PKCS12DER)--Specifies a DER-encoded PKCS #12 certificate package. If this option is selected, a PASSWORD must also be supplied. Format(PKCS12B64)--Specifies a DER-encoded then base-64 encoded PKCS #12 certificate package. If this option is selected, a PASSWORD must also be supplied. Format (PKCS12B64) is the default if a password has been specified but no format is specified.

Digital Certificate Support

5­13

Processing Digital Certificates with ACF Subcommands

Examples The following exports the certificate with a record key of FRANK01.CERT into a data set named FRANK01.MYCERT, using base-64 encoding.

EXPORT FRANK01.CERT DSNAME(MYCERT)

The following exports the certificate belonging to user FRANK01, with a label of "Frank01 Cert," into a data set named PUBLIC.TESTCERT, using DER encoding.

EXPORT FRANK01 LABEL(Frank01 Cert) DSNAME(`PUBLIC.TESTCERT') FORMAT(CERTDER)

The following exports the certificate with a record key of CQLRG.TESTCERT into a data set named CQLRG.TESTCERT.CER, using base-64 encoding.

EXPORT CQLRG.TESTCERT DSNAME(TESTCERT.CER) FORMAT(CERTB64)

The following exports the certificate and private key with a logonid of FRANK01 and a Label of "Frank01 Cert" into a data set named FRANK01.CERT.P12, using base-64 encoding. This PKCS #12 package will also contain the CA certificates that are in the signing chain.

EXPORT FRANK01 DSNAME(`FRANK01.CERT.P12') LABEL(Frank01 Cert) PASSWORD(This is my secret and you don't know it)

GENCERT Subcommand

The GENCERT subcommand is used to generate a digital certificate and insert a CERTDATA profile record into the eTrust CA-ACF2 infostorage database. The GENCERT subcommand can be issued in any mode of the ACF command. It has the following syntax:

GENCert { logonid | logonid.suffix | CERTAUTH | CERTAUTH.suffix | SITECERT | SITECERT.suffix } [Label(label)] [Dsname(data-set-name)] [SUbjsdn([CN=common-name] [T=title] [OU=organizational-unit-name] [O=organization-name] [L=locality] [{S=state-or-province | SP=state-or-province | ST=state-or-province}] [C=country])] [SIZe({key-size|1024})] [ACtive({date-or-date-time|current-date-000000| current-date-time})] [Expire({date-or-date-time|current-date-000000| current-date-time})]

5­14

z/OS and OS/390 Security Cookbook

Processing Digital Certificates with ACF Subcommands

[SIGnwith({ CERTAUTH Label(label-name) | CERTAUTH.suffix | SITECERT Label(label-name) | SITECERT.suffix) | Label(label-name)})] [Keyusage([HANDSHAKE][DATAENCRYPT] [DOCSIGN][CERTSIGN])] [ALtname([IP=numeric-ip-address] [DOMAIN=internet-domain-name] [EMAIL=email-address] [URI=universal-resource-identifier])]

Parameter Descriptions logonid|CERTAUTH|SITECERT-- The logonid specifies the user associated with the certificate. It may be a one to eight-character logonid, or a logonid, a dot, and a one to eight-character suffix. If label is specified, logonid, rather than logonid.suffix, must be specified, and indicates the logonid with which the label is associated. Using CERTAUTH in place of a logonid designates the certificate as a Certification Authority certificate. Using SITECERT in place of a logonid designates the certificate as a site certificate. Label(label)--Specifies a 1 to 32-character label that the new certificate will have. The label can contain blanks and mixed-case characters. If a label is not specified, the label field defaults to the upper-case version of the logonid or logonid.suffix that was specified. Note: For every one apostrophe desired in the Label value, two consecutive apostrophes must be specified. For example, the Label value, Frank's Certificate, should be specified as, Frank"s Certificate. If a single apostrophe is specified in the Label value, the value will be considered invalid. Dsname(data-set-name)--Specifies the data set that contains a PKCS #10 certificate request, as generated by the GENREQ subcommand of the ACF command, or by other certificate management software. If the data set name is enclosed in single quotes, it is considered fully qualified and is used as specified. Otherwise, the user's prefix, as specified by the TSO PROFILE PREFIX command (or defaulted from the DFT-PFX field of the logonid record) is added to the front of the data set name. DSNAME is optional. If specified, GENCERT will not generate a public/private key pair. If specified, SIGNWITH must also be specified because the PKCS #10 request does not contain a private key. If SUBJSDN is also specified, the subject's distinguished name is generated from the SUBJSDN that was entered on the command. If DSNAME is specified and extensions are present within the PKCS #10 request, and they are not overridden by the other GENCERT keywords, they are copied to the new certificate. DSNAME is mutually exclusive with the SIZE keyword.

Digital Certificate Support

5­15

Processing Digital Certificates with ACF Subcommands

SUbjsdn(...attributes...)--Specifies the subject's distinguished name. The attributes can consist of the following fields. Except as otherwise noted, valid characters for the values of the attributes are A through Z, a through z, 0 through 9, space, `,(,),+,comma,-,.,/,:,=,and ?. Values containing spaces must be enclosed in single quotes. Any apostrophes should be doubled. For example, a common name of John T. O'Reiley would be specified as CN='John T. O"Reiley'. Also, unless otherwise specified, each attribute can be specified only once. Note: A space is the only valid delimiter between specified attributes. If the DSNAME keyword is also present, the subject's distinguished name from the SUBJSDN keyword is used instead of the subject's distinguished name from the PKCS #10 certificate request. If neither DSNAME nor SUBJSDN is specified, the subject's distinguished name is generated with CN='ACF2 USER:logonid'.

CN=common-name--Specifies the person's regular name. For example, Sam Smith would be specified as CN='Sam Smith'. T=title--Specifies the person's job title. For example, T='Software Developer'. OU=organizational-unit-name--Specifies the department or group. This can be specified multiple times to indicate a hierarchy. For example, OU=Accounting,OU='Accounts Payable'. O=organization-name--Specifies the name of the company. For example, O='Blue Lock Company'. L=locality--Specifies the city. For example, L='Tom"s River'. S=state-or-province, SP=state-or-province, ST=state-or-province--Specifies the state or province. All three keywords mean the same thing. When the distinguished name is displayed, state or province is displayed using 'ST='. State or province must be expressed using the same abbreviations used in mail addresses, for example, ST=IL for Illinois. C=country--Specifies the country. This must be specified using the two-character ISO 3166 country code. For example, C=US for the United States of America, or C=VA for Vatican City. The codes are available at the ISO 3166 Maintenance Agency web site at:

http://www.din.de/gremien/nas/nabd/iso3166ma/codlstpl/en_listpl.html

SIZe({key-size|1024})--Specifies the size of the private encryption key to be generated, in bits.

512--Specifies a low-strength key 768--Specifies a medium-strength key 1024--Specifies a high-strength key

This keyword is mutually exclusive with the DSNAME keyword.

5­16

z/OS and OS/390 Security Cookbook

Processing Digital Certificates with ACF Subcommands

ACtive({date-or-date-time|current-date-000000|current-date-time})--Indicates the date and time that the certificate becomes active. For example, 04/30/01-154403. If no time is specified, it defaults to 000000. If no date is specified, it defaults to the current day and time. The active date specified must be earlier than the expire date. Expire({date-or-date-time|current-date-000000|current-date-time})--Indicates the date and time that the certificate expires. For example, 04/30/10-154403. If no time is specified, it defaults to 000000. If no date is specified, it defaults to the active day and time plus 1 year. The expire date specified must be later than the active date. SIGnwith({CERTAUTH Label(label-name)|SITECERT Label(label-name)}), SIGnwith({CERTAUTH.suffix |SITECERT.suffix}), SIGnwith(Label(label-name))--Specifies the certificate used to sign the new certificate. If SIGNWITH is not specified, a self-signed certificate is generated. If SIGNWITH contains CERTAUTH or SITECERT, a suffix or Label value is used to specify which CERTAUTH or SITECERT certificate is used to sign the certificate. If CERTAUTH or SITECERT are not specified, Label must be specified and the label will identify the user certificate that will sign the new certificate. The user id associated with the label is the user generating the certificate. This option cannot be specified if the certificate being generated is for a CERTAUTH or SITECERT id. Note: For every one apostrophe desired in the Label value, two consecutive apostrophes must be specified. For example, the Label value, Frank's Certificate, should be specified as, Frank"s Certificate. If a single apostrophe is specified in the Label value, the value will be considered invalid. Keyusage--Specifies the values of the keyUsage certificate extension. The default for certificate authority certificates is CERTSIGN. CERTSIGN is always set for certificate authority certificates even if not specified. There is no default for non-certificate authority certificates.

HANDSHAKE--Sets the digitalSignature and keyEncipherment bits in the keyUsage extension. This allows identification and key exchange during security handshakes such as SSL. DATAENCRYPT--Sets the dataEncipherment bit in the keyUsage extension. This allows the certificate to be used for data encryption. DOCSIGN--Sets the nonRepudiation bit in the keyUsage extension. This allows the certificate to be used in a legally binding signature. CERTSIGN­ Sets the keyCertSign and cRLSign bits in the keyUsage extension. This lets the certificate sign other digital certificates and CRLs.

Digital Certificate Support

5­17

Processing Digital Certificates with ACF Subcommands

When KEYUSAGE is specified and the target ID is CERTAUTH and keyUsage is present in the PKCS #10 request specified in the DSNAME keyword, the request will fail if the certSign bit is turned off in the PKCS #10 request. Otherwise, the keyUsage extension is generated as indicated by the KEYUSAGE parameter. In addition, the certSign and cRLSign bits are turned on if not already specified in the KEYUSAGE parameter. When KEYUSAGE is specified and the target ID is CERTAUTH but keyUsage is not specified in a PKCS #10 request, the extension are generated as indicated by the KEYUSAGE parameter. In addition, the certSign and cRLSign bits are turned on if not already specified in the KEYUSAGE parameter. When KEYUSAGE is specified and the target ID is not CERTAUTH, the keyUsage extension is generated using the attributes specified in the KEYUSAGE parameter. When KEYUSAGE is not specified and the target id is CERTAUTH and keyUsage is present in the PKCS #10 request specified in the DSNAME keyword, the request will fail if the certSign bit is turned off in the PKCS #10 request. Otherwise, the extension is generated using the attributes specified in the keyUsage extension in the PKCS #10 request. When KEYUSAGE is not specified and the target id is CERTAUTH and the DSNAME keyword is not specified, the keyUsage extension is generated by turning on the certSign and cRLSign bits. When KEYUSAGE is not specified and the target id is not CERTAUTH, the extension is generated using the attributes specified in the keyUsage extension in the PKCS #10 request, if present. If the keyUsage extension is not present in the PKCS #10 request or the DSNAME keyword was not specified, the keyUsage extension is not created. ALtname--Specifies the values for the subjectAltName extension. One or more of the values might be specified. The parameter is optional and there is no default. If required, the entered values are converted to ASCII.

IP=numeric-ip-address--Specifies a string containing a fully qualified numeric-ip-address in IPV4 dotted decimal format, which is four decimal numbers between 0 and 255 separated by periods: 141.202.1.255 The maximum field size is 15 bytes. DOMAIN=internet-domain-name--Specifies a fully qualified internet domain name, such as www.ca.com. The validity of this value is not checked. The maximum field size is 255 bytes. EMAIL=email-address--Specifies a fully qualified e-mail address such as [email protected] The maximum field size is 255 bytes.

5­18

z/OS and OS/390 Security Cookbook

Processing Digital Certificates with ACF Subcommands

URI=universal-resource-identifier--Specifies a universal resource identifier such as http://www.ca.com The validity of this field is not checked. The maximum field size is 255 bytes.

Certificate Extensions When a certificate is generated, certain extensions are created. If a PKCS #10 request is passed as input to GENCERT using the DSNAME parameter, certain extensions are copied from the PKCS #10 request. The logic for the keyUsage extension was listed previously under the KEYUSAGE parameter. The following is the logic for the other extension settings: subjectKeyIdentifer--When DSNAME is specified, the subjectKeyIdentifier is copied from the PKCS #10 request, if it is present. If DSNAME is not specified or if the PKCS #10 request does not contain a subjectKeyIdentifer, this extension is created according to Public Key Infrastructure Standards. authorityKeyIdentifier--If SIGNWITH is specified, this extension is created using the subjectKeyIdentifier value in the SIGNWITH certificate. If SIGNWITH is not specified or the SIGNWITH certificate does not contain a subjectKeyIdentifier extension, the authorityKeyIdentifier extension is not created. basicConstraints--When the target ID is CERTAUTH, and basicConstraints is present in the PKCS #10 request, the command fails if the cA Boolean value is false. Otherwise the extension is generated turning the cA bit on. Pathlength is not included. When the target ID is CERTAUTH and basicConstraints is not present in the PKCS #10 request, the extension is generated by turning the cA bit on. Pathlength is not included. When the target ID is not CERTAUTH, and basicConstraints is coded in the PKCS #10 request, basicConstraints is generated using the values set in the PKCS #10 request including the pathLength. If basicConstraints was not present in a PKCS #10 request, the extension is not generated. subjectAltName--When ALTNAME is specified the subjectAltName extension is generated using the ALTNAME values. When ALTNAME is not specified and subjectAltName is present in a PKCS #10 request, the subjectAltName extension is generated using the values present in the PKCS #10 request. If subjectAltName is not present in a PKCS #10 request, the subjectAltName extension is not generated. issuerAltName--When SIGNWITH is specified, the extension is generated using the subjectAltName value of the signing certificate if the extension is present. Otherwise the extension is not created. When SIGNWITH is not specified, the issuerAltName extension is not created.

Digital Certificate Support

5­19

Processing Digital Certificates with ACF Subcommands

GENCERT Examples 1. Generate a self-signed certificate authority certificate from a PKCS #10 request.

gencert certauth.bluelock Subj(CN='Blue Lock Company Certificate Authority' OU='Auditing Department' O='Blue Lock Company' C=US) label(Audit CA) expire(12/31/2020)

This command will generate a self-signed certificate authority certificate. A label, Audit CA, was specified for the record and an expiration date of 12/31/2020. Be sure to place an expiration date on your CERTAUTH certificates. The default is one year from the day you create the record. Subsequent certificates signed with the certificate might get warning messages if the expiration date of the CERTAUTH certificate is not more than a year away. The subject's distinguished name as well as the issuer's distinguished name are generated using the inputted SUBJSDN value. Since the certificate is self-signed, the TRUST flag is automatically set and the serial number is 00. The resulting CERTDATA record would look like this:

CERTDATA / CERTAUTH.BLUELOCK LAST CHANGED BY FRANK01 ON 02/02/02-10:34 ISSUERDN(CN=Blue Lock Company Certificate Authority.OU=Auditing Department O=Blue Lock Company.C=US) CERTNSER(0000000000000001) KEYSIZE(1,024) LABEL(Audit CA) SERIAL#(00) SUBJDN(CN=Blue Lock Company Certificate Authority.OU=Auditing Department.O=Blue Lock Company.C=US) TRUST Certificate is not connected to any key rings

2.

Generate a SITECERT certificate for the company's web server.

gencert sitecert.blcweb Subj(CN='Blue Lock Web Server Certificate' OU='Auditing Department'O='Blue Lock Company' C=US) label(BL Web Server) signwith(certauth Label(Audit CA)) expire(12/31/2020)

This command generated a certificate signed by the CERTAUTH certificate we just created. The serial number and issuer's distinguished name were taken from the signing certificate. We expect the web server to be in place for quite some time so a generous expiration date was also supplied. The resulting CERTDATA record would look like this:

CERTDATA / SITECERT.BLCWEB LAST CHANGED BY FRANK01 ON 02/02/02-11:08 ISSUERDN(CN=Blue Lock Company Certificate Authority.OU=Auditing Department.O=Blue Lock Company.C=US) KEYSIZE(1,024)LABEL(BL Web Server) SERIAL#(01) SUBJDN(CN=Blue Lock Web Server Certificate.OU=Auditing Department.O=Blue Lock Company.C=US)TRUST Certificate is not connected to any key rings

3.

Generate a user certificate, signed with a certificate authority certificate.

gencert frank01.cert Subj(cn='Frank Schwinger' OU='Sales Department' O='Blue Lock Company' C=US) label(Frank01 Cert) signwith(certauth Label(Audit CA)) expire(12/31/2003)

5­20

z/OS and OS/390 Security Cookbook

Processing Digital Certificates with ACF Subcommands

This user certificate is also signed with the Audit CA CERTAUTH certificate. This certificate was given a less generous expiration date. We can renew Frank's certificate if he's still with the company next year. See Certificate Replacement ("Renewal") for more information. The certificate is trusted because the signing certificate is trusted.

CERTDATA / FRANK01.CERT LAST CHANGED BY CUNKE01 ON 02/02/02-11:23 ISSUERDN(CN=Blue Lock Company Certificate Authority.OU=Auditing Department.O=Blue Lock Company.C=US) KEYSIZE(1,024) LABEL(Frank01 Cert) SERIAL#(02) SUBJDN(CN=Frank Schwinger.OU=Sales Department. O=Blue Lock Company.C=US) TRUST Certificate is not connected to any key rings

GENREQ Subcommand

The GENREQ command is used to generate a certificate request to be sent to a Certification Authority. GENREQ extracts the subject's distinguished name and public key from an existing certificate, packages it in PKCS #10 format, signs it with the certificate's private key, base-64 encodes the result, and writes it to a data set. This request is sent to a Certification Authority, which will create a new certificate with the same distinguished name and public key, but issued and signed by the Certification Authority. The GENREQ command can be issued in any mode of the ACF command. It has the following syntax:

GENReq {logonid|logonid.suffix} Dsname(data-set-name) [Label(label)]

logonid|logonid.suffix--Specifies the record key of the certificate to use to obtain the distinguished name and public key for the request, if Label is not also specified. This is a one- to eight-character logonid, or a logonid, a dot, and a one- to eight-character suffix. If Label is also specified, logonid, rather than logonid.suffix, must be specified, and indicates the logonid that the label is associated with. Dsname(data-set-name)--Specifies the name of the data set into which the certificate request is written. The data set must not already exist. If the data set name is enclosed in single quotes, it is considered fully qualified and is used as specified. Otherwise, the user's prefix, as specified by the TSO PROFILE PREFIX command (or defaulted from the DFT-PFX field of the logonid record) is added to the front of the data set name. Label(label)--Specifies the label of the certificate used to obtain the distinguished name and public key for the request. Logonid must also be specified to indicate which logonid the label is associated with. Note: For every one apostrophe desired in the Label value, two consecutive apostrophes must be specified. For example, the Label value, Frank's Certificate, should be specified as, Frank"s Certificate. If a single apostrophe is specified in the Label value, the value will be considered invalid.

Digital Certificate Support

5­21

Processing Digital Certificates with ACF Subcommands

Examples

genreq frank01.cert dsn(TESTREQ.REQ) genreq frank01 label(Frank01 Cert) dsn(`joseph01.testreq2.req')

This command, issued by user FRANK01, generates a certificate request based on the FRANK01.CERT certificate and writes it to a data set named FRANK01.TESTREQ.REQ. The second command shows how a label is used to indicate which one of Frank's certificates is used in the genreq request. The following is an example of a generated request.

Server: CA-SAF REL 1.3 Subject's distinguished name: CN=Frank Schwinger OU=Sales Department O=Blue Lock Company C=US -----BEGIN NEW CERTIFICATE REQUEST----MIIBkwI4AsBf9R0wGwYJKoZIhvcNAQkBFg5kbWFnZWVAbWliLmNvbTEVMBMGA1UE AxMMRGVubmlzIE1hZ2VlMQwwCgYDVQQFEwMwMDExDDAKBgNVBAogA01JQjELMAkG A1UEBjCBnTANBgkqhkiG9w0BAQEFAAOBiwAwgYcCgYEA6SSBPS7HrK1WAOaU3QeN g+F85qvzyPh+VZLhihFR6IdX149OtAIhQFG+479EnpW2prJyjFr2Xd19jV4QxCHZ q8RYeVzU0+lrJPPRHLQGYUdx/lYvGv/LzwZOiWn+OwRdTqkxKTPr/IH0weIXW0Xg j2rhi1YQK8xpm7IpdwEw+eECAQOgADqxBgkqhkiG9w0BAQQDgYEALsTCqYSqfLXH 9aZ8lx1tj0pBcsSIgqKf9BF2KxM2i9PfTxuqnuLt3dQcM/MBJp0oKvFlNaUfevkt 4eoljTkZZ+WBq4s9Lwx7c/K6O9CMGG59j2VvhxRBIbhhzQN1SoOX/tf50y6kQmMP cnUi93gpQIaopR/zQvjJhUN7TZAwUJE -----END NEW CERTIFICATE REQUEST-----

CONNECT Subcommand

The CONNECT subcommand is used to associate certificate information with a key ring. The CONNECT subcommand has the following syntax:

CONnect Certdata(userid1.suffix) Keyring(userid2.suffix) [Ringname(ringname)] [Label(label)] [Usage({PERSONAL|CERTAUTH|SITE})] [DEFAULT]

Parameter Descriptions CERTDATA(userid1.suffix)--Specifies the record key of a CERTDATA record to associate with a key ring. The userid1 is a one to eight-character userid associated with the CERTDATA record. The suffix is one to eight characters used to make the record key unique. The suffix is separated from the userid by a period, and cannot be specified when LABEL is used.

5­22

z/OS and OS/390 Security Cookbook

Processing Digital Certificates with ACF Subcommands

KEYRING(userid2.suffix)--Specifies the record key of a KEYRING record to which the certificate information is to be associated. The userid2 is a one to eight-character userid associated with the KEYRING record. The suffix is one to eight characters used to make the record key unique. The suffix is separated from the userid by a period, and cannot be specified when the RINGNAME parameter is used. RINGNAME(ringname)--Specifies the ring name of a KEYRING record to which the certificate information is to be associated. The ringname can be up to 237 characters in length. LABEL(label)--Specifies the label of a CERTDATA record to associate with a key ring. The label can be up to 32 characters in length. It can contain blanks and mixed-case characters. Note: For every one apostrophe desired in the Label value, two consecutive apostrophes must be specified. For example, the Label value, Frank's Certificate, should be specified as, Frank"s Certificate. If a single apostrophe is specified in the Label value, the value will be considered invalid. USAGE({PERSONAL|CERTAUTH|SITE})--Specifies how the certificate is to be used within the key ring. If USAGE is omitted, the usage associated with the certificate that is being connected is used.

PERSONAL--Specifies that the certificate is to be used as a user certificate. CERTAUTH--Specifies that the certificate is to be used as a certificate authority certificate. SITE--Specifies that the certificate is to be used as a site certificate.

DEFAULT--Specifies that the certificate is to be the default certificate for the key ring. A key ring can have only one default certificate. Examples

acf connect certdata(user02.cert1) keyring(user01.ring) usage(site) default acf connect certdata(user02) label(user02 certificate) keyring(user01) ringname(user01 key ring)

REMOVE Subcommand

The REMOVE subcommand is used to disassociate a certificate from a key ring. The REMOVE subcommand has the following syntax:

REMove Certdata(userid1.suffix) Keyring(userid2.suffix) [Ringname(ringname)] [Label(label)]

Digital Certificate Support

5­23

Associating a Digital Certificate with a User

Parameter Descriptions CERTDATA(userid1.suffix)--Specifies the record key of a CERTDATA record to remove from a key ring. The userid1 is a one to eight character userid associated with the CERTDATA record. The suffix is one to eight characters used to make the record key unique. The suffix is separated from the userid by a period, and cannot be specified when LABEL is used. KEYRING(userid2.suffix)--Specifies the record key of a KEYRING record from which to remove the certificate. The userid2 is a one to eight character userid associated with the KEYRING record. The suffix is one to eight characters used to make the record key unique. The suffix is separated from the userid by a period, and cannot be specified when RINGNAME is used. RINGNAME(ringname)--Specifies the ring name of a KEYRING record from which to remove the certificate. The ringname can be up to 237 characters in length. LABEL(label)--Specifies the label of a CERTDATA record from which to disassociate a key ring. The label can be up to 32 characters in length. It can contain blanks and mixed-case characters. Note: For every one apostrophe desired in the Label value, two consecutive apostrophes must be specified. For example, the Label value, Frank's Certificate, should be specified as, Frank"s Certificate. If a single apostrophe is specified in the Label value, the value will be considered invalid. Examples

acf remove certdata(user02.cert1) keyring(user01.ring) acf remove certdata(user02) label(user02 certificate) keyring(user01) ringname(user01 key ring)

Associating a Digital Certificate with a User

Certificates are associated to eTrust CA-ACF2 users through the use of profile records. The CERTDATA segment of the USER profile identifies an X.509 digital certificate associated with a user. A user can have more than one certificate, but a single certificate cannot be used by more than one user. Profile records are inserted using the userid as the record key with or without a specified label (if no label is specified, one is set by default). The record key can also contain a userid with a distinguished suffix if a user is defined with more than one certificate.

5­24

z/OS and OS/390 Security Cookbook

Associating a Digital Certificate with a User

CERTDATA Profile Data Records

A description of the CERTDATA profile data record fields follows. Record ID recid Fields ACTIVE(date) CERTNSER(hex) DSN(data-set-name) EXPIRE(date) ISSUERDN(dn) LABEL(label) NEWLABEL(label) PASSWORD(password) SERIAL#(serial-number) HITRUST|TRUST|NOTRUST

Field Descriptions recid--Specifies the userid that is to be associated with the certificate. It can be a one to eight-character logonid, or a logonid, a dot, and a one to eight-character suffix. If label is also specified, logonid, rather than logonid.suffix, must be specified, and indicates the logonid with which the label is associated. Using CERTAUTH in place of a logonid designates the certificate as a Certification Authority certificate. Using SITECERT in place of a logonid designates the certificate as a site certificate. Active(date)--Specifies an optional activation date in the format "mm/dd/yy". This date is not the same as the not-before validity date in the certificate itself. This date gives the security administrator the ability to specify when the profile record associating the user to the certificate becomes active. This date must fall within the range of the certificate's not-before and not-after validity dates and must be earlier than the CERTDATA record expiration date, if one exists. CERTNSER(hex value)--Indicates the next serial number to be used by this certificate when signing another certificate. This field cannot be altered, which prevents generation of duplicate certificates. All detected duplicate certificates will be unusable on z/OS and OS/390 systems.

Digital Certificate Support

5­25

Associating a Digital Certificate with a User

Dsn(data-set-name)--Specifies the z/OS or OS/390 dataset that contains the digital certificate that is inserted into a CERTDATA profile record. The data set must be defined as physical sequential (DSORG=PS) and variable-blocked (RECFM=VB) and must be catalogued. If the data set name is enclosed in single quotes, it is considered fully qualified and is used as specified. Otherwise, the user's prefix, as specified by the TSO PROFILE PREFIX command (or defaulted from the DFT-PFX field of the logonid record) is added to the front of the data set name. Expire(date)--Specifies an optional expiration date in the format "mm/dd/yy". This date is not the same as the not-after validity date in the certificate itself. This date gives the security administrator the ability to specify when the profile record associating the user to the certificate expires. This date must fall within the range of the certificate's not-before and not-after validity dates and must be later than the CERTDATA record activation date, if one exists. ISSUERDN(dn)--Specifies that the ISSUERDN is the certification authority's distinguished name as extracted from the certificate. This field cannot be altered. However, it can be used with the SERIAL# operand to list, change, or delete a CERTDATA record. Note: ISSUERDN cannot be abbreviated. Label(label)--Specifies a 32-character label to be associated with the certificate. The label can contain blanks and mixed-case characters. If a label is not specified, the label field will default to the upper-case version of the logonid or logonid.suffix that was specified. Note: For every one apostrophe desired in the Label value, two consecutive apostrophes must be specified. For example, the Label value, Frank's Certificate, should be specified as, Frank"s Certificate. If a single apostrophe is specified in the Label value, the value will be considered invalid. To change the label in a record, the NEWLABEL operand must be used. Note: LABEL cannot be abbreviated on a LIST or DELETE command. NEWLABEL(label)--Specifies the 32-character label, which is to replace an existing label associated with a certificate. The label can contain blanks and mixed-case characters. Note: For every one apostrophe desired in the NEWLABEL value, two consecutive apostrophes must be specified. For example, the NEWLABEL value, Frank's Certificate, should be specified as, Frank"s Certificate. If a single apostrophe is specified in the NEWLABEL value, the value will be considered invalid. NEWLABEL can only be specified on a CHANGE command. If Label rather than NEWLABEL is encountered in the CHANGE command input, a CHANGE using Label request is assumed to be in effect. Password(password)--Specifies the password that was used to encrypt the PKCS #12 certification package. SERIAL#(serial_number)--Specifies the serial number as extracted from the certificate. This field cannot be altered. However, it can be used with the ISSUERDN operand to list, change or delete a CERTDATA record. Note: SERIAL# cannot be abbreviated.

5­26

z/OS and OS/390 Security Cookbook

Associating a Digital Certificate with a User

HITRUST | TRUST |NOTRUST--Specifies a trust status for the certificate. If a trust status is not specified, it is set by default based on the validity of the certificate (self-signed) or, if the certificate was signed by another certificate, the validity of the signing certificate and the private key.

HITRUST indicates that the certificate is both highly trusted and trusted. Any certificate usage applying to trusted certificates applies to highly trusted certificates. However, only certificate authority certificates (CERTAUTH) can be highly trusted. TRUST indicates that the certificate is trusted, i.e., that the certificate is valid for the user, site or certificate authority, and the private key has not been compromised. If no trust status has been specified and the certificate is self-signed, by default, the status will be set to TRUST. If no trust status has been specified and the certificate was signed by another certificate, by default, the status will be set to TRUST only if the following conditions are met: ­ ­ ­ ­ ­ The signing certificate can be located in the database. The signing certificate is a Certification Authority (CERTAUTH). The signing certificate is not expired. The signing certificate's signature is valid. The validity dates of the certificate being added fall within the range of the signing certificate's validity dates.

Otherwise, the certificate will be inserted as not trusted (NOTRUST) and an informational message will be issued stating the reason why. However, if the signing certificate's signature is invalid, the certificate is not inserted. USER certificate--TRUST indicates that the certificate can be used to authenticate a userid. SITECERT certificate--TRUST indicates that the certificate can be used without authenticating it. CERTAUTH certificate--TRUST indicates that the certificate can be used to authenticate other certificates.

NOTRUST indicates that the certificate is not trusted. If NOTRUST is specified or set by default, when the CERTDATA record is displayed, no trust value will be displayed; the trust field will remain blank.

change frank01.mycert NOTRUST CERTDATA / FRANK01.mycert LAST CHANGED BY FRANK01 ON 01/14/02-15:41 ISSUERDN(CN=this is a CA.OU=acf2) LABEL(CERTAUTH.CERT4) SERIAL#(00) SUBJDN(CN=this is a CA.OU=acf2)

Digital Certificate Support

5­27

Associating a Digital Certificate with a User

Creating CERTDATA Profile Records

As part of the INSERT command processing, the certificate is read from the z/OS and OS/390 data set. eTrust CA-ACF2 decodes the certificate to extract the serial number, issuer's distinguished name, and other information and inserts some of this information along with information from the command input into a CERTDATA profile data record. This information can be displayed with the LIST command. Use the following command to enter profile administration mode:

set profile(user) div(certdata)

Use the following commands to create a CERTDATA profile data record:

insert frank01.mycert dsn(`frank01.mycert') active(02/02/02) expire(02/02/03) trust CERTDATA / FRANK01.MYCERT LAST CHANGED BY FRANK01 ON 02/02/02-17:24 ACTIVE(02/02/02) EXPIRE(02/02/03) ISSUERDN(CN=CA cert20) LABEL(FRANK01.MYCERT) SERIAL#(01) SUBJDN(CN=frank01.mycert) TRUST PROFILE

To create a record using logonid and label:

insert frank01 label(mycert) dsn(`frank01.mycert') active(02/02/02) expire(02/02/03) trust CERTDATA / FRANK01.MYCERT LAST CHANGED BY FRANK01 ON 02/02/02-17:24 ACTIVE(02/02/02) EXPIRE(02/02/03) ISSUERDN(CN=CA cert20) LABEL(MYCERT) SERIAL#(01) SUBJDN(CN=frank01.mycert) TRUST PROFILE

Certificate Replacement ("Renewal") As part of the INSERT command processing, a certificate can be replaced without deleting and reinserting it. To replace an existing certificate, make sure that one of the following three cases is satisfied: Case 1. The certificate being added is a duplicate of the existing certificate (i.e., has the same serial number and issuer's distinguished name) and the labels and record keys of both certificates are the same; Case 2. The certificate being added is NOT a duplicate of the existing certificate, has the same subject's distinguished name, issuer's distinguished name, and public key as the existing certificate, the end date and time on the certificate being added is later than on that of the existing certificate, the existing certificate is not expired, and the record keys of both certificates are the same;

5­28

z/OS and OS/390 Security Cookbook

Associating a Digital Certificate with a User

Case 3. The certificate being added is NOT a duplicate of the existing certificate, has the same public key as the existing certificate, there is a private key associated with the existing certificate in the database, the existing certificate is NOT expired, and the record keys of both certificates are the same. Activating New CERTDATA Profile Records Use the following console command to activate a newly created CERTDATA profile data record:

f acf2,rebuild(usr),class(p) f acf2,omvs

Changing CERTDATA Profile Records

Use the following command to enter profile administration mode.

set profile(user) div(certdata)

Use the CHANGE command to change only the following fields in the CERTDATA profile record:

active date - [Active(date)] expire date - [Expire(date)] label - [NEWLABEL(label)] trust status - [HITRUST | TRUST | NOTRUST]

Use the following command to change a single record using record ID:

change frank01.mycert active(02/10/02) expire(02/20/03) newlabel(new certificate) notrust CERTDATA / FRANK01.MYCERT LAST CHANGED BY FRANK01 ON 02/02/02-17:24 ACTIVE(02/10/02) EXPIRE(02/20/03) ISSUERDN(CN=CA cert20) LABEL(new certificate) SERIAL#(01) SUBJDN(CN=frank0l.mycert) PROFILE

Use the following command to change a single record using record ID and label:

change frank01 label(FRANK01.MYCERT) active(02/10/02) expire(02/20/03) newlabel(new certificate) trust CERTDATA / FRANK01 LAST CHANGED BY FRANK01 ON 02/02/02-17:24 ACTIVE(02/10/02) EXPIRE(02/20/03) ISSUERDN(CN=CA cert20) LABEL(new certificate) SERIAL#(01) SUBJDN(CN=frank0l.mycert) TRUST PROFILE

Use the following command to change a single record using SERIAL # and ISSUERDN:

change userid SERIAL#(serial_number) ISSUERDN(dn) active(date) expire(date) newlabel(label) [hitrust|trust|notrust]

Digital Certificate Support

5­29

Associating a Digital Certificate with a User

Use the following command to change multiple records:

change like(frank01.-) active(02/10/02) expire(02/20/03) trust ACF6D071 2 RECORDS CHANGED PROFILE

Note: The label cannot be changed on a multiple (masked) record request. Activating Changed CERTDATA Profile Records Use the following console command to activate a newly changed CERTDATA profile data record:

f acf2,rebuild(usr),class(p) f acf2,omvs

Viewing CERTDATA Profile Records

Use the following command to enter profile administration mode.

set profile(user) div(certdata)

Use the LIST command as follows to view CERTDATA profile records. To list a single record using record ID:

list frank01.mycert CERTDATA / FRANK01.MYCERT LAST CHANGED BY FRANK01 ON 02/02/02-17:24 ACTIVE(02/10/02) EXPIRE(02/20/03) ISSUERDN(CN=CA cert20) LABEL(FRANK01.MYCERT) SERIAL#(01) SUBJDN(CN=frank0l.mycert) PROFILE

To list a single record using record ID and label:

list frank01 label(MYCERT) CERTDATA / FRANK01 LAST CHANGED BY FRANK01 ON 02/02/02-17:24 ACTIVE(02/10/02) EXPIRE(02/20/03) ISSUERDN(CN=CA) LABEL(MYCERT) SERIAL#(01) SUBJDN(CN=frank0l) TRUST PROFILE

Use the following command to list a single record using SERIAL # and ISSUERDN:

list userid SERIAL#(serial_number) ISSUERDN(dn)

5­30

z/OS and OS/390 Security Cookbook

Associating a Digital Certificate with a User

Use the following command to list multiple records:

list like(frank01.-) CERTDATA / FRANK01.MYCERT1 LAST CHANGED BY FRANK01 ON 02/02/02-17:24 ACTIVE(02/10/02) EXPIRE(02/20/03) ISSUERDN(CN=CA cert20) LABEL(FRANK01.MYCERT1) SERIAL#(01) SUBJDN(CN=frank0l.mycert1) TRUST Certificate is not connected to any key rings CERTDATA / FRANK01.MYCERT2 LAST CHANGED BY FRANK01 ON 02/02/02-17:24 ACTIVE(02/10/02) EXPIRE(02/20/03) ISSUERDN(CN=CA cert2) LABEL(FRANK01.MYCERT2) SERIAL#(01) SUBJDN(CN= frank0l.mycert2) TRUST Certificate is not connected to any key rings CERTDATA / FRANK01.MYCERT3 LAST CHANGED BY FRANK01 ON 02/02/02-17:24 ACTIVE(02/10/02) EXPIRE(02/20/03) ISSUERDN(CN=CA cert21) LABEL(FRANK01.MYCERT3) SERIAL#(01) SUBJDN(CN=frank0l.mycert3) TRUST Certificate is not connected to any key rings PROFILE

Deleting CERTDATA Profile Records

Use the following command to enter profile administration mode.

set profile(user) div(certdata)

Use the DELETE command as follows to delete a specific CERTDATA profile record. Use the following command to delete a single record using record ID:

delete frank01.mycert ACF6D073 CERTDATA / FRANK01.MYCERT RECORD DELETED PROFILE

Use the following command to delete a single record using record ID and label:

delete frank01 label(MYCERT) ACF6D073 CERTDATA / FRANK01 RECORD DELETED PROFILE

Use the following command to delete a single record using SERIAL # and ISSUERDN:

delete userid SERIAL#(serial_number) ISSUERDN(dn)

Use the following command to delete multiple records:

delete like(userid.-) ACF6D072 2 RECORDS CHANGED PROFILE

Digital Certificate Support

5­31

Associating a Digital Certificate with a User

Automatic Registration of Digital Certificates

CERTDATA profile records can also be dynamically inserted or deleted through a process known as Automatic Registration of Digital Certificates. An installation-written or vendor-provided CGI program requests automatic registration by invoking a z/OS and OS/390 UNIX callable service. A program of this sort would typically validate a user's digital certificate and then prompt the user for an ID and password, which are then validated by eTrust CA-ACF2. If the validation is successful, the certificate is presented to eTrust CA-ACF2 and a CERTDATA profile record is dynamically created and associated with that user. Dynamically inserted profile records can be distinguished in two ways: first, the record key contains the word AUTOnnn as the suffix, where nnn is a numeric value; second, the DSN field is blank since the certificate was not read from a z/OS and OS/390 data set. A user must be authorized through the SAF FACILITY class before a profile record is dynamically inserted or deleted. The FAC resource rule $KEY values to allow dynamic INSERT and DELETE are:

IRR.DIGTCERT.ADD IRR.DIGTCERT.DELETE

The following is a rule example:

SET RESOURCE(FAC) COMPILE $KEY(IRR) TYPE(FAC) DIGTCERT.ADD UID(userid) ALLOW DIGTCERT.DELETE UID(userid) ALLOW STORE

Note: Ensure that you do not inadvertently allow access to these resources because of masking in your resource rules.

5­32

z/OS and OS/390 Security Cookbook

Associating Multiple Digital Certificates with a User

Associating Multiple Digital Certificates with a User

OS/390 V2R9 and above supports key rings for digital certificates. A key ring lets you associate one or more digital certificates to a particular user (logonid). These are certificates that can be used by the user. The application using the USS R_datalib function can request that eTrust CA-ACF2 pass back one or more trusted digital certificates based on the key ring value passed to it. The application asks for a trusted certificate by supplying a certificate label or the subject's distinguished name, or by requesting the default certificate. If the caller is authorized to make the request, eTrust CA-ACF2 passes back a trusted certificate and the application uses this to validate the user. If the validation fails, the caller can process each certificate in the ring in turn until it finds one that is accepted, or until it has processed all of the certificates in the specified key ring. eTrust CA-ACF2 administers key ring support using profile records. The KEYRING segment of the USER Profile lets you create, change, display, or delete a key ring for a user using the normal INSERT, CHANGE, LIST, and DELETE commands. The key of the record consists of the logonid of the user for whom the key ring is created, and a qualifier to make the record unique.

KEYRING Profile Records

A description of the KEYRING profile data record fields follows: Record ID recid Fields DEFAULT(userid.suffix) RINGNAME(ringname)

recid--This is a one to eight-character userid that is to be associatd with the key ring. A one to eight-character suffix can be appended to the userid to create a unique record key. The suffix must be separated from the userid with a period. DEFAULT(userid.suffix)--Specifies a default certificate for this key ring. The field contains the name of a CERTDATA profile record used to register the digital certificate. Only one default certificate can be specified. The field is optional. The length of the field is 16 characters. RINGNAME(ringname)--Specifies the name of the key ring. This name is used to connect CERTDATA records to the key ring or to remove CERTDATA records from the key ring. The length of the field is 237 characters. This field is required. The following is an example of creating a key ring profile record:

SET PROFILE(USER) DIV(KEYRING) INSERT usera.ring DEFAULT(usera.cert1) RINGNAME(usera's keyring) KEYRING / USERA.RING LAST CHANGED BY SECID01 ON 04/01/02 ­ 14:46 DEFAULT(USERA.CERT1) RINGNAME(USERA'S KEYRING)

Digital Certificate Support

5­33

Mapping Multiple Digital Certificates to a User ID

Once created, the key ring profile can have certificates associated with it. The method of controlling these certificates is by using the CONNECT and REMOVE commands. To add a certificate to a key ring, use the CONNECT command. To delete a certificate from a key ring, use the REMOVE command. There are two required fields used with these commands: CERTDATA--Specifies the key of a CERTDATA record for a specific certificate. This field is required. KEYRING--Specifies the key of the KEYRING profile record being operated on. This field is required. The following is an example of adding a certificate to a key ring and then deleting it from the key ring:

CONNECT CERTDATA(usera.cert2) KEYRING(usera.ring) ACF68011 CERTIFICATE SUCCESSFULLY CONNECTED TO THE KEY RING REMOVE CERTDATA(usera.cert2) KEYRING(usera.ring) ACF68015 CERTIFICATE SUCCESSFULLY REMOVED FROM THE KEY RING

Mapping Multiple Digital Certificates to a User ID

Digital certificates are being used more frequently as a means of identifying users in today's computing environment. As the number of people using certificates grows, so does the amount of work required to manage certificates. One method to manage this workload is the ability to map multiple certificates to a single logonid. This process, referred to as "digital certificate name filtering", is available at z/OS and OS/390 V2R9 and is supported in eTrust CA-ACF2 version 6.3 and above. The CERTMAP and CRITMAP data records in the Global Systems Options (GSO) Record allow mapping of multiple certificates to a single eTrust CA-ACF2 logonid and are discussed below.

Digital Certificate Name Filtering

The filtering process lets a site map any number of certificates to a single logonid using two pieces of information contained in a certificate:

Issuer's Distinguished Name (IDN) Subject's Distinguished Name (SDN)

5­34

z/OS and OS/390 Security Cookbook

Mapping Multiple Digital Certificates to a User ID

The issuer is the certificate authority (CA) that issued the certificate. The subject is the individual to whom the certificate is issued. A distinguished name is the field that contains information that relates to the identity of the issuer or the subject. The identifiers in a distinguished name can include any or all of the following from least specific to most specific (The abbreviation used in the certificate is in parentheses):

Country (C=) State or province (ST=) City or locality (L=) Postal code (PC=) Street (STREET=) Company or organization (O=) Division or organizational unit (OU=) Email address (E=) Title (T=) Common name (CN=)

The filter process lets you define which logonid to assign a particular certificate based on the information contained in a CERTMAP record. For example, assume that we have four certificates created by the same issuer with the IDN containing the values:

OU=CA Class 1.O=CA.L=internet

Assume also that the SDN for each certificate has values as follows:

CN=Bob.OU=LVL2.OU=Support.OU=ACF2.O=CA, Inc CN=Earl.OU=LVL1.OU=Support.OU=ACF2.O=CA, Inc CN=Pearl.OU=LVL1.OU=Support.OU=ACF2.O=CA, Inc CN=Tony.OU=Devlopment.OU=ACF2.O=CA, Inc

If you want to assign a logonid for all level 1 personnel in support for access to the system, you could create a CERTMAP record referencing the logonid TECH01 that contains the values:

OU=LVL1.OU=Support.OU=ACF2.O=CA, Inc

Then, when Earl or Pearl access the system, the filtering process based on the described CERTMAP record would assign the logonid TECH01 as specified in the CERTMAP record.

Digital Certificate Support

5­35

Mapping Multiple Digital Certificates to a User ID

Filtering Logic Processing When a user attempts to access the system using a digital certificate, initACEE processing gets invoked. This processing attempts to make the most specific match it can of a certificate to a logonid. The logic of this processing is as follows: 1. 2. 3. 4. Attempt to match the certificate to an existing CERTDATA record. If no CERTDATA record matches, use the best-fit CERTMAP record that matches both the full IDN and a full or partial SDN. If no CERTMAP record matches step 2, use the best-fit CERTMAP record that matches a full or partial SDN. If no CERTMAP record matches step 3, use the best-fit CERTMAP record that matches a full or partial IDN.

Partial means removing levels of the distinguished name starting with the common or user name (CN=) and working through the filter until a match is found. The IDN or SDN are listed from most specific to least specific. In addition to mapping to a specific logonid, you can use a CERTMAP record to map to multiple logonids. If the filtering process encounters a MULTIID value in the CERTMAP record, this indicates that multiple logonids are involved and determines the actual logonid to be assigned by using system or user variables such as SYSID, APPLID, or an application dependent variable list. The logonid used in this case is found in the CRITMAP record. The processing logic for this is as follows: 1. 2. Find the CERTMAP record as normal. If MULTIID is specified on the CRITMAP record, use system variables (SYSID or APPLID) and/or application defined variables passed on the initACEE call to find a matching CRITMAP record. Assign the logonid specified in the CRITMAP record.

3.

For example, using the certificates that were previously described, assume we want to assign logonids based on the application that the users invoke when they access our site over the internet with a certificate provided by the CA (certificate authority). The internet applications are the WEBINSUR and WEBBANK pages. Using a CERTMAP record and two CRITMAP records, you can assign a different logonid based on the application:

CERTMAP data: IDNFILTR(`L=Internet.O=CA') MULTIID CRITERIA(APPLID=&applid) CRTIMAP data: APPLID(WEBBANK) USER(BANKU) CRITMAP data: APPLID(WEBINSUR) USER(INSURU)

Using these records, eTrust CA-ACF2 assigns the logonid BANKU for the WEBBANK application and the logonid INSURU for the WEBINSUR application.

5­36

z/OS and OS/390 Security Cookbook

Mapping Multiple Digital Certificates to a User ID

Certificate Name Filtering Options (CERTMAP)

Certificate Name Filtering allows the mapping of multiple digital certificates to a single eTrust CA-ACF2 logonid. Optionally, a single digital certificate can be mapped to one of a number of eTrust CA-ACF2 logonids based on the system ID, application ID, or application defined variables. Record ID CERTMAP.recid Fields SDNFILTR(subject's-dist-name-filter) IDNFILTR(issuer's-dist-name-filter) DSN(data-set-name) CRITERIA(criteria-name-template) LABEL(32-byte-label) TRUST|NOTRUST USERID(userid-to-map-to) MULTIID|NOMULTIID

Field Descriptions recid--Specifies the unique one to eight-character name of the record ID. SDNFILTR('subject's-distinguished-name-filter')--Specifies the "significant" portion of the subject's distinguished name. This is the part of the name that is used as a filter when associating a logonid with a certificate. If this field contains blanks, the entire filter must be encased in quotes, otherwise they are not needed. When the CERTMAP record is inserted or changed without the DSN parameter, you must specify the entire portion of the distinguished name to be used as the filter. The format of the subject's-distinguished-name-filter variable is similar to the output displayed when a certificate is displayed with the LIST command. It is an X.509 distinguished name in an address type format:

component.component.component.component...

Or, more specifically:

Qualifier1=node1.qualifier2=node2....qualifiern=noden

For example:

SDNFILTR(`CN=John Jones.OU=Accounts Payable.O=My Company.L=internet')

Digital Certificate Support

5­37

Mapping Multiple Digital Certificates to a User ID

The value specified for SDNFILTR must begin with a prefix found in the following list, followed by an equal sign (X'7E'). Each component should be separated by a period (X'4B'). The case, blanks, and punctuation displayed when the digital certificate information is listed must be maintained in the SDNFILTR. Since digital certificates only contain characters available in the ASCII character set, the same characters should be used for the SDNFILTR value. Valid prefixes are:

COUNTRY STATE/PROVINCE LOCALITY ORGANIZATION ORGANIZATIONAL UNIT TITLE COMMON NAME STREET Address POSTAL CODE (Zip) Specified Specified Specified Specified Specified Specified Specified Specified Specified as as as as as as as as as C= ST= L= O= OU= T= CN= STREET= PC=

A maximum of 255 characters can be entered for SDNFILTR. SDNFILTR is optional if IDNFILTR is specified. If SDNFILTR is not specified, only the issuer's name is used as a filter. SDNFILTR must not be specified with IDNFILTR unless the value of IDNFILTR results in the entire issuer's name being used in the filter. Note that subject's name can be partial but cannot be used in a filter that contains only a partial issuer's name. IDNFILTR('issuer's-distinguished-name-filter')--Specifies the "significant" portion of the issuer's distinguished name that is used as a filter when associating a logonid with a certificate. If this field contains blanks, the entire filter must be encased in quotes; otherwise they are not needed. When the CERTMAP record is inserted or changed without the DSN parameter, you must specify the entire portion of the distinguished name to be used as the filter. The format of the issuer's-distinguished-name-filter variable is the same as the subject's-distinguished-name-filter variable in the SDNFILTR field. See the SDNFILTR field description for a more complete description of the values that are permitted in the filter parameters. A maximum of 255 characters can be entered for IDNFILTR. IDNFILTR is optional if SDNFILTR is specified. If IDNFILTR is not specified, only the subject's name is used as a filter. If IDNFILTR is specified and only a portion of the issuer's name is used as the filter, SDNFILTR must not be specified. If both IDNFILTER and SDNFILTR are specified, the IDNFILTR value does not need to begin with a valid prefix from the list above. This allows the use of certificates from a certificate authority that chooses to include non-standard data in the issuer's distinguished name.

5­38

z/OS and OS/390 Security Cookbook

Mapping Multiple Digital Certificates to a User ID

DSN(data-set-name)--When IDNFILTR, SDNFILTR, or both are specified along with DSN on the CERTMAP record, the value in the filter fields must correspond to a starting point within the respective distinguished name found in the certificate contained in the data set. You should specify enough of the name to precisely identify the starting point for the filter. For example, if the certificate in the data set has the following subject:

CN=John Jones.OU=Accounts Payable.O=My Company.L=internet

and you want all certificates for anyone in:

Accounts Payable

to be selected by this filter. You must specify:

SDNFILTR('OU=Acc')

Without the data set containing the certificate, you need to enter the following to produce the same result:

SDNFILTR(OU=Accounts Payable.O=My Company.L=internet')

When a starting point value is specified for a certificate contained in a data set, there cannot be more than 255 characters between the starting point and ending point of the subject's name in the certificate. CRITERIA(criteria-name-template)--When specified with the MULTIID field, CRITERIA indicates a dynamic user ID mapping. The user ID associated with this mapping profile is based not only on the issuer's distinguished name and the subject's distinguished name found in the certificate, but also on additional criteria. CRITERIA specifies the criteria in the form of one or more variable names, separated by freeform text. These variable names begin with an ampersand (&) and are separated by periods. The freeform text should identify the variables contained in the template:

variable-name1=&name1.variable-name2=&name2

For example, if the application ID and system ID are to be considered in determining the user ID associated with this mapping, the CRITERIA parameter should be specified as follows:

CRITERIA(APPLID=&APPLID.SYSID=&SYSID)

The eTrust CA-ACF2-defined criteria are the application ID (APPLID) and the system ID (SYSID). When a user presents a certificate to the system for identification, the identity of the application (as well as the system the user is trying to access) becomes part of the criteria. The application passes its identity to eTrust CA-ACF2 which determines the system identifier. The system ID is the 4-character value specified for the SID parameter of the SMFPRMxx member of SYS1.PARMLIB. This value is substituted for &SYSID in the criteria.

Digital Certificate Support

5­39

Mapping Multiple Digital Certificates to a User ID

Once the substitution is made, the fully expanded criteria field is used to find a matching profile defined in the CRITMAP GSO records. For example, APPLID=BANKU.SYSID=SYSA is the definition if the application being accessed is BANKU on the SYSA system. You should create a CRITMAP GSO record for this profile. The logonid to be associated with these certificates must be specified as the USERID. The APPLID and SYSID values of the CRITMAP record can be masked so that a record containing APPLID(BANKU) SYSID(*) allows the certificates to be used on any system, rather than just system SYSA. While masking characters can be used in the CRITMAP parameters, they should not be specified in CRITERIA keyword on the CERTMAP GSO record. Criteria names other than APPLID and SYSID are allowed, but are effective in certificate name filtering if the application supplies these criteria names and their associated values to eTrust CA-ACF2 when the user attempts to access the application using a certificate. SYSID is determined by eTrust CA-ACF2, but APPLID must be specified with the initACEE callable service. Criteria names, such as APPLID and SYSID, should only be specified if the application instructs you to do so. A maximum of 255 characters can be entered when specifying the CRITERIA keyword. The values can be entered in any case, but are made upper case by eTrust CA-ACF2 because they must match upper case names in the CRITMAP record to be effective. When specifying the criteria value, note that the maximum length of the APPLVAR field on the CRITMAP record is also 254. The CRITERIA keyword can only be set for MULTIID. LABEL(label-name)--Up to 32 characters can be specified for label-name. It can contain embedded blanks and mixed-case characters. The LABEL field can be used as a record identifier when changing or deleting CERTMAP records. For example, when changing the CERTMAP.INTERNET record, which has a LABEL of A1 to TRUST status, either of the following commands would work.

Change certmap.internet trust Change certmap label(A1) trust

TRUST|NOTRUST--When TRUST or NOTRUST is specified it indicates whether this mapping can be used to associate a logonid to a certificate presented by a user accessing the system. If neither is specified, the default is NOTRUST. USERID(logonid)--Specifies the logonid of the user that is used when a certificate matches this record. MULTIID|NOMULTIID--MULTIID tells eTrust CA-ACF2 to use the values specified for CRITERIA. If MULTIID is specified, then CRITERIA must be specified. If MULTIID is not specified, CRITERIA is ignored and USERID must be specified. The default is MULTIID.

5­40

z/OS and OS/390 Security Cookbook

Mapping Multiple Digital Certificates to a User ID

Example Example 1 shows entering the filter information manually:

SET CONTROL(GSO) INSERT CERTMAP.lvl1 SDNFILTR(OU=LVL1.OU=SUPPORT.OU=ACF2.O=CA, Inc) USER(tech01) SYSA / CERTMAP.LVL1 LAST CHANGED BY SSDRCM ON 02/15/00 ­ 20:04 SDNFILTR(`OU=LVL1.OU=SUPPORT.OU=ACF2.O=CA, Inc') USER(TECH01) NOTRUST

Example 2 shows entering the same information, but using the DSN field with the filter showing the starting point:

SET CONTROL(GSO) INSERT CERTMAP.lvl1 SDNFILTR(OU=LVL1) USERID(tech01) DSN(bobs.cert) SYSA / CERTMAP.LVL1 LAST CHANGED BY SSDRCM ON 02/15/00 ­ 20:04 SDNFILTR(`OU=LVL1.OU=SUPPORT.OU=ACF2.O=CA, Inc') USERID(TECH01) NOTRUST

SHOW CERTMAP--Displays information contained in CERTMAP records as laid out in the internal CERTMAP table. The display first shows data from records that contain both IDNFILTER and SDNFILTER, followed by records with only SDNFILTER, and finally records with only IDNFILTER.

show certmap -- CERTMAP FILTERING TABLES -IDN/SDN FILTERS ---------------

IDN FILTER SDN FILTER Label TRUST USER CRITERIA ================================ ===== ======== ============================== ACF2 DEVELOPMENT Y ACF2DEVL CN=CAI CERT AUTHORITY.OU=ACF2 D EVELOPMENT.O=COMPUTER ASSOCIATE S.L=LISLE.ST=ILLINOIS.C=US OU=ACF2.OU=DEVELOPMENT.OU=COMPU TER ASSOCIATES.L=LISLE.ST=ILLIN OIS.C=US JASMINE II DEVELOPMENT Y JASMINE CN=CAI CERT AUTHORITY.OU=ACF2 D EVELOPMENT.O=COMPUTER ASSOCIATE S.L=LISLE.ST=ILLINOIS.C=US OU=JASMINE II.OU=DEVELOPMENT.OU =COMPUTER ASSOCIATES.L=ISLANDIA .ST=NEW YORK.C=US UNICENTER TNG DEVELOPMENT Y TNG CN=CAI CERT AUTHORITY.OU=ACF2 D EVELOPMENT.O=COMPUTER ASSOCIATE S.L=LISLE.ST=ILLINOIS.C=US OU=UNICENTER TNG.OU=DEVELOPMENT .OU=COMPUTER ASSOCIATES.L=ISLAN DIA.ST=NEW YORK.C=US

Digital Certificate Support

5­41

Mapping Multiple Digital Certificates to a User ID

TOP SECRET DEVELOPMENT

Y

TSSDEVL

CN=CAI CERT AUTHORITY.OU=ACF2 D EVELOPMENT.O=COMPUTER ASSOCIATE S.L=LISLE.ST=ILLINOIS.C=US OU=TOP SECRET.OU=DEVELOPMENT.OU =COMPUTER ASSOCIATES.L=PRINCETO N.ST=NEW JERSEY.C=US

SDN FILTERS -----------

SDN FILTER Label TRUST USER CRITERIA ================================ ===== ======== ============================== ISLANDIA DEVELOPMENT Y DEVL OU=DEVELOPMENT.OU=COMPUTER ASSO CIATES.L=ISLANDIA.ST=NEW YORK.C =US LISLE DEVELOPMENT N DEVL OU=DEVELOPMENT.OU=COMPUTER ASSO CIATES.L=LISLE.ST=ILLINOIS.C=US OU=DEVELOPMENT.OU=COMPUTER ASSO CIATES.L=DALLAS.ST=TEXAS.C=US

DALLAS DEVELOPMENT

Y

DEVL

IDN FILTERS -----------

IDN FILTER Label TRUST USER CRITERIA ================================ ===== ======== ============================== PRIVATE USERS Y OU=CLASS 2 PUBLIC PRIMARY CERTI FICATION AUTHORITY.O=VERISIGN, INC.C=US APPLID=&APPLID.COMPANY=&COMPANY PUBLIC USERS Y OU=CLASS 1 PUBLIC PRIMARY CERTI FICATION AUTHORITY.O=VERISIGN, INC.C=US APPLID=&APPLID

CERTMAP GSO Records The CERTMAP record defines the IDN or SDN filters used to assign a specific logonid to a group of certificates. There is a SHOW CERTMAP command that displays the information contained in the CERTMAP record. See R_cacheserv Cache Names (CACHESRV).

5­42

z/OS and OS/390 Security Cookbook

Mapping Multiple Digital Certificates to a User ID

Examples Example 1 shows entering the filter information manually:

SET CONTROL(GSO) INSERT CERTMAP.lvl1 SDNFILTR(OU=LVL1.OU=SUPPORT.OU=ACF2.O=CA, Inc) USER(tech01) SYSA / CERTMAP.LVL1 LAST CHANGED BY SSDRCM ON 02/15/02 ­ 20:04 SDNFILTR(`OU=LVL1.OU=SUPPORT.OU=ACF2.O=CA, Inc') USER(TECH01) NOTRUST

Example 2 shows entering the same information, but using the DSN field with the filter showing the starting point:

SET CONTROL(GSO) INSERT CERTMAP.lvl1 SDNFILTR(OU=LVL1) USERID(tech01) DSN(bobs.cert) SYSA / CERTMAP.LVL1 LAST CHANGED BY SSDRCM ON 02/15/02 ­ 20:04 SDNFILTR(`OU=LVL1.OU=SUPPORT.OU=ACF2.O=CA, Inc') USERID(TECH01) NOTRUST

Certificate Name Filtering Criteria Mapping (CRITMAP)

Digital certificates can be mapped to one of a number of eTrust CA-ACF2 logonids based on the system ID, application ID, or application-defined variables specified in the CRITMAP record. These records are used in conjunction with the CRITERIA parameter of the CERTMAP GSO records. Record ID CRITMAP.recid Fields APPLID(application-name) SYSTEMID(sysid) APPLVAR(site-variable-list) USERID(userid-to-map-to)

Field Descriptions: recid--Specifies the unique one to eight-character name of the record ID. APPLID(application-name)--Specifies an application ID specified by the application. SYSTEMID(sysid)--Specifies a system ID. The system ID is obtained from the 4-character SID parameter of the SMFPRMxx member of SYS1.PARMLIB. APPLVAR(site-variable-list)--Specifies a list of application-defined variables. For example, (BOBSAPPL=BANKAPP.LEVEL=HIGH). The application-defined variables are passed to eTrust CA-ACF2 on the initACEE callable service along with the certificate identifying the user. APPLVAR has a maximum length of 254. USERID(userid-to-map-to)--Specifies the eTrust CA-ACF2 logonid assigned when matching this CRITMAP record.

Digital Certificate Support

5­43

Mapping Multiple Digital Certificates to a User ID

Example 1 We want all users whose certificate contains an issuer's distinguished name ending in L=Internet to have their logonid selected based on the application that they are accessing. Users accessing the WEBBANK application will be assigned the WEBBANK logonid. Users accessing the WEBINS application will be assigned the INSUREU logonid.

Insert CERTMAP.APPLS IDNFILTR(L=Internet) CRITERIA(APPLID=&APPLID) TRUST Insert CRITMAP.BANK APPLID(WEBBANK) USERID(WEBBANK) Insert CRITMAP.INS APPLID(WEBINS) USERID(INSUREU)

Example 2 We want all users whose certificate contains an issuer's distinguished name ending in L=Internet to have their logonid selected based on the current SYSID and application variable called LEVEL. If the application specified that LEVEL=HIGH and it is running on system A, we'll assign logonid TOPDOG. If the application specified that LEVEL=LOW on system A, we'll assign logonid WORKER. If the request is running on system B, all users should be assigned the logonid named GENERAL.

Insert CERTMAP.APPL2 IDNFILTR(L=Internet) CRITERIA(SYSID=&SYSID.LEVEL=&LEVEL) TRUST Insert CRITMAP.SYSA1 SYSID(SYSA) APPLVAR(LEVEL=HIGH) USER(TOPDOG) Insert CRITMAP.SYSA2 SYSID(SYSA) APPLVAR(LEVEL=LOW) USER(WORKER) Insert CRITMAP.SYSB SYSID(SYSB) APPLVAR(LEVEL=*) USER(GENERAL)

Show CRITMAP--Displays information contained in CRITMAP records as laid out in the internal CRITMAP table. The display shows the record id, SYSID, APPLID, USERID, and associated application variables.

sho critmap -- CRITERIA TABLE -Record key SYSTEMID APPLID USERID APPLICATION VARS ================= ======== ======== ======== ================================= CRITMAP.PUBLIC2 * CICSAPPL PUBLIC2 CRITMAP.PLATINUM CRITMAP.UCCEL CRITMAP.PUBLIC1 * * * HRAPPL HRAPPL WEBAPPL PLATUSER COMPANY=PLATINUM UCCUSER PUBLIC1 COMPANY=UCCEL

5­44

z/OS and OS/390 Security Cookbook

RACF to eTrust CA-ACF2 Translation

RACF uses the RACDCERT command to administer digital certificates. This command allows authorized users to add, list, modify, generate and delete certificates. It can also be used to generate certificate requests. The following are examples of RACDCERT commands and their translation to eTrust CA-ACF2 commands.

RACDCERT Command

Example 1 The following RACDCERT command adds a digital certificate to the RACF database:

RACDCERT ID(JSMITH) ADD(`JSMITH.CLIENT1.P12') WITHLABEL(`Certificate for Jimmy Smith') TRUST PASSWORD(`Jacksonville')

In eTrust CA-ACF2 you would add the same digital certificate in the following manner:

Set profile(user) div(certdata) Insert jsmith.client dsn(`jsmith.client1.p12') label(Certificate for Jimmy Smith) trust Password(Jacksonville)

Example 2 The following RACDCERT command displays the contents of the certificate in the JSMITH.CLIENT1.P12 data set.

RACDCERT CHECKCERT(`JSMITH.CLIENT1.P12') PASSWORD(`Jacksonville')

In eTrust CA-ACF2 you would display the same digital certificate in the following manner:

Chkcert dsn(`jsmith.client1.p12') password(Jacksonville)

Example 3 The following RACDCERT command displays the certificate that was added to the RACF data base:

RACDCERT ID(JSMITH) LIST(LABEL(`Certificate for Jimmy Smith'))

In eTrust CA-ACF2 you would display the CERTDATA record in the following manner:

Set profile(user) div(certdata) List jsmith.client

Digital Certificate Support

5­45

RACF to eTrust CA-ACF2 Translation

The contents of the certificate contained in the CERTDATA record can be displayed as follows:

Chkcert jsmith.client

Example 4 The following RACDCERT command modifies the certificate that was added to the RACF data base:

RACDCERT ID(JSMITH) ALTER(LABEL(`Certificate for Jimmy Smith')) NEWLABEL(`Jimmy Smith Certificate') TRUST

In eTrust CA-ACF2 the same change would be made in the following manner:

Set profile(user) div(certdata) Change jsmith.client newlabel(Jimmy Smith Certificate) trust

Example 5 The following RACDCERT command deletes the certificate that was added to the RACF data base:

RACDCERT ID(JSMITH) DELETE(LABEL(`Jimmy Smith Certificate'))

In eTrust CA-ACF2 the record would be deleted in the following manner:

Set profile(user) div(certdata) Delete jsmith.client

or

delete jsmith label(Jimmy Smith Certificate)

Example 6 The following RACDCERT command generates a self-signed CA certificate to be added to the RACF database:

RACDCERT CERTAUTH GENCERT SUBJECTSDN(CN(`My Company z/OS CA') o(`My Company') ou(`My Dept') l(`My location') sp(`Illinois') c(`US')) size(512) withlabel(`CA certificate for My Company') NOTBEFORE(DATE(2001-09-04)) NOTAFTER(DATE(2005-10-12))

In eTrust CA-ACF2, the following command will generate a self-signed CA certificate that is added to the CA-ACF2 database:

Gencert certauth.cert1 subjsdn(cn=`My Company z/OS CA' o=`My Company' ou=`My Dept' l=`My location' sp=Illinois c=US) size(512) label(CA certificate for My Company) active(2001-09-04) expire(2005-10-12)

5­46

z/OS and OS/390 Security Cookbook

RACF to eTrust CA-ACF2 Translation

Example 7 The following RACDCERT command generates a SITE certificate signed by the CA certificate generated in the previous step:

RACDCERT SITECERT GENCERT SUBJECTSDN(CN(`server.my.company.com') o(`My Company') ou(`My Dept') l(`My location') sp(`Illinois') c(`US')) size(512) withlabel(`Certificate for my server') SIGNWITH(CERTAUTH LABEL(`CA certificate for My Company'))

In eTrust CA-ACF2, the following command will generate the same SITE certificate:

Gencert sitecert.server subjsdn(cn=`server.my.company.com' o=`My Company' ou=`My Dept' l=`My location' sp=Illinois c=US) size(512) label(Certificate for my server) signwith(certauth label(CA certificate for My Company)

Example 8 The following RACDCERT command generates a client certificate signed by an internal CA certificate:

RACDCERT ID(JSMITH) GENCERT SUBJECTSDN(CN(`Jimmy Smith') o(`My Company') ou(`My Dept') l(`My location') sp(`Illinois') c(`US')) size(512) withlabel(`Jimmy Smith Cert') SIGNWITH(CERTAUTH LABEL(`CA certificate for My Company'))

In eTrust CA-ACF2, the following command will generate the same client certificate:

Gencert jsmith.cert subjsdn(cn=`Jimmy smith' o=`My Company' ou=`My Dept' l=`My location' sp=Illinois c=US) size(512) label(Jimmy Smith Cert) signwith(certauth label(CA certificate for My Company))

Example 9 The following RACDCERT command generates a certificate request.

RACDCERT ID(JSMITH) GENREQ(LABEL(`Jimmy Smith Cert')) DSN(`JSMITH.CERT.REQ')

In eTrust CA-ACF2, the following command will generate the same certificate request:

Genreq jsmith.cert dsn(`jsmith.cert.req')

Example 10 The following RACDCERT command generates a certificate from a certificate request.

RACDCERT ID(JSMITH) GENCERT(`JSMITH.CERT.REQ') WITHLABEL(`Jimmy Smith Cert from req') SIGNWITH(CERTAUTH LABEL(`CA certificate for My Company'))

Digital Certificate Support

5­47

RACF to eTrust CA-ACF2 Translation

In eTrust CA-ACF2, the following command will generate the same certificate from a certificate request:

Gencert jsmith.cert2 dsn(`jsmith.cert.req') label(Jimmy Smith Cert from req) signwith(certauth.cert1)

Example 11 The following RACDCERT command exports a certificate and private key to a dataset in DER format.

RACDCERT ID(JSMITH) EXPORT(LABEL(`Jimmy Smith Cert')) DSN(`JSMITH.CERT.P12') FORMAT(PKCS12DER) PASSWORD(`JimmySmith')

In eTrust CA-ACF2, the following command will export the same certificate to the same dataset:

export jsmith label(Jimmy Smith Cert) dsn(`jsmith.cert.p12') format(pkcs12der) password(Jimmy Smith)

Example 12 The following RACDCERT command creates a key ring.

RACDCERT ID(WEBSRV) ADDRING(SERVA)

In eTrust CA-ACF2, the following command creates the same key ring:

Set profile(user) div(keyring) Insert websrv ringname(SERVA)

Example 13 The following RACDCERT command connects a certificate to the key ring

RACDCERT ID(WEBSRV) CONNECT(ID(WEBSRV) LABEL(`Certificate for serva') RING(SERVA) DEFAULT)

In eTrust CA-ACF2, the following command connects the same certificate to the key ring:

Set profile(user) div(keyring) Connect certdata(websrv) label(Certificate for serva) keyring(websrv) ringname(SERVA) default

Alternatively you could enter:

Set profile(user) div(keyring) Connect certdata(websrv.serva) keyring(websrv.serva) default

5­48

z/OS and OS/390 Security Cookbook

Example 14 The following RACDCERT command lists a key ring.

RACDCERT ID(WEBSRV) LISTRING(SERVA)

In eTrust CA-ACF2, either of the following commands will list the key ring:

Set profile(user) div(keyring) list websrv ringname(SERVA) list websrv.serva

Example 15 The following RACDCERT command removes a certificate from a key ring

RACDCERT ID(WEBSRV) REMOVE(ID(WEBSRV) LABEL(`Certificate for serva') RING(SERVA))

In eTrust CA-ACF2, the following command removes the same certificate from the key ring:

Set profile(user) div(keyring) remove certdata(websrv) label(Certificate for serva) keyring(websrv) ringname(SERVA)

Example 16 The following RACDCERT command deletes a key ring.

RACDCERT ID(WEBSRV) DELRING(SERVA)

In eTrust CA-ACF2, the following command deletes the same key ring:

Set profile(user) div(keyring) delete websrv ringname(SERVA)

Example 17 The following RACDCERT command adds a mapping profile that will associate the user ID WEBUSER with all digital certificates issued by VeriSign for Class 1 Individual Subscribers:

RACDCERT ID(WEBUSER) MAP IDNFILTER(`OU=VeriSign Class 1 Individual Subscriber.O=VeriSign, Inc..L=Internet') WITHLABEL(`Savings Account')

In eTrust CA-ACF2, the following command creates the same profile:

Set control(gso) div(certmap)

Insert certmap.webuser idnfiltr(OU=VeriSign Class 1 Individual Subscriber.O=VeriSign, Inc..L=Internet) label(Savings Account) id(webuser)

Digital Certificate Support

5­49

Chapter

6

The CA LDAP Server for OS/390 and z/OS

The eTrust LDAP Server for z/OS and OS/390 provides an inbound Lightweight Directory Access Protocol(LDAP) interface to external OS/390 security managers including eTrust CA-ACF2. eTrust LDAP Server is a protocol that lets you access objects in other databases (such as DB2 or an LDAP directory) or security interfaces (such as eTrust CA-ACF2) and perform authentication or authorization services on them. eTrust LDAP Server provides one interface to access the data in multiple places (such as DB2 and eTrust CA-ACF2). You do not need to know where the actual data is stored; eTrust LDAP Server manages this aspect. CA clients are able to take advantage of these LDAP capabilities using the CA supplied LDAP-compliant directory server for the OS/390 and z/OS platform. The CA LDAP Server for OS/390 and z/OS includes:

Integration with Unicenter Common Services Access control for directory information Strong LDAP server authentication Interoperability with both CA and third party LDAP clients A high-performance repository Integration with the CA eTrust Solution Suite.

Requirements

The following sections list the OS/390 and z/OS installation requirements for CA LDAP Server for OS/390 and z/OS.

The CA LDAP Server for OS/390 and z/OS

6­1

Architectural Overview

OS/390 and z/OS

OS/390 V2R7 or greater eTrust CA-ACF2 Version 6.3 or greater CPS Version 1.0 or greater CPS is the component that will facilitate the communications to the OS/390 and z/OS external security manager from the UNIX System Services (USS) LDAP Server

CA90s Genlevel 9901 or greater or Unicenter Common Services with the following components: ­ ­ ­ ­ CAENF CCITCP and CCITCPGW Spawn Services Viewpoint component

Installation

Windows NT or Windows 2000 Workstation to run installation scripts.

Architectural Overview

The CA LDAP Server for OS/390 and z/OS architecture is a set of layers. Each layer can, in fact, be on different physical machines. The following diagram illustrates the layers between the client application and the OS/390 and z/OS security package.

6­2

z/OS and OS/390 Security Cookbook

LDAP Server Overview

LDAP Server Overview

The LDAP Server runs as a USS process, with a very simple architecture. The following diagram illustrates its server and component:

The CA LDAP Server for OS/390 and z/OS

6­3

CPS Manager Overview

The TCP/IP listener lets an LDAP-aware application from any platform connect to the CA LDAP Server for OS/390 and z/OS. This listener will have the same TCP/IP address that the OS/390 and z/OS host has, and it will have a default port of 389. The LDAP Server includes support for Secure Socket Layer (SSL) connections through the IBM System SSL. When started with SSL support, the ports will default to 389 for unsecured connections and 636 for secured connections. Set these options when starting the LDAP Server. See the CA LDAP Server for OS/390 and z/OS Getting Started Guide for more information about the start up options.

CPS Manager Overview

The CPS architecture includes several pieces. The following diagram illustrates the processes between the CA LDAP Server for OS/390 and z/OS and your CA security product. The SECSRVR started task (STC) pictured below is the actual process that issues the commands to the security database. Start thus with the user ID supplied at LDAP bind time. This layer ensures that all commands are executed under the scope of the user that initiated the request.

6­4

z/OS and OS/390 Security Cookbook

CPS Benefits

CPS Benefits

Using CPS and its interface to CAICCI, CPS lets the LDAP Server route an LDAP request for eTrust CA-ACF2 from one OS/390 or z/OS host to another. This routing lets you configure the LDAP Server so that it and CPS can be on different OS/390 or z/OS hosts. This also means that LDAP Server does not have to run on each OS/390 and z/OS host with a security database. Based on the environment within your company, you can install the components where they can best be managed and where they will give you the best performance possible. Computer Associates has been promoting Unicenter Common Services as the framework to allow integration of OS/390 and z/OS applications with other platforms. With CPS and the CAICCI component of Unicenter Common Services, we are able to let you truly customize how you want to set up your LDAP environment.

CA LDAP Server for OS/390 and z/OS Capabilities

The CA LDAP Server for OS/390 and z/OS is installed into the Hierarchical File System (HFS) and runs as a USS daemon. LDAP Server capabilities include the following.

Databases

eTrust CA-ACF2--A fully functional interface to eTrust CA-ACF2 providing full logon ID (LID) administration including user-defined fields. LDBM--A customizable back-end providing the use of a USS database as the repository for your directory store. LDAP--This configurable back-end lets you configure the LDAP Server to become a client to another LDAP Server. This lets you daisy chain the LDAP Server to others that you might have installed.

Access Controls

Using built-in access controls, you can control access to entries in the databases based on LDAP authentication information. You can supplement these controls using the eTrust CA-ACF2 built-in scope controls.

The CA LDAP Server for OS/390 and z/OS

6­5

CA LDAP Server for OS/390 and z/OS Capabilities

Configuration

There are two ways to configure the LDAP Server:

You can configure the LDAP Server through a single configuration file, slapd.conf, letting you control all options from a single point. You can configure the LDAP Server to run any combination of databases.

Encryption

You can configure the LDAP Server to encrypt all data transmissions between the LDAP clients running on any platform in your organization and the LDAP Server in USS. This encryption is provided using the IBM System SSL for OS/390 and z/OS.

Multiple Instances

Based on the needs of your organization, you can run the LDAP Server three different ways:

Run a single instance of the LDAP Server and access multiple eTrust CA-ACF2 databases. Run multiple instances of the LDAP Server and access multiple eTrust CA-ACF2 databases. With this configuration, you can access the same security database from multiple servers so that you can distribute the load across your OS/390 and z/OS machines. Run multiple instances of the LDAP Server on a single OS/390 and z/OS machine and access multiple eTrust CA-ACF2 databases. With this configuration, you can access the same security database for testing while allowing production applications access at the same time using different configuration options.

eTrust CA-ACF2 Support for OS/390 and z/OS NFS

To define eTrust CA-ACF2 support for OS/390 and z/OS NFS, use the following procedure: 1. Create logonids for the NFS Server, the NFS Client, the NFS Lock Manager (NLM), and the NFS Network Status Monitor (NSM) started tasks:

SET LID INSERT MVSNFS NAME(NFS Server) STC GROUP(OMVSGRP) NON-CNCL INSERT MVSNFSC NAME(NFS Client) STC GROUP(OMVSGRP) INSERT MVSNLM NAME(NFS Lock Manager) STC GROUP(OMVSGRP) INSERT MVSNSM NAME(NFS Network Status Monitor) STC GROUP (OMVSGRP)

6­6

z/OS and OS/390 Security Cookbook

IBM LDAP Server Support

2.

Create user profile records for each of the started tasks. These logonids require a UID(0).

SET PROFILE(USER) DIV(OMVS) INSERT MVSNFS UID(0) HOME(/u/mvsnfs) PROGRAM(/bin/sh) INSERT MVSNFSC UID(0) HOME(/u/mvsnfsc) PROGRAM(/bin/sh) INSERT MVSNLM UID(0) HOME(/u/mvsnlm) PROGRAM(/bin/sh) INSERT MVSNSM UID(0) HOME(/u/mvsnsm) PROGRAM(/bin/sh)

Note: At eTrust CA-ACF2 6.4 and above, the PROGRAM field in the user profile record has been renamed to OMVSPGM. 3. If the group assigned to these started tasks has not been previously created, create a group profile record:

SET PROFILE(GROUP) DIV(OMVS) INSERT OMVSGRP GID(nn)

4.

The logonids associated with the started tasks require access to data sets that the remote users are accessing. Ensure that these logonids have the appropriate authority to access these data sets. To activate the changes made for NFS, issue the following commands:

F ACF2,REBUILD(USR),CLASS(P) F ACF2,REBUILD(GRP),CLASS(P) F ACF2,OMVS

5.

IBM LDAP Server Support

IBM provides a Lightweight Directory Access Protocol (LDAP) Server with OS/390 V2R5 and above that is based on a client/server model of communication that provides client access to an LDAP server. The LDAP server uses a DB2-based file to store information. An LDAP directory provides a method to maintain directory information, such as e-mail accounts, in a central location for storage, update, retrieval, and exchange. To set up the OS/390 and z/OS LDAP Server with eTrust CA-ACF2, use the following steps: 1. 2. Define a started task logonid for the LDAP server.

INSERT LDAPSRV NAME(LDAP SERVER ID) STC GROUP(LDAPGRP)

Set up the OMVS profile for this logonid so that it uses UID(0) for superuser authority.

SET PROFILE(USER) DIV(OMVS) INSERT LDAPSRV UID(0) HOME(/)

3.

Set up the OMVS group profile for the group assigned to the LDAPSRV logonid if not already in existence:

SET PROFILE(GROUP) DIV(OMVS) INSERT LDAPGRP GID(nn)

The CA LDAP Server for OS/390 and z/OS

6­7

IBM LDAP Server Support

4.

Add or update the FACILITY resources so that the LDAP server has READ access to BPX.DAEMON and UPDATE access to BPX.SERVER.

SET RESOURCE(FAC) COMPILE $KEY(BPX) TYPE(FAC) DAEMON UID(ldapsrv) SERVICE(READ) ALLOW SERVER UID(ldapsrv) SERVICE(READ,UPDATE) ALLOW

Note: If the BPX rule set already exists, add the two rule lines for the LDAPSRV logonid to the existing rule set. 6. Give read access to the data sets in the LDAP server STC JCL.

6­8

z/OS and OS/390 Security Cookbook

Chapter

7

Logging UNIX System Services (USS) Security Calls

To monitor user activity in a UNIX System Services (USS) environment, eTrust CA-ACF2 logs security events under USS to SMF using the standard eTrust CA-ACF2 SMF record. Log records are written for any security event that denies the user access to a USS facility. These records can assist you in determining the UID and GID of the user involved in the attempted access.

Setting Attributes

Turning on the user or auditor logging or audit options in an HFS file can also cause logging. The owner of the file can set the user audit attribute of the file. The auditor option can also set an audit attribute, but, in release 6.2, requires the eTrust CA-ACF2 AUDIT privilege to do this (In release 6.3, this function requires the eTrust CA-ACF2 SECURITY privilege). Each of these attributes is set based on the access being attempted to the file. If these AUDIT attributes or flags are turned on in a file for the type of file access, eTrust CA-ACF2 logs that access by writing an SMF record. These SMF records can be viewed on the ACFRPTOM report.

The ACFRPTOM Report

The eTrust CA-ACF2 report ACFRPTOM uses standard eTrust CA-ACF2 report JCL like the following for batch submission:

//ACFRPTOM JOB //* //REPORT EXEC //* //SYSPRINT DD //SYSUDUMP DD //RECMAN1 DD //SYSIN DD // 1,'USS RPT',MSGCLASS=A,TYPRUN=HOLD PGM=ACFRPTOM,PARM=`TITLE(USS EVENTS)' SYSOUT=* SYSOUT=* DSN=SYS1.MAN1,DISP=SHR DUMMY

See the Reports and Utilities Guide for more information.

Logging UNIX System Services (USS) Security Calls

7­1

The ACFRPTOM Report

ACFRPTOM Parameters

The ACFRPTOM report uses the following parameters common to all eTrust CA-ACF2 reports:

EDATE ETIME LINECNT SDATE STIME SELECT SYSID TITLE

For descriptions and default values for these parameters, see the "General Information" chapter in the Reports and Utilities Guide.

ACFRPTOM Specific Parameters

The following parameters are specific to ACFRPTOM: UID(value)--Specifies the USS UID for which you want to collect security information. Acceptable numeric values range from zero to 2,147,483,647. This field is not maskable. GID(value)--Specifies the USS GID for which you want to collect security information. Acceptable numeric values range from zero to 2,147,483,647. This field is not maskable. USER(logonid)--Specifies the logonid for which you want USS security information collected. This field is not maskable. GROUP(groupname)--Specifies the group for which you want USS security information collected. This field is not maskable.

Service Specifies the name of the SAF callable service for which you want security information collected. See the IBM OS/390 Security Server (RACF) Callable Services guide for detailed information on these services. Possible values for this field include:

Service Field Values ck_access ck_file_owner ck_IPC_access

Description Check access Check file owner Check IPC access

7­2

z/OS and OS/390 Security Cookbook

The ACFRPTOM Report

Service Field Values ck_owner_2_files ck_priv ck_process_owner clear_setid deleteUSP getGMAP get_uid_gid_supg getUMAP initACEE initUSP mMakeFSP makeISP make_root_fsp query_file_opts query_sys_opts R_admin R_audit R_cacheserv R_chaudit R_chmod R_chown R_dceauth R_dceinfo R_dcekey R_dceuid R_exec R_fork R_getgroups R_getgroupsbynam R_IPC_ctl

Description Check owner of two files Check privilege Check process owner Clear set ID Delete USP Get GID-to-group-name mapping Get UIDs, GIDs, and supplemental groups Get UID-to-user-ID mapping Initialize ACEE Initialize USP Make IFSP Make IISP Make root IFSP Query file security options Query system security options RACF administration API Provide an audit interface Call for cache services Change audit options Change file mode Change owner and group Check a user's authority Retrieve or set user fields Retrieve or set a DCE password Determine the ID of a client Set effective and saved UIDs/GIDs Fork a process Get/Set supplemental groups Get groups by name Perform IPC control

Logging UNIX System Services (USS) Security Calls

7­3

The ACFRPTOM Report

Service Field Values R_Kerbinfo R_PKIServ R_ptrace R_setegid R_seteuid R_setfacl R_setgid R_setuid R_umask R_usermap

Description Retrieve or set Kerberos fields Digital Certificate processing Ptrace authority check Set effective GID, set all GIDs Set effective UID, set all UIDs Create or modify ACLs Set group ID Set UID Set file mode creation mask Map application user

For more information about these values, see Service Field Values later in this chapter. SUMMARY|DETAIL--Specifying the default value SUMMARY produces a three-line entry for each event logged. Specifying DETAIL produces report entries that include all the information available for each logging event. ERROR--Specifying ERROR restricts the output of the report to include only entries for services that ended with a SAF RC greater than zero. This helps produce a report that is easier to read when attempting to resolve an OMVS setup problem. The default is to report on all SMF records that have been written.

7­4

z/OS and OS/390 Security Cookbook

Sample ACFRPTOM Output

Sample ACFRPTOM Output

The following illustration shows the logging of security events in a USS environment:

110/28/99 99.301 SERVICE DATE 15.15 - OMVS LOGGINGS USERID GROUP UID TIME JOBNAME SOURCE GID SYSID 0 XE41 0 SAF RC CPU 0 XE41 8 RSN 8 PAGE 1

INIT_USP USER01 OMVGROUP 10/13/99 99.286 21.27.15 USER01 Failed - User not defined as OpenMVS user INIT_USP USER01 OMVGROUP 10/13/99 99.286 21.27.16 USER01 Failed - User not defined as OpenMVS user

20

XE41

0 8 XE41 10 XE41 0

8

20

INIT_USP USER01 OMVGROUP 1025 10/13/99 99.286 21.30.10 USER01 XE41 Successful - Logging active by Trace/Audit options Home : /u/user01 Program : /bin/sh DELETE_USP USER01 OMVGROUP 0 10/13/99 99.286 21.34.07 USER01 XE41 Successful - Logging active by Trace/Audit options

0

0

0 XE

0

0

0

CHECK_ACCESS USER01 OMVGROUP 1025 10 10/13/99 99.286 22.03.11 USER01 XE41 XE41 Successful - Logging active by Trace/Audit options Function: opendir User Type: Local Requested Access: Search Pathname: /u/user02/ Filename: /ROOT File Permissions: Owner: rwx Group: r-- Other: --Owning UID: 0 Owning GID: 0 Volume : SMS001 File Identifier: 000104000000000003 File Audit Options: User : Read Failure Write Failure Exec/Search Failure Auditor : Read Failure Write Failure Exec/Search Failure

0

0

0

This sample output was run with the DETAIL option and shows three log entries for INIT_USP requests, one entry for a DELETE_USP request, and one entry for a CHECK_ACCESS request.

Field Descriptions

Different information is logged for different types of requests.

INIT_USP and DELETE_USP requests result in three-line log entries: the first two lines consist of field information; the third line is a text explanation. The CHECK_ACCESS request results in a log entry that consists of three lines plus additional lines of information about the request.

Descriptions of these entries follow. Included are descriptions of the security services and fields that can show up on the ACFRPTOM when DETAIL is specified.

Logging UNIX System Services (USS) Security Calls

7­5

Sample ACFRPTOM Output

SERVICE--The type of service requested. See the list of possible service requests you might see in this field and a brief description of each in the Service Field Values section. USERID--The logonid of the user for which the request was made. GROUP--The GROUP with which the user is associated. UID--The OMVS UID number of the user. GID--The OMVS GID number of the user. SAF--The SAF return code. For all services:

0--Successful completion 4--eTrust CA-ACF2 not active 8--Request denied. See explanation line. 0--Successful completion 8--Request denied. See explanation line.

RC--The eTrust CA-ACF2 return code. For all services:

RSN--The SAF reason code. See explanation line. DATE--The Julian or Gregorian date when the access was attempted. The format of the Gregorian date is mm/dd or dd/mm, depending on the DATE option in the GSO OPTS infostorage record. TIME--The time of day when the access attempt occurred. JOBNAME--The name of the job under which the access was issued. SOURCE--The logical input source from which the request was issued. SYSID--The eTrust CA-ACF2 system ID associated with the logging records. CPU--The SMF name of the CPU that validated the request. EXPLANATION LINE--A text explanation of the return and reason codes for this call. It tells whether the request failed or succeeded and provides a brief explanation of the disposition. Failed request messages are customized to reflect the reason for the failure. Successful requests look like this: Successful - Logging active by Trace/Audit options

7­6

z/OS and OS/390 Security Cookbook

Service Field Values

Service Field Values

Possible values for the SERVICE field of the ACFRPTOM report follow. These values are case-sensitive. Additional information that can appear on the report for each request when the DETAIL option is specified is a function of the particular call being made. See the next section, Security Credentials and File Security Packets, for more information. ck_access--Determines if a user has the requested access (READ, WRITE, EXECUTE or SEARCH) to the specified file or directory. ck_file_owner--Checks if a current process is a superuser or the owner of the specified file. A process could be the owner of a file if the effective UID is equal to the file owner's UID. ck_IPC_access--Determines whether the current process has the requested access to the interprocess communication (IPC) key or identifier whose IPC security packet (IISP) is passed. ck_owner_2_files--Checks whether the calling process is a superuser or is the owner of the file/directory, or directory/directory entry pair represented by input FSP1 and FSP2. A process is the owner of the file if the processes effective UID id equal to the file's owner UID. ck_priv--Determines if the calling process is a superuser. ck_process_owner--Checks to see if the calling process is the owner of a process being called. clear_setid--Clears temporary access that has been given to a file or directory (that is, resets the S_ISUID, S_ISGID and S_ISVTX bits in the file's or directory's access permissions back to zero. For more information about these bits, see the OS/390 UNIX System Services User's Guide. deleteUSP--Indicates that the user's access to USS terminated. getGMAP--Indicates that a call was made to determine the GID for a groupname or the groupname for a GID. get_uid_gid_supg--Gets the real, effective, and saved UIDs and GIDs, and the supplemental groups from the USP. getUMAP--Indicates that a call was made to determine the UID for a username or the username for a UID. initACEE--Provides an interface for creating and managing security contexts created through the pthread_security_np service.

Logging UNIX System Services (USS) Security Calls

7­7

Service Field Values

initUSP--Indicates initial user access to USS.

Home--the home directory of the user at initial access to USS. Program--the name of the program for the indicated user at initial access to USS. File Type--the file type of the file for which the FSP is being created. It tells whether a file is a directory, a regular file or one of several special types of files. File Permissions--the file access permissions to be assigned to the indicated file. These are displayed in the fields named Owner, Group, and Other. Values for the fields are r for READ, w for WRITE, x for EXECUTE, and s for SEARCH. For more information about file permissions, see the OS/390 UNIX System Services User's Guide.

makeFSP--Seen when a file or directory is created.

makeISP--Builds an IISP in the area provided by the caller. make_root_fsp--Indicates that a new file system is being initialized in a new PDSE/x data set. query_file_opts--Indicates that file security options were queried to determine the settings. query_sys_opts--Indicates that system security options were queried to determine the settings. R_admin--Enables applications to construct a data field name parameter list to manage RACF user profiles in the RACF database. In addition, this service also allows applications to pass RACF TSO administrative command images to RACF. Any output resulting from RACF's processing of the profile administration request is returned to the caller in virtual storage. This callable service does not support the following RACF commands: BLKUPD, RACLINK, RVARY, DISPLAY, RESTART, SET, SIGNOFF, STOP, and TARGET. R_audit--A record cut in addition to a security service record; it supplies additional information about the file being audited. R_cacheserv--Indicates a call was made for cache services. A cache is stored in a data space and contains security information. The cache functions are:

START--Start a new cache. ADD--Add a record to the new cache. END--End cache creation. FETCH--Fetch a record from the cache. DELETE--Delete the cache.

7­8

z/OS and OS/390 Security Cookbook

Service Field Values

R_chaudit--Indicates that a file's Audit Options have been changed. See FILE AUDIT OPTIONS in the Security Credentials and File Security Packets section next for more information.

User Audit Options--indicates what type of user access to this file should be audited. Auditor Audit Options--indicates what type of auditor access to this file should be audited. File Type--The file type of the file whose permissions are being changed. It indicates if a file is a directory, a regular file or one of several special types of files. File Permissions--the file access permissions assigned to the indicated file. These are displayed in the fields named Owner, Group, and Other. Values for the fields are r for READ, w for WRITE, x for EXECUTE, and s for SEARCH. UID To Be Set--the UID number to which the file's owning UID is being set. GID To Be Set--the GID number to which the file's owning GID is being set.

R_chmod--Indicates a file's permissions (mode) have been changed.

R_chown--Changes a file's owning UID and GID to a new value.

R_dceauth--Enables an application server to check a user's authority to access an eTrust CA-ACF2 defined resource. It is intended to be used only for the USS kernel on behalf of an application server. R_dceinfo--Retrieves or sets fields in the DCE USER profile record. R_dcekey--Enables OpenEdition DCE to retrieve or set a DCE password (key). R_dceuid--Enables OpenEdition DCE to determine the user ID of the client from the string forms of the client's DCE UUID pair. R_exec--Changes the effective and saved UID or GID or both.

Set UID--change made to UID. Set GID--change made to GID.

R_fork--Indicates that a call was made to get the security information for a forked process. R_getgroups--Indicates that a call was made to determine what groups the current process or user belongs to. R_getgroupsbynam--Indicates that a call was made to determine the groups to which a specific userid belongs. R_IPC_ctl--Performs functions based on a function code.

Logging UNIX System Services (USS) Security Calls

7­9

Service Field Values

R_kerbinfo--Retrieves or sets SecureWay Security Server Network Authentication Service fields. The service returns principal or realm information and updates the count of invalid attempts at accessing the SecureWay Security Server Network Authentication Service. The invalid key count is also cleared upon successful access to the service. R_PKIServ--Allows applications to request the generation, retrieval, and administration of V3 X.509 digital certificates. R_ptrace--Indicates that a check was made to see if a calling process can ptrace a target process it is calling. R_setegid--Changes the effective GID to a different GID.

GID To Be Set--the GID that is to be set as the effective GID. Real GID--the actual GID of this user. Effective GID--the GID under which this user's accesses are being validated. Saved GID--internally used GID OPTYPE--The type of operation performed: Add, Modify or Delete. ACLTYPE--The type of ACL affected: Access, Directory Model, or File Model. UID/GID--The UID or GID for this ACL entry. PERM--The octal value of the file permissions specified for this user or group. If PERM=DEL the ACL entry for the specified UID/GID is deleted. UID To Be Set--the UID that is to be set as the effective UID. Real UID--the actual UID of this user. Effective UID--the UID under which this user's accesses are being validated. Saved UID--internally used UID. GID To Be Set--the GID that is to be set as the current GID. Real GID--the actual GID of this user. Effective GID--the GID under which this user's accesses are being validated. Saved GID--internally used GID.

R_setfacl--Indicates a call was made to create or modify an Access Control List.

R_seteuid--Changes the effective UID to a different UID.

R_setgid--Changes the real, effective and saved GIDs to a different GID.

7­10

z/OS and OS/390 Security Cookbook

Security Credentials and File Security Packets

R_setuid--Changes the real, effective and saved UID to a different UID.

UID To Be Set--the UID that is to be set as the current UID. Real UID--the actual UID of this user or process. Effective UID--the UID under which this user's accesses are being validated. Saved UID--internally used UID.

R_ticketserv--This service enables application servers to parse or extract principal names from a GSS-API context token. This enables an application server to determine the client principal who originated an application-specific request when the request includes a GSS-API context token. R_umask--Change of permissions that a program sets in a new file or directory when it creates a new file or directory. R_usermap--Enables OS/390 and z/OS application servers to determine the application user identity associated with an eTrust CA-ACF2 logonid, or to determine the eTrust CA-ACF2 logonid associated with an application user identity or digital certificate. Currently, the only supported applications are Lotus Notes for OS/390 and z/OS and Novell Directory Services.

Security Credentials and File Security Packets

Many log entries show additional information about the request. The information is contained internally as Security Credentials (CRED) and File Security Packets (FSP). This information is common to many calls and can appear in the following fields on the ACFRPTOM report if it is available: FUNCTION--The function attempted for a file or directory, such as OPEN, SEARCH, and so forth. PATHNAME--The full pathname of a file or directory, including the file or directory name itself. There could be two pathnames specified if the call involved more than one file or directory. FILENAME--The name of a file or directory. In the case of a ck_access, this field names the part of the path currently being validated for access (that is, if the path is aa/bb/cc then three separate ck_access calls would be seen: the first with a filename of aa, the second with a filename of bb, and a third with the filename of cc ). There can also be two filenames specified if the call involved more than one file or directory. FILE PERMISSIONS--Access permissions for the file's owning UID (owner), the file's owning GID (group) and all others attempting access (other). OWNING UID--UID of the owner of the file or directory. If the real UID of a user/process attempting access to this file matches the owning UID, then access is granted according to the owner file permissions.

Logging UNIX System Services (USS) Security Calls

7­11

Selective SMF Logging Options for USS

OWNING GID--GID of the owner of the file or directory. If the real GID of a user/process attempting access to this file matches the owning GID, then access is granted according to the group file permissions. If the process/user does not have the owning GID as its primary GID, but has a supplemental group that matches the owning GID, then access will also be determined by the group file permissions. Note: If neither the GID nor UID match the owner's GID or UID, then the "other" file permissions are used to determine access. VOLUME--Volume on which the file system that contains the file resides. FILE IDENTIFIER--In some cases there can be no Pathname or Filename indicated in a call. In this case, access is validated by using the File Identifier. To determine what the Path and Filename are for this call, find the last previous call with the same File Identifier. The Pathname and Filename for that call are the same as for the call in question. FILE AUDIT OPTIONS--There are two types of file audit options:

User--indicates the type of file access that should be logged for a user. For example, if the report shows "Read Failure, Write All, Exec/Search None," it means that all failed READ attempts, all WRITEs, but no EXECs or SEARCHes are to be logged to SMF for the user. Auditor--indicates the type of file access that should be logged for an auditor. For example, if the report shows "Read Failure, Write All, Exec/Search None," it means that all failed READ attempts, all WRITEs, but no EXECs or SEARCHes are to be logged to SMF for the auditor.

Selective SMF Logging Options for USS

Normally eTrust CA-ACF2 logs certain callable services or USS events to the SMF log. With the introduction of the UNIXOPTS GSO record in release 6.3 of eTrust CA-ACF2, you now have the ability to selectively control which USS events are logged by eTrust CA-ACF2. There are seven parameters or options in the UNIXOPTS record that determine whether USS events within certain categories are logged to create an audit trail or whether these events are ignored. These parameters and the events that they cover are detailed below. DIRACC|NODIRACC--Specifies if SMF records are to be cut for UNIX system services that control access checks for read/write access to directories. Some of the functions that access directories with read or write access are open, opendir, rename, rmdir, mount, mkdir, link, mknod, getcwd, and vlink. The Security Server callable services that control cutting this SMF record are ck_access and ck_owner_2_files.

7­12

z/OS and OS/390 Security Cookbook

Selective SMF Logging Options for USS

DIRSRCH|NODIRSRCH--Specifies if SMF records are to be cut for UNIX system services that control directory searches. Some of the functions that search directories are chmod, chown, chaudit, getcwd, link, mkdir, open, opendir, stat, ttyname and vlink. The Security Server callable service that controls cutting this SMF record is ck_access. Be aware that auditing directory searches will generate an extremely large amount of SMF records in a short period of time. FSOBJ|NOFSOBJ--Specifies if SMF records are to be cut for UNIX system services that control the auditing of the creation and deletion of system objects. It also cuts SMF records for all access checks except directory searches. Some of the functions that will do this are chdir, link, mkdir, open, mount, rename, rmdir, symlink, vmakedir, and vcreate. The Security Server callable services that control cutting of this SMF record are ck_access, ck_owner_2_files, ckpriv, makeFSP, make_root_fsp, makeISP, and R_audit. FSSEC|NOFSSEC--Specifies if SMF records are to be cut for UNIX system services that control the auditing of changes to the security data (FSP) for file system objects. Some of the functions that modify the FSP are chaudit, chmod, chown, chattr, write, fchaudit, fchmod, and setfacl. The Security Server callable services that control cutting of this SMF record are R_chaudit, R_chown, R_chmod, clear_setid, and R_setfacl. IPCOBJ|NOIPCOBJ--Specifies if SMF records are to be cut for UNIX system services that control the auditing of the access control, IPC object changes and the creation and deletion of IPC objects. Some of the functions that will do this are msgctl, msgget, msgsnd, semctl, semget, semop, shmat, shmget and shmctl. The Security Server callable services that control cutting of this SMF record are ck_IPC_access, R_IPC_ctl, and makeISP. PROCACT|NOPROCACT--Specifies if SMF records are to be cut for UNIX system services that control the auditing of services that look at data from or effect other processes. Some of the functions that effect other processes are getpsent, kill, ptrace, recv, recvmsg and sendmsg. The Security Server callable services that control cutting of this SMF record are ck_process_owner and R_ptrace. PROCESS|NOPROCESS--Specifies if SMF records are to be cut for UNIX system services that control the dubbing and undubbing of processes, changes to the UIDs and GIDs of processes, and changes to the thread limits and other privileged options. Some of the functions that dub processes or change process values are exec, setuid, setgid, seteuid, setegid, dub, undub, and vregister. The Security Server callable services that control cutting of this SMF record are R_exec, R_setuid, R_setgid, R_seteuid, R_setegid, ck_priv, initACEE, initUSP, and deleteUSP. There are a number of USS events that eTrust CA-ACF2 is currently not logging. These are: getMAP, query_file_opts, query_sys_opts, R_admin, R_dceauth, R_dceinfo, R_dcekey, R_dceruid, R_fork, R_getgroups, R_getgroupsbynam, R_umask, and R_usermap.

Logging UNIX System Services (USS) Security Calls

7­13

Appendix

A

RACF to eTrust CA-ACF2 Translation

Many applications and products describe the setup for external security in RACF terms. This appendix describes RACF terminology so that an eTrust CA-ACF2 administrator can create the necessary eTrust CA-ACF2 records. For information about a particular product not covered here, contact eTrust CA-ACF2 Level 1 Technical Support.

RACF Segments and ACF2 Profiles

User related information is stored by RACF in various database segments. eTrust CA-ACF2 accomplishes this using the LOGONID and PROFILE records. The table below lists the RACF segments and where the corresponding information is stored in eTrust CA-ACF2. LOGONID indicates that the information is stored in the logonid record. PROFILE indicates that the information is in a separate profile record. PROFILE* indicates that the information is in a separate profile record, but that optional default data is stored in an Information Storage record pointed to by the SMSINFO field in the logonid record. eTrust CA-ACF2 Equivalent PROFILE PROFILE PROFILE* PROFILE LOGONID or PROFILE PROFILE PROFILE PROFILE

RACF Segment CERTDATA DCE DFP DLFDATA CICS KEYSMSTR LANGUAGE NETVIEW

Profile Name USER USER DATASET DLFCLASS USER KEYSMSTR USER USER

Segment CERTDATA DCE DFP DLFDATA CICS SSIGNON LANGUAGE NETVIEW

RACF to eTrust CA-ACF2 Translation

A­1

RACF Segments and ACF2 Profiles

RACF Segment OMVS OPERPARM SESSION TSO BASE WORKATTR

eTrust CA-ACF2 Equivalent PROFILE PROFILE PROFILE LOGONID LOGONID PROFILE

Profile Name USER GROUP USER APPCLU

Segment OMVS OMVS OPERPARM SESSION

USER

WORKATTR

BASE and TSO Segment Considerations

This section describes the BASE and TSO segments. The data for fields within these segments is within the eTrust CA-ACF2 logonid record. The tables in the following sections identify fields within the RACF BASE and TSO segments that have identical eTrust CA-ACF2 logonid fields. The comments section identifies how the field can be used with the RACROUTE REQUEST=EXTRACT SAF call.

By saying that a field is extractable, this means that it can be extracted via a RACROUTE REQUEST=EXTRACT,TYPE=EXTRACT (or EXTRACTN) SAF call. By saying that a field is replaceable, this means that it can be replaced by a RACROUTE REQUEST=EXTRACT,TYPE=REPLACE SAF call.

When using the SAF RACROUTE REQUEST=EXTRACT mechanism, you must refer to fields according to their name in the RACF database, not the corresponding eTrust CA-ACF2 name. This distinction becomes important when you use the SAF RACROUTE REQUEST=EXTRACT facility to obtain from and alter data within the BASE and TSO user profile segments. Note: Not all RACF database fields within the BASE and TSO segments have equivalent fields within the eTrust CA-ACF2 logonid record. Some fields are RACF-specific and simply do not pertain to eTrust CA-ACF2 . Other fields are implemented differently under eTrust CA-ACF2 and cannot be queried and/or administrated by the SAF RACROUTE REQUEST=EXTRACT facility. For example, the RACF MAGSTRIP field provides Operator ID (OID) support during signon processing. eTrust CA-ACF2 provides similar, but not identical functionality with Extended User Authentication (EUA). The eTrust CA-ACF2 EUA implementation is superior because it provides more functionality, and it provides greater administrative flexibility.

A­2

z/OS and OS/390 Security Cookbook

RACF Segments and ACF2 Profiles

BASE Segment Fields The table below identifies RACF BASE segment fields that have equivalent eTrust CA-ACF2 logonid fields. eTrust CA-ACF2 RACF Field Name Equivalent PASSINT PASSWORD PASSDATE PGMRNAME DFLTGRP LJTIME LJDATE REVOKECT MAXDAYS PASSWORD PSWD-TOD NAME GROUP ACC-TIME ACC-DATE PSWD-INV

Comments eTrust CA-ACF2 supports both extract and replace. eTrust CA-ACF2 supports only the extract. eTrust CA-ACF2 supports only the extract. eTrust CA-ACF2 supports both extract and replace. eTrust CA-ACF2 supports both extract and replace. eTrust CA-ACF2 supports only the extract. eTrust CA-ACF2 supports only the extract. eTrust CA-ACF2 supports only the extract.

Note: eTrust CA-ACF2 does not support any of the RACF combination fields within the BASE user segment. TSO Segment Fields The following table identifies RACF TSO segment fields having equivalent eTrust CA-ACF2 Logonid fields. eTrust CA-ACF2 RACF Field Name Equivalent TACCNT TDEST TSOACCT DFT-DEST

Comments eTrust CA-ACF2 supports both extract and replace. eTrust CA-ACF2 supports both extract and replace.

RACF to eTrust CA-ACF2 Translation

A­3

RACF Commands

eTrust CA-ACF2 RACF Field Name Equivalent THCLASS TJCLASS TLPROC TLSIZE TMCLASS TMSIZE TOPTION TPERFORM TRBA TSCLASS TUNIT TUPT DFT-SUBH DFT-SUBC TSOPROC TSORGN DFT-SUBM TSOSIZE LIDTFLG2 TSOPERF TSORBA DFT-SOUT TSOUNIT Various fields

Comments eTrust CA-ACF2 supports both extract and replace. eTrust CA-ACF2 supports both extract and replace. eTrust CA-ACF2 supports both extract and replace. eTrust CA-ACF2 supports both extract and replace. eTrust CA-ACF2 supports both extract and replace. eTrust CA-ACF2 supports both extract and replace. eTrust CA-ACF2 supports only for extract. eTrust CA-ACF2 supports both extract and replace. eTrust CA-ACF2 supports both extract and replace. eTrust CA-ACF2 supports both extract and replace. eTrust CA-ACF2 supports both extract and replace. eTrust CA-ACF2 supports only the extract.

RACF Commands

ADDGROUP Command

RACF uses the ADDGROUP command to add a group definition. For example:

ADDGROUP OMVSGRP OMVS(GID(1))

In eTrust CA-ACF2, this definition is added to a profile record as follows:

SET PROFILE(GROUP) DIV(OMVS) INSERT OMVSGRP GID(1)

A­4

z/OS and OS/390 Security Cookbook

RACF Commands

Anytime you insert, change, or delete profile records, you must bring the changed profile records into storage as follows:

F ACF2,REBUILD(USR),CLASS(P)

In addition, if you changed the OMVS or OMVSGRP profile records, you must also rebuild the in-storage tables as follows:

F ACF2,OMVS

ADDSD Command

RACF uses the ADDSD command to define profiles for data sets that are to be protected. This process is unnecessary in eTrust CA-ACF2 because all data sets are protected by default.

ADDUSER Command

RACF uses the ADDUSER command to define a new user to its database. The command defines the the profile information necessary to allow that user to use the desired components of the system. The ADDUSER command is the same as the INSERT command in eTrust CA-ACF2. For example, the RACF command:

ADDUSER USER01 DFLTGRP(OMVSGRP) OMVS(UID(2001) HOME(/) PROGRAM(/bin/sh)) PASSWORD(password)

Would be rendered in eTrust CA-ACF2 as follows:

INSERT USER01 GROUP(OMVSGRP) PASSWORD(password) UID(2001) HOME(/) OMVSPGM(/bin/sh)

Note: At eTrust CA-ACF2 6.4 and above, the PROGRAM field in the user profile record has been renamed to OMVSPGM. Anytime you insert, change, or delete profile records, you must bring the changed profile records into storage as follows:

F ACF2,REBUILD(USR),CLASS(P)

In addition, if you changed the OMVS or OMVSGRP profile records, you must also rebuild the in-storage tables as follows:

F ACF2,OMVS

ALTDSD Command

RACF uses the ALTDSD command to alter profiles for data sets that have been defined as protected. This process is unnecessary in eTrust CA-ACF2 because all data sets are protected by default.

RACF to eTrust CA-ACF2 Translation

A­5

RACF Commands

ALTGROUP Command

RACF uses the ALTGROUP command to change an existing group profile. For example:

ALTGROUP OMVSGRP OMVS(G10(2))

In eTrust CA-ACF2, the function of modifying an existing profile is performed with a CHANGE command. For example:

SET PROFILE(GROUP) DIV(OMVS) CHANGE OMVSGRP GID(2)

Anytime you insert, change, or delete profile records, you must bring the changed profile records into storage as follows:

F ACF2,REBUILD(USR),CLASS(P)

In addition, if you changed the OMVS or OMVSGRP profile records, you must also rebuild the in-storage tables as follows:

F ACF2,OMVS

ALTUSER Command

RACF uses the ALTUSER command to change an existing user's profile. For example:

ALTUSER USER01 CICS(OPCLASS(10) OPIDENT(U01) TIMEOUT(30))

Or:

ALTUSER USER01 OMVS(HOME('/u/user01'))

eTrust CA-ACF2 uses the CHANGE command to accomplish the same thing by changing a logonid or profile record. For example:

SET LID CHANGE USER01 CICSCL(10) CICSID(U01) IDLE(30)

Or:

SET PROFILE(USER) DIV(OMVS) CHANGE USER01 HOME(/u/user01/)

Anytime you insert, change, or delete profile records, you must bring the changed profile records into storage as follows:

F ACF2,REBUILD(USR),CLASS(P)

In addition, if you changed the OMVS or OMVSGRP profile records, you must also rebuild the in-storage tables as follows:

F ACF2,OMVS

A­6

z/OS and OS/390 Security Cookbook

RACF Commands

BLKUPD Command

RACF uses the BLKUPD command to allow users to repair the RACF database by directly changing its internal elements. This command is for RACF administration and would have no effect on an eTrust CA-ACF2 environment.

CONNECT Command

RACF uses the CONNECT command to connect or add RACF userid to an existing group. This grants the userid the accesses associated with that group. For example:

CONNECT USERA GROUP(PAYGRP)

In eTrust CA-ACF2, grouping individuals together is handled with the UID string and the individual logonid fields that eTrust CA-ACF2 uses to construct the UID string. For example, if you want to add a user to the payroll department, you would issue the following command:

SET LID CHANGE USERA DEPT(PAY)

DELDSO Command

RACF uses the DELDSO command to delete a profile defining a data set for RACF protection. This process is unnecessary in eTrust CA-ACF2 because all data sets are protected by default.

DELGROUP Command

RACF uses the DELGROUP command to delete a RACF group profile. For example:

DELGROUP PAYROLL

There is no direct corollary in eTrust CA-ACF2 . eTrust CA-ACF2 uses the UID string to group users and only uses a group in selected environments such as UNIX System Services. A default group is assigned to an individual logonid by placing a value in the GROUP field and by defining an associated GROUP profile records. Deleting a group in this instance would be done as follows:

SET LID CHANGE LOGONID GROUP() SET PROFILE(GROUP) DIV(OMVS) DELETE PAYROLL

RACF to eTrust CA-ACF2 Translation

A­7

RACF Commands

DELUSER Command

RACF uses the DELUSER command to delete a user profile from RACF. For example:

DELUSER USERA

In eTrust CA-ACF2 you remove a user from the database by deleting the logonid as follows:

SET LID DELETE USERA

LISTDSD, LISTGRP, and LISTUSER Commands

RACF uses the LISTDSD, LISTGRP, and LISTUSER commands to display the corresponding data set, group, and user profiles. For example:

LISTUSER USERA

eTrust CA-ACF2 provides a LIST command to enable you to list the individual or selected groups or database records. For instance, to list a logonid you would do the following:

SET LID LIST USERA

PASSWORD Command

RACF uses the PASSWORD command to change a user's password or its associated change interval. The same function is accomplished in eTrust CA-ACF2 using the CHANGE command on the logonid. For example:

SET LID CHANGE USERA PASSWORD(NEWONE) MINDAYS(3) MAXDAYS(30)

PERMIT Command

The RACF PERMIT command allows access to resources. For example:

PERMIT SYS1.PARMLIB CLASS(DATASET) ID(user) ACCESS(READ)

Or:

PERMIT USI161ME.HOGWA01.HOGWA01C.JOB03567.D0000002 CLASS(jesspoolclass) ID(user) ACCESS(READ)

A­8

z/OS and OS/390 Security Cookbook

RACF Commands

Based on the resource class, eTrust CA-ACF2 would use access rules or resource rules to perform the same control. If the resource class is DATASET, DASDVOL, or TAPEVOL, eTrust CA-ACF2 uses access rules to validate a request. Any other class is controlled with resource rules. The first RACF example uses a class of DATASET, so in eTrust CA-ACF2 this is an access rule as follows:

$KEY(SYS1) PARMLIB UID(user) R(A)

The second RACF example uses a class that is not one of the classes that uses access rules, so eTrust CA-ACF2 uses a generalized resource rule as follows:

$KEY(USI161ME) TYPE(SPL) HOGWA01.- UID(user) SERVICE(READ) ALLOW

RACDCERT Command

RACF uses the RACDCERT command to administer digital certificates. This command allows authorized users to add, list, modify, generate and delete certificates. It can also be used to generate certificate requests. The following are examples of RACDCERT commands and their translation to eTrust CA-ACF2 commands. Example 1 The following RACDCERT command adds a digital certificate to the RACF database:

RACDCERT ID(JSMITH) ADD(`JSMITH.CLIENT1.P12') WITHLABEL(`Certificate for Jimmy Smith') TRUST PASSWORD(`Jacksonville')

In eTrust CA-ACF2 you would add the same digital certificate in the following manner:

Set profile(user) div(certdata) Insert jsmith.client dsn(`jsmith.client1.p12') label(Certificate for Jimmy Smith) trust Password(Jacksonville)

Example 2 The following RACDCERT command displays the contents of the certificate in the JSMITH.CLIENT1.P12 data set.

RACDCERT CHECKCERT(`JSMITH.CLIENT1.P12') PASSWORD(`Jacksonville')

In eTrust CA-ACF2 you would display the same digital certificate in the following manner:

Chkcert dsn(`jsmith.client1.p12') password(Jacksonville)

RACF to eTrust CA-ACF2 Translation

A­9

RACF Commands

Example 3 The following RACDCERT command displays the certificate that was added to the RACF data base:

RACDCERT ID(JSMITH) LIST(LABEL(`Certificate for Jimmy Smith'))

In eTrust CA-ACF2 you would display the CERTDATA record in the following manner:

Set profile(user) div(certdata) List jsmith.client

The contents of the certificate contained in the CERTDATA record can be displayed as follows:

Chkcert jsmith.client

Example 4 The following RACDCERT command modifies the certificate that was added to the RACF data base:

RACDCERT ID(JSMITH) ALTER(LABEL(`Certificate for Jimmy Smith')) NEWLABEL(`Jimmy Smith Certificate') TRUST

In eTrust CA-ACF2 the same change would be made in the following manner:

Set profile(user) div(certdata) Change jsmith.client newlabel(Jimmy Smith Certificate) trust

Example 5 The following RACDCERT command deletes the certificate that was added to the RACF data base:

RACDCERT ID(JSMITH) DELETE(LABEL(`Jimmy Smith Certificate'))

In eTrust CA-ACF2 the record would be deleted in the following manner:

Set profile(user) div(certdata) Delete jsmith.client

or

delete jsmith label(Jimmy Smith Certificate)

A­10

z/OS and OS/390 Security Cookbook

RACF Commands

Example 6 The following RACDCERT command generates a self-signed CA certificate to be added to the RACF database:

RACDCERT CERTAUTH GENCERT SUBJECTSDN(CN(`My Company z/OS CA') o(`My Company') ou(`My Dept') l(`My location') sp(`Illinois') c(`US')) size(512) withlabel(`CA certificate for My Company') NOTBEFORE(DATE(2001-09-04)) NOTAFTER(DATE(2005-10-12))

In eTrust CA-ACF2, the following command will generate a self-signed CA certificate that is added to the CA-ACF2 database:

Gencert certauth.cert1 subjsdn(cn=`My Company z/OS CA' o=`My Company' ou=`My Dept' l=`My location' sp=Illinois c=US) size(512) label(CA certificate for My Company) active(2001-09-04) expire(2005-10-12)

Example 7 The following RACDCERT command generates a SITE certificate signed by the CA certificate generated in the previous step:

RACDCERT SITECERT GENCERT SUBJECTSDN(CN(`server.my.company.com') o(`My Company') ou(`My Dept') l(`My location') sp(`Illinois') c(`US')) size(512) withlabel(`Certificate for my server') SIGNWITH(CERTAUTH LABEL(`CA certificate for My Company'))

In eTrust CA-ACF2, the following command will generate the same SITE certificate:

Gencert sitecert.server subjsdn(cn=`server.my.company.com' o=`My Company' ou=`My Dept' l=`My location' sp=Illinois c=US) size(512) label(Certificate for my server) signwith(certauth label(CA certificate for My Company)

Example 8 The following RACDCERT command generates a client certificate signed by an internal CA certificate:

RACDCERT ID(JSMITH) GENCERT SUBJECTSDN(CN(`Jimmy Smith') o(`My Company') ou(`My Dept') l(`My location') sp(`Illinois') c(`US')) size(512) withlabel(`Jimmy Smith Cert') SIGNWITH(CERTAUTH LABEL(`CA certificate for My Company'))

In eTrust CA-ACF2, the following command will generate the same client certificate:

Gencert jsmith.cert subjsdn(cn=`Jimmy smith' o=`My Company' ou=`My Dept' l=`My location' sp=Illinois c=US) size(512) label(Jimmy Smith Cert) signwith(certauth label(CA certificate for My Company))

Example 9 The following RACDCERT command generates a certificate request.

RACDCERT ID(JSMITH) GENREQ(LABEL(`Jimmy Smith Cert')) DSN(`JSMITH.CERT.REQ')

RACF to eTrust CA-ACF2 Translation

A­11

RACF Commands

In eTrust CA-ACF2, the following command will generate the same certificate request:

Genreq jsmith.cert dsn(`jsmith.cert.req')

Example 10 The following RACDCERT command generates a certificate from a certificate request.

RACDCERT ID(JSMITH) GENCERT(`JSMITH.CERT.REQ') WITHLABEL(`Jimmy Smith Cert from req') SIGNWITH(CERTAUTH LABEL(`CA certificate for My Company'))

In eTrust CA-ACF2, the following command will generate the same certificate from a certificate request:

Gencert jsmith.cert2 dsn(`jsmith.cert.req') label(Jimmy Smith Cert from req) signwith(certauth.cert1)

Example 11 The following RACDCERT command exports a certificate and private key to a data set in DER format.

RACDCERT ID(JSMITH) EXPORT(LABEL(`Jimmy Smith Cert')) DSN(`JSMITH.CERT.P12') FORMAT(PKCS12DER) PASSWORD(`JimmySmith')

In eTrust CA-ACF2, the following command will export the same certificate to the same data set:

export jsmith label(Jimmy Smith Cert) dsn(`jsmith.cert.p12') format(pkcs12der) password(Jimmy Smith)

Example 12 The following RACDCERT command creates a key ring.

RACDCERT ID(WEBSRV) ADDRING(SERVA)

In eTrust CA-ACF2, the following command creates the same key ring:

Set profile(user) div(keyring) Insert websrv ringname(SERVA)

Example 13 The following RACDCERT command connects a certificate to the key ring

RACDCERT ID(WEBSRV) CONNECT(ID(WEBSRV) LABEL(`Certificate for serva') RING(SERVA) DEFAULT)

A­12

z/OS and OS/390 Security Cookbook

RACF Commands

In eTrust CA-ACF2, the following command connects the same certificate to the key ring:

Set profile(user) div(keyring) Connect certdata(websrv) label(Certificate for serva) keyring(websrv) ringname(SERVA) default

Alternatively you could enter:

Set profile(user) div(keyring) Connect certdata(websrv.serva) keyring(websrv.serva) default

Example 14 The following RACDCERT command lists a key ring.

RACDCERT ID(WEBSRV) LISTRING(SERVA)

In eTrust CA-ACF2, the following commands will list the key ring:

Set profile(user) div(keyring) list websrv ringname(SERVA) list websrv.serva

Example 15 The following RACDCERT command removes a certificate from a key ring

RACDCERT ID(WEBSRV) REMOVE(ID(WEBSRV) LABEL(`Certificate for serva') RING(SERVA))

In eTrust CA-ACF2, the following command removes the same certificate from the key ring:

Set profile(user) div(keyring) remove certdata(websrv) label(Certificate for serva) keyring(websrv) ringname(SERVA)

Example 16 The following RACDCERT command deletes a key ring.

RACDCERT ID(WEBSRV) DELRING(SERVA)

In eTrust CA-ACF2, the following command deletes the same key ring:

Set profile(user) div(keyring) delete websrv ringname(SERVA)

RACF to eTrust CA-ACF2 Translation

A­13

RACF Commands

Example 17 The following RACDCERT command adds a mapping profile that will associate the user ID WEBUSER with all digital certificates issued by VeriSign for Class 1 Individual Subscribers:

RACDCERT ID(WEBUSER) MAP IDNFILTER(`OU=VeriSign Class 1 Individual Subscriber.O=VeriSign, Inc..L=Internet') WITHLABEL(`Savings Account')

In eTrust CA-ACF2, the following command creates the same profile:

Set control(gso) div(certmap)

Insert certmap.webuser idnfiltr(OU=VeriSign Class 1 Individual Subscriber.O=VeriSign, Inc..L=Internet) label(Savings Account) id(webuser)

RALTER Command

The RACF RALTER command allows changes to an existing profile. For example:

RALTER PROGRAM * ADDMEM(`CBC.SCLBDLL') UACC(READ)

In eTrust CA-ACF2 , the equivalent function would be handled by making changes to an access rule or a resource rule and then recompiling it.

RDEFINE Command

RDEFINE is used in RACF to define resources. There is no counterpart to this in eTrust CA-ACF2 . eTrust CA-ACF2 uses a default protection scheme, which assumes that the resource is protected. This default scheme requires that rules be written to allow access to a resource.

RDELETE Command

RACF uses the RDELETE command to remove a resource from RACF protection, and to remove other RACF administrative functions. There is no counterpart to this command in eTrust CA-ACF2 . Removing resources from protection is the same as writing a generic resource rule to allow access to the resource class.

REMOVE Command

RACF uses the REMOVE command to take one or more users out of a specific group. Since eTrust CA-ACF2 has a grouping structure based on the UID string, moving a user from group to group is simply a change to the value in the appropriate field contained within the UID string.

A­14

z/OS and OS/390 Security Cookbook

RACF Commands

RLIST Command

RACF uses the RLIST command to list the details of resource profiles. It is also used to perform refreshes of resource profiles. eTrust CA-ACF2 uses the LIST command to display the various records found in the eTrust CA-ACF2 databases. For refreshing resource rules that are globally resident, eTrust CA-ACF2 uses the F ACF2, REBUILD command. For locally resident rules, the SETNORUL command releases the old copies of rules in an address space forcing the address space to acquire new copies.

RVARY Command

RACF uses the RVARY command to deactivate or reactivate RACF functions or resources. There is no counterpart to this command in eTrust CA-ACF2 .

SEARCH Command

RACF uses the SEARCH command to selectively display database information. eTrust CA-ACF2 provides a comprehensive set of commands and utilities that allow the security administrator to retrieve eTrust CA-ACF2 user information. The eTrust CA-ACF2 command provides a complete set of parms and associated options for listing and displaying user information. See the Overview chapter of the eTrust CA-ACF2 Administration Guide for details on how to use this command. eTrust CA-ACF2 also provides several utilities for listing logonid and access information. These reports are the ACFRPTSL, ACFRPTXR, and the ACFRPTRX reports. See the eTrust CA-ACF2 Reports and Utilities Guide for details on how to use these reports.

SETROPTS Command

SETROPTS is used to set RACF options or turn them off. For example:

SETROPTS CLASSACT(JESSPOOL)

eTrust CA-ACF2 uses SAFDEF records as needed to activate various protection schemes. Since most SAF calls are protected by default, it is usually not necessary to add additional SAFDEF records. The eTrust CA-ACF2 SECTRACE and SHOW SAFDEF commands can be used to verify the SAF environment that an application is using. For example, the SHOW SAFDEF command indicates that the class of JESSPOOL is ignored so it would need a SAFDEF record to activate as follows:

IN SAFDEF.JESSPOOL ID(JESSPOOL) MODE(GLOBAL) RACROUTE(REQUEST=AUTH,CLASS=JESSPOOL) REP

RACF to eTrust CA-ACF2 Translation

A­15

RACF Attribute Translation

If finer detail is required, the SECTRACE output could supply additional information that could be added to the SAFDEF record to make the request more specific. CLASS This defines a type of resource. eTrust CA-ACF2 divides resources into data set resources or general resources. If the class is DATASET, DASDVOL, or TAPEVOL, eTrust CA-ACF2 uses data set access rules to validate access. All other classes will use generalized resource rules. The currently defined classes and their eTrust CA-ACF2 type codes can be found by issuing an ACF SHOW CLASMAP command. If the resource is not defined or you want to change the type codes used in the resource rules for a class, you can use a GSO CLASMAP record to accomplish this. For example, the JESSPOOL class comes predefined with a type code of SAF. To change this, you would issue:

SET CONTROL(GSO) INSERT CLASMAP.JESSPOOL RESOURCE(JESSPOOL) RSRCTYPE(SPL)- ENTITYLN(53)

RACF Attribute Translation

The following table shows how eTrust CA-ACF2 translates a RACF attribute. eTrust CA-ACF2 Access Rule READ WRITE WRITE ALLOC EXECUTE eTrust CA-ACF2 Resource Rule READ UPDATE DELETE ADD EXECUTE

RACF Attribute READ UPDATE CONTROL ALTER EXECUTE

Note: In RACF, a higher attribute assumes access to the entire lower attribute. For example, giving update access to a resource would assume read access. eTrust CA-ACF2 does not make this assumption. Access to a resource must be specifically given.

A­16

z/OS and OS/390 Security Cookbook

Program Control (PADS)

Program Control (PADS)

RACF Program Control allows for the definition of an exact program and library environment. A similar function exists in eTrust CA-ACF2 called program pathing. This feature is used in data set access rules to specify the exact path (program and/or library) for accessing a particular data set or group of data sets.

RACF Attributes

The following table shows selected RACF attributes, their purpose, and the equivalent eTrust CA-ACF2 privilege that would be used to achieve the same result in an eTrust CA-ACF2 environment. eTrust CA-ACF2 Equivalent AUDIT NON-CNCL

RACF Attribute AUDITOR OPERATIONS

Purpose Allows a user to review profile information. Allows a user to bypass security checking for selected resource classes. Allows a user to bypass security checking without any logging. Global access checking in RACF not allowed for user. Prevents a user from accessing the system. Used in RACF administration. Allows a user to bypass security checking but logging can be turned on for this user.

PRIVILEGED

MAINT and a GSO MAINT record No counterpart* SUSPEND or CANCEL SECURITY NON-CNCL

RESTRICT REVOKE SPECIAL TRUSTED

* The "No counterpart" indicates that the concept does not exit in eTrust CA-AC2 and the attribute can be ignored in setting up an ID in an eTrust CA-ACF2 environment.

RACF to eTrust CA-ACF2 Translation

A­17

Index

_

_passwd() function, 2-12

Activation of new or changed records, 2-10 ADDGROUP RACF command, A-4 Adding firewall administrators to FWGRP, 3-25 ADDSD RACF command, A-5

A

Access flags, 4-2 Access levels for files and directories, 4-2 Access to resources allowing in CA-ACF2, A-9 ACEE, 2-7 ACEE task level, 2-13 ACEECGRP field, 2-7 ACF subcommands CONNECT, 5-22, 5-33 REMOVE, 5-23, 5-34 ACF$DCE EDIT macro, 3-16 ACF2UNLD utility, 3-16 ACFBATCH utility, 3-16 ACFRPTOM report, 7-1 entry descriptions, 7-5 File Security Packets (FSP), 7-11 parameters, 7-2 sample output, 7-5 Security Credentials Packets (CRED), 7-11 specific parameters, 7-2 ACFRPTRV report HFS file processing, 4-18 ACRPTOM report service field values, 7-7

ADDUSER RACF command, A-5 administrator ID creating, 2-14 ALL, SECTRACE command, 2-23 ALTDSD RACF command, A-5 ALTGROUP RACF command, A-6 ALTUSER command in RACF, A-6 ANONYMOU logonid, 3-4 ANONYMOUS logon feature ANONYMOUS parameter, 3-4 FTP, 3-4 FTPDATA configuration file, 3-4 AOPADMIN, 3-6 AOPOPER, 3-6 APPLVAR field CRITMAP record, 5-43 Assign users to groups, 2-19 ASSIZE field, defining, 2-17 Attribute translation RACF, A-11 Attributes RACF, A-12 audit, 2-24 Audit attribute, 7-1

Index­1

RACF Attributes

AUDIT privilege, 7-1 Authentication DCE Security Server, 3-14 Automatic signon DCE, 3-19

BPX.CAHFS.SET.PRIORITY, 4-11 BPX.CAHFS.SET.RLIMIT, 4-11 BPX.CAHFS.UNMOUNT, 4-12 BPX.DAEMON, 2-12, 3-5, 6-7 BPX.DEFAULT.USER, 2-20

B

BASE segment fields, A-3 BLKUPD RACF command, A-7 BPX resources for file functions, 4-14 system functions, 4-11 BPX rule, 2-10, 2-12, 2-13, 3-5 BPX.CAHFS.CHANGE.FILE.ATTRIBUTES, 4-14 BPX.CAHFS.CHANGE.FILE.AUDIT.FLAGS, 4-14 BPX.CAHFS.CHANGE.FILE.FORMAT, 4-14 BPX.CAHFS.CHANGE.FILE.GROUP, 4-14 BPX.CAHFS.CHANGE.FILE.MODE, 4-14 BPX.CAHFS.CHANGE.FILE.MODE.EGID, 4-14 BPX.CAHFS.CHANGE.FILE.MODE.EUID, 4-14 BPX.CAHFS.CHANGE.FILE.MODE.STICKY, 4-14 BPX.CAHFS.CHANGE.FILE.OWNER, 4-14 BPX.CAHFS.CHANGE.FILE.TIME, 4-15 BPX.CAHFS.CHANGE.PRIORITY, 4-11 BPX.CAHFS.CREATE.EXTERNAL.LINK, 4-12 BPX.CAHFS.CREATE.LINK, 4-12 BPX.CAHFS.CREATE.SYMBOLIC.LINK, 4-12 BPX.CAHFS.MOUNT, 4-11 BPX.CAHFS.PTRACE, 4-12 BPX.CAHFS.SECURITY.DISABLE, 4-23 BPX.CAHFS.SECURITY.DISABLE.ATTRIBUTES, 4-23 BPX.CAHFS.SECURITY.ENABLE, 4-23 BPX.CAHFS.SECURITY.ENABLE.ATTRIBUTES, 4-23 BPX.CAHFS.SECURITY.STATUS, 4-23 BPX.CAHFS.SECURITY.STATUS.ATTRIBUTES, 4-23

BPX.SAFFASTPATH, 2-10, 4-3 BPX.SERVER, 2-13, 6-7 BPX.SRV.userid, 2-13 BPXBATCH program, 2-14 BPXOINIT, 2-9 BPXPRMxx member, 2-17 BPXROOT logonid, 2-12 BPXWIRAC exec, 2-14

C

CA SAF HFS introduction, 4-5 rule generation utility, 4-19 security modification utility, 4-22 CA90s. See Unicenter TNG Framework for OS/390 CA-ACF2 defining XE, 2-5 CAISEC00 member, 2-5 CDS.CSSM, 3-24 Certificate authority (CA), 5-35 certificate extensions, 5-18, 5-33 Certificate name filtering, 5-34 Certificate name filtering criteria mapping (CRITMAP) CRITMAP record, 5-43 Certificate name filtering options (CERTMAP) CERTMAP record, 5-37 CERTMAP field, of SHOW subcommand, 5-41 CERTMAP GSO records, 5-42 CERTMAP record described, 5-37 field descriptions, 5-37, 5-38, 5-39, 5-40

A­2

CA-ACF2 OS/390 Security Cookbook

RACF Attributes

CERTMAP records displaying site-defined, 5-41 Change owner (CHOWN), 4-4 CHANGE, SECTRACE command, 2-23 CHECK, SECTRACE command, 2-23 CHKCERT examples, 5-11, 5-33 subcommand, 5-10, 5-33 CHKLIST DD, 3-21 chmod command, 4-5 CHOWN, 4-4 chown(), 2-21 CHOWNRES parameter, 4-4 ck_access, 2-23 ck_file_owner, 2-23 ck_IPC_access, 2-23 ck_owner_two_files, 2-23 ck_priv, 2-23 ck_process_owner, 2-23 CLASMAP record, 3-12, 3-26 CLASS resource types, A-11 clear_setid, 2-24 Command notation, 1-5 Component Broker Series (SOMobjects) SOM subsystem, 3-11 SOMDOBJ class, 3-12 SOMobject method, 3-12 CONNECT RACF command, A-7 CONNECT subcommand, 5-22, 5-33 Controlling access to daemons, 2-12 Hierarchical File System (HFS), 4-2 USS, 2-5 Controlling superuser functions, 2-21 Conversion of DCE registry, 3-16 CPUTIME field defining, 2-17

CRITERIA field CERTMAP record, 5-39 CRITMAP record described, 5-43 field descriptions, 5-43 Cross-reference tables rebuilding, 2-23 CSFAKEX resource, 3-26 CSFKEYS class, 3-26 CSFSERV class, 3-25, 3-26

D

Daemons controlling access to, 2-12 Data caching under NFS, 3-21 Data set access for OMVS, 2-9 remote, 3-21 dbx(), 2-22 DCE profile record AUTOLOG, 3-15 DCENAME, 3-15 HOMECELL, 3-15 HOMEUUID, 3-15 UUID, 3-15 DCE registry, 3-16 updating, 3-16 DCE Security Server ACF2UNLD utility, 3-16 CA-ACF2 support, 3-16 creating a DCE profile record, 3-16 description, 3-14 MVSEXPT utility, 3-16 MVSIMPT utility, 3-16 RACFUNLD file name, 3-17 DCE segment, 3-18 DCE support DCEKERN, 3-18 defining a DCE segment, 3-18 defining under CA-ACF2, 3-18 disable automatic login, 3-18 environment variables, 3-18 for OS/390, 3-17

Index

A­3

RACF Attributes

DCE_LOGIN command, 3-19 DCEKERN started task/daemon, 3-18 Defaults GID and UID, 2-20 Defining DCE, 3-18 resources in CA-ACF2, A-11 DELDSO RACF command, A-7 deleteUSP, 2-24 DELGROUP RACF command, A-7 DELUSER RACF command, A-8 DETAIL field ACFRPTOM report, 7-4 DFLTAPPL, 3-5 DFS/SMB encrypted password, 3-15 DFS/SMB password, 2-2 DFTGROUP field, 2-20 DFTOMVSG field, 2-20 DFTOMVSU field, 2-20 DFTUSER field, 2-20 Digital certificate key ring and filtering, 2-3 Digital Certificate Support certificate authority (CA), 5-35 Certificating Authority, 5-1 CERTMAP GSO records, 5-42 filtering logic processing, 5-36 identifier abbreviations, 5-35 issuer's distinguished name (IDN), 5-34 key ring profile records, 5-33, 5-45 key ring support, 5-33, 5-45 name filtering, 5-34 subject's distinguished name (SDN), 5-34 X.509 Digital Certificate, 5-1 DIRACC field UNIXOPTS record, 7-12 Directories rebuilding, 2-23 DIRSRCH field UNIXOPTS record, 7-12 Disable DCE automatic login, 3-18

DISABLE parameter, security modification utility parameter, 4-22 Disabling RACF IFAPRDxx member, 3-13 STATE field, 3-13 DOMCON, 3-7 DOMINO console interface, 3-7 DSN field CERTMAP record, 5-39

E

EDATE, 7-2 ENABLE parameter, security modification utility parameter, 4-22 Environment variables DCE, 3-18 ENVVAR files, 3-18 ERROR field ACFRPTOM report, 7-4 ETIME, 7-2 EUV_AUTOLOG, 3-18 Exit processing pathname translation, 4-16 user path processing, 4-16 Exits translate table, 4-18 EXPORT subcommand, 5-12, 5-33 EXPORTS, NFS SECURITY setting, 3-21

F

FAC rule, 2-12, 2-13, 3-5, 3-6, 3-18, 3-23, 4-3, 4-23, 6-7 sample, 4-15 FACILITY resources AOPADMIN, 3-6 BPX.CAHFS.SECURITY, 4-23 BPX.DAEMON, 2-12, 6-7 BPX.SAFFASTAUTH, 2-10, 4-3 BPX.SERVER, 2-13, 6-7 DCEKERN.START.REQUEST, 3-18

A­4

CA-ACF2 OS/390 Security Cookbook

RACF Attributes

for file functions, 4-14 FWKERN.START.REQUEST, 3-23 HFS system functions, 4-11 sample HFS rules, 4-15 with FTP, 3-4 with Telnet, 3-5 FASTAUTH processing, 2-10, 2-22, 4-3 File access security, 4-6 File functions for HFS, 4-13 File ownership, 4-9 File security UNIX security model, 4-2 File Security Packets (FSP), 7-11 FILEPROC field defining, 2-17 Firewalls adding administrators, 3-25 setting up, 3-23 FSOBJ field UNIXOPTS record, 7-12 FSSEC field UNIXOPTS record, 7-12 FTP anonymous logons, 3-4 installing, 3-4 FTPD started task, 3-3 FTPDATA configuration file, 3-4 FTPSERVE started task, 3-3 FWGRP adding firewall administrators, 3-23 FWKERN, 3-23 FWKERN.START.REQUEST, 3-23

GENREQ Examples, 5-22, 5-33 subcommand, 5-21, 5-33 GET, SECTRACE command, 2-24 get_uid_gid_supgrps, 2-24 getGMAP, 2-24 getgrgid() service, 2-6 getpsent(), 2-22 getpwnam() service, 2-12 getUMAP, 2-24 GID field ACFRPTOM report, 7-2 default for OMVS, 2-20 defining, 2-18 format, 2-5 values, 2-6 Granularity superuser, 2-21 GROUP field ACFRPTOM report, 7-2 assigning users, 2-19 of logonid record, 2-6 Group identification, 2-5 Group profile records assigning users to groups, 2-19 defining, 3-6 defining a GID, 2-9 defining for SOM subsystem, 3-11 defining for started tasks, 3-22 for USS groups, 2-18 GID field values, 2-6 OMVS, 2-18 rebuilding cross-reference tables, 2-23 rebuilding directories, 2-23 TTY, 2-11 Groups supplemental, 2-6

G

GENCERT certificate extensions, 5-18, 5-33 examples, 5-19, 5-33 subcommands, 5-14, 5-33

H

HFS. See Hierarchical File System (HFS) Hierarchical File System (HFS) accessing data sets, 4-1

Index

A­5

RACF Attributes

CA SAF rule generation utility, 4-19 CA SAF security modification utility, 4-22 controlling using CA SAF HFS security, 4-5 exit processing, 4-16 FACILITY resources, 4-14 FASTAUTH checking, 4-3 file access security, 4-6 file functions, 4-13 implementation of CA SAF HFS security, 4-15 introduction, 4-1 path name translation, 4-6 processes that affect security, 4-3 remote access, 3-21 reporting, 4-11 root directory, 4-10 rule considerations, 4-10 rules for root directory, 4-10 securing functions, 4-11 system functions, 4-11 troubleshooting, 4-18 UNIX security model, 4-2 user file ownership, 4-9 HOME field defining, 2-16 Hyper Solution Delivery, 1-7

initUSP, 2-24 Integrated Cryptographic Service Facility (ICSF), 3-25 Interfacing between OMVS ISHELL and RACF, 2-14 Internet Connection Server, 3-37 Internet Web Server, 3-37 IPC_RMID, 2-22 IPCOBJ field UNIXOPTS record, 7-13 ipcrm command, 2-22 IRR.DIGTCERT.LIST, 3-24 IRR.DIGTCERT.LISTRING, 3-24 ISAKMP server, 3-24 ISPF access to HFS data set, 4-1 Issuer's distinguished name (IDN), 5-34

K

Key ring profile records, 5-33, 5-45

I

ICA.CFGSRV, 3-24 ICAPFLOG, 3-23 ICAPPFTP, 3-23 ICAPSLOG, 3-23 ICAPSOCK, 3-23 ICAPTNAT, 3-23 ICSF. See Integrated Cryptographic Service Facility IDNFILTR field CERTMAP record, 5-38 IFAPRDxx member, 3-13 Implicit DCE_LOGIN DCE, 3-19 INFODIR record, 2-7, 2-10, 2-22 INIT, SECTRACE command, 2-24 initACEE, 2-24

Key ring support, 5-33, 5-45 kill(), 2-22

L

LDAP server support IBM, 6-7 LINECNT, 7-2 link(), 2-21 LISTDSD RACF command, A-8 LISTGRP RACF command, A-8 LISTUSER RACF command, A-8 lnotes profile record, 3-10 Logging security events, 7-1 USS security calls, 7-1 Logonid record GROUP field, 2-6

A­6

CA-ACF2 OS/390 Security Cookbook

RACF Attributes

Logonid records creating for FTP started task, 3-4 creating for INETD, TCPIP, and RMFGAT started task, 2-11 creating for OMVS started task, 2-9 installing XE, 2-7 Lotus Domino, 2-3 Lotus Domino Go Webserver (DGW), 3-37 Lotus Notes Server, 3-7 defining users, 3-10 ls command, 4-19

MVSNFS user profile records, 3-22 MVSNFSC user profile records, 3-22 MVSNLM user profile records, 3-22 MVSNSM user profile records, 3-22

N

Name filtering, 5-34 NDS. See Novell Directory Services NDS profile records, 3-27

M

MAKE, SECTRACE command, 2-24 make_root, 2-24 makeFSP, 2-24 makeISP, 2-24 MAXASSIZE parameter, 2-17 MAXCPUTIME parameter, 2-17 MAXFILEPROC parameter, 2-17 MAXMMAPAREA parameter, 2-18 MAXPROCUSER parameter, 2-17 MAXTHREADS parameter, 2-17 MISC, SECTRACE command, 2-24 mkdir(), 2-21 MMAPAREA field defining, 2-18 Monitoring user activity, 7-1 mount(), 2-21 msgctl(), 2-22 Multiple groups, 2-6 MVS hierarchical file system, 4-5 MVS data set, 4-1 MVSEXPT utility, 3-16 MVSIMPT utility, 3-16 MVSNFS procedure, 3-21

Network File System (NFS) support for OS/390. See NFS NFS default STCs, 3-22 SECURITY attribute, 3-21 SECURITY attribute settings, 3-21 NFS support for OS/390, 3-21 nice(), 2-22 NOBODY, 3-26 NOCHOWNRES parameter, 4-4 NONE, NFS SECURITY setting, 3-21 NO-OMVS logonid attribute, 2-21 Novell Directory Services, 3-26 Novell Network Services, 3-26 NWROOT, 3-26 NWUSER, 3-26

O

OBTAIN failed, 4-1 OCEP services, 3-24 OMVS creating started task logonids, 2-7, 2-9 defining INETD, TCPID, and RMFGAT started task logonids, 2-11 interfacing between ISHELL and RACF, 2-14 ISHELL, 2-14 segment, 2-15

Index

A­7

RACF Attributes

OMVS data set access, 2-9 OMVS started task, 2-9 OMVSKERN, 3-5 OMVSPGM field defining, 2-14 Open() for read, 2-21 Open() for write, 2-21 opendir(), 2-21 OpenEdition MVS defining INETD, TCPID, and RMFGAT started task logonids, 2-11 UNIX System services support, 2-4 Operator commands for USS rebuilding directories, 2-23 Operator group, AOPOPER, 3-6 OPTS record OMVS userid and group defaults, 2-20 OS/390 Release-specific security concerns, 2-8 OS/390 compatibility StarTCC, 1-6 upgrade solutions, 1-6 OS/390 DCE support, 3-17 OS/390 firewall, 3-22 OS/390 Integrated Cryptographic, 3-25 OS/390 Internet Connection Server. See WebSphere Application Server OS/390 Network File System, 3-21 OS/390 Print Server, 3-6 OS/390 Security Server Support, 3-12 CA-ACF2 Support for the DCE Security Server, 3-12 DCE Security Server, 3-12 disabling RACF, 3-13 RACF, 3-12

P

PASSWORD RACF command, A-8 Path name translations for hierarchical file systems, 4-6 Pathname translation processing, 4-17 Permission categories, 4-2 PERMIT RACF command, A-8 pfsctl(), 2-22 Print Server support for OS/390, 3-6 Privileges superusers, 2-6 PROCUSER field defining, 2-17 Profile records DCE segment, 3-16 defining XE, 2-5 group segment, 2-18, 3-5, 3-6, 3-22, 3-23, 3-27, 6-7 GROUP segment, 2-9, 2-11, 2-15 lnotes, 3-10 NDS segment, 3-27 OMVS segment, 2-9, 2-14, 2-15, 2-16, 2-17, 3-4, 3-5, 3-22, 3-23, 3-27, 6-7 Program control (PADS) RACF, A-12 Program controlled extended attribute, 4-5 ps command, 2-22 pthread_security_np service, 2-13

Q

query_file_security_options, 2-24 query_system_security_options, 2-24 quiesce(), 2-21

A­8

CA-ACF2 OS/390 Security Cookbook

RACF Attributes

R

R_admin, 2-24 R_audit, 2-23 R_chmod, 2-23 R_chown, 2-23 R_dceauth, 2-23 R_dceinfo, 2-24 R_dcekey, 2-24 R_dceruid, 2-24 R_exec, 2-24 R_fork, 2-24 R_getgroups, 2-24 R_getgroupsbyname, 2-24 R_IPC_ctl, 2-23 R_ptrace, 2-23 R_setegid, 2-24 R_seteuid, 2-24 R_setgid, 2-24 R_setuid, 2-24 R_umask, 2-24 R_usermap, 2-24 RACDCERT RACF command, A-9 RACF ADDGROUP command, A-4 adding a group definition, A-4 ADDSD command, A-5 ADDUSER command, A-5 administering digital certificates, A-9 allowing access to resources, A-8 ALTDSD command, A-5 ALTGROUP command, A-6 ALTUSER command, A-6 attribute translation, A-11 attributes, A-12 BLKUPD command, A-7 changing an existing group profile, A-6 changing an existing user's profile, A-6 changing existing profiles, A-9 changing user password, A-8 CONNECT command, A-7

connecting userid to existing group, A-7 deactivate or reactivate, A-10 defining resources, A-9 DELDSO command, A-7 deleting a group profile, A-7 deleting a profile defining a data set, A-7 deleting a user profile, A-8 deleting resource from protection, A-9 DELGROUP command, A-7 DELUSER command, A-8 disabling, 3-13 displaying database information, A-10 interfacing with OMVS ISHELL, 2-14 LISTDSD command, A-8 LISTGRP command, A-8 listing data set, group, user profiles, A-8 listing resource profile details, A-10 LISTUSER command, A-8 PASSWORD command, A-8 PERMIT command, A-8 program control (PADS), A-12 RACDCERT command, A-9 RALTER command, A-9 RDEFINE command, A-9 RDELETE command, A-9 REMOVE command, A-10 removing users from group, A-10 RLIST command, A-10 RVARY command, A-10 SAF compliant security system, 3-12 SEARCH command, A-10 security server components, 3-12 segments and CA-ACF2 equivalents, A-1 SETROPTS command, A-10 setting options, A-10 to CA-ACF2 translation, A-1 RACF segments BASE and TSO considerations, A-2 RACFUNLD file name, 3-17 RALTER RACF command, A-9 RDEFINE RACF command, A-9 RDELETE RACF command, A-9 readlink(), 2-21 realpath(), 2-21 Rebuilding cross-reference tables, 2-23 directories, 2-23

Index

A­9

RACF Attributes

Records activating, 2-10 Release-specific security concerns OS/390, 2-8 security requirements, 2-8 Remote access, 3-21 REMOVE RACF command, A-10 REMOVE subcommand, 5-23, 5-34 rename(), 2-21 Resident directories building for profile records, 2-10 Resident directory, 2-7 Resource rules allowing access to supplemental groups, 2-7 REXX exec, 2-14 RLIST RACF command, A-10 RLOGIN, 3-5 rmdir(), 2-21 Root directory, 4-10 Rule generation utility, 4-19 Rules for Hierarchical File Systems, 4-10 for root directory, 4-10 RVARY RACF command, A-10

SAFHUSR, 4-17 Sample ACFRPTOM output, 7-5 SDATE, 7-2 SDNFILTR field CERTMAP record, 5-37, 5-40 SEARCH RACF command, A-10 SECTRACE for OMVS, 2-23 HFS files, 4-18 SECTRACE functions, 2-23 Securing FTP using anonymous logons, 3-4 Securing TELNET for USS, 3-5 Security Credentials Packets (CRED), 7-11 Security modification utility for HFS, 4-22 parameters, 4-22 SECURITY privilege, 7-1 SELECT, 7-2 Selective SMF logging options, 7-12 semctl(), 2-22 Servers defining to use thread-level security, 2-13 Session manager, 3-5 SET, SECTRACE command, 2-24

S

SAF compliant security system, 3-12 SAF rule, 3-25 SAF rules, 3-11 SAF, NFS SECURITY setting, 3-21 SAFDEF for HFS FASTAUTH, 4-3 SAFDEF record, 2-10 SAFEXP, NFS SECURITY setting, 3-21 SAFFASTAUTH, 2-10 SAFHSEC, 4-17

seteuid() service, 2-12 setgid on execution, 4-2 setpriority(), 2-22 setreuid() service, 2-12 SETROPTS RACF command, A-10 Setting defaults for OMVS, 2-20 Setting up firewalls, 3-22 setuid on execution, 4-2 setuid() service, 2-12 shmctl(), 2-22

A­10

CA-ACF2 OS/390 Security Cookbook

RACF Attributes

SHOW CERTMAP subcommand example, 5-41 SMF, 7-1 SMF logging options, 7-12 SOM subsystem, 3-11 SOMDOBJ class, 3-12 SOMobject method, 3-12 spawn() service, 2-12 StarTCC Profile, 1-8 Started task logonids defining to OMVS, 2-11 Started tasks defining OMVS logonid, 2-9 Starting CA-ACF2, 2-5 stat(), 2-21 STATE field, 3-13 STATUS parameter, security modification utility parameter, 4-22 STC, 2-9 Sticky bit, 4-2, 4-5 STIME, 7-2 subcommand CHKCERT, 5-10, 5-33 GENREQ, 5-21, 5-33 subcommands EXPORT, 5-12, 5-33 GENCERT, 5-14, 5-33 Subject's distinguished name (SDN), 5-34 SUMMARY field ACFRPTOM report, 7-4 Superuser authorities, 2-3 Superuser functions, 2-21 Superuser granularity, 2-21 SUPERUSER.FILESYS, 2-21 SUPERUSER.FILESYS.CHOWN, 2-21 SUPERUSER.FILESYS.MOUNT, 2-21 SUPERUSER.FILESYS.PFSCTL, 2-22 SUPERUSER.FILESYS.VREGISTER, 2-22

SUPERUSER.IPC.RMID, 2-22 SUPERUSER.PROCESS.GETPSENT, 2-22 SUPERUSER.PROCESS.KILL, 2-22 SUPERUSER.PROCESS.PTRACE, 2-22 SUPERUSER.SETPRIORITY, 2-22 superusers, 2-12 creating an administrator ID, 2-14 definition, 2-6 Supplemental groups, 2-6, 3-25 Surrogate resource BPX.SRV.userid, 2-13 Surrogate users, 2-13 Surrogation process, 2-13 symlink(), 2-21 Syntax for command notation, 1-5 SYSID, 7-2 System functions for HFS, 4-11 SYSTEMID field CRITMAP record, 5-43

T

TCP/IP establishing security, 3-1 TELNET securing for USS, 3-5 using, 3-5 TELNET configuration statements, 3-5 TGR rule, 3-6, 3-25 Thread-level security, 2-13 THREADS field defining, 2-17 TITLE, 7-2 Tracing UNIX system services (OMVS), 2-23 Translate table, 4-18

Index

A­11

RACF Attributes

Transmission Control Protocol/Internet Protocol. See TCP/IP Trusted users assigning superuser authority, 2-6 TSO ISHELL support, 2-14 TSO segment fields, A-3 TTY group profile record, 2-11

User path processing, 4-17 User profile records CERTDATA segment, 5-1 DCE segment, 3-16 defining for SOM subsystem, 3-11 fields, 2-17 HOME field, 2-16 LNOTES segment, 3-10 NDS segment, 3-27 OMVSPGM field, 2-14 rebuilding cross-reference tables, 2-23 rebuilding directories, 2-23 UID field, 2-15 Using firewalls, 3-22 TELNET, 3-5 USS rebuilding directories, 2-23 USS Shell, 2-5 USS support, 2-4

U

UID field ACFRPTOM report, 7-2 default for OMVS, 2-20 defining, 2-15 format, 2-5 UID(0), 2-6, 2-12, 2-21 UNAME field, NDS profile record, 3-27 UNI rules, 2-22 UNIX hierarchical file system, 4-5 UNIX System Services controlling access to, 2-5 UNIX System Services support, 2-4 UNIXOPTS record OMVS userid and group defaults, 2-20 UNIXPRIV class, 2-22 described, 2-21 resources, 2-21 unlink(), 2-21 unmount(), 2-21 unquiesce(), 2-21 Upgrade solutions, 1-6 User audit attribute, 7-1 USER field ACFRPTOM report, 7-2 User file ownership, 4-9 User identification, 2-5 User limit overrides, 2-17 User limits, 2-3

V

vregister(), 2-22

W

WebSphere Application Server, 3-37 prerequisites, 3-45

X

XE, 2-5, 2-6, 2-7, 2-9

A­12

CA-ACF2 OS/390 Security Cookbook

Information

eTrust CA-ACF2 Security for z/OS and OS/390 Security Cookbook

230 pages

Find more like this

Report File (DMCA)

Our content is added by our users. We aim to remove reported files within 1 working day. Please use this link to notify us:

Report this file as copyright or inappropriate

351561


You might also be interested in

BETA
eTrust CA-ACF2 Security for z/OS and OS/390 Security Cookbook