eTrust CA-Top Secret Security for z/OS and OS ... - SupportConnect
eTrust CA-Top Secret Security for z/OS and OS ... - SupportConnect
eTrust CA-Top Secret Security for z/OS and OS ... - SupportConnect
- No tags were found...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> ® <strong>Security</strong><strong>for</strong> z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390<strong>Security</strong> CookbookMay 2003
This documentation <strong>and</strong> related computer software program (hereinafter referred to as the “Documentation”) is <strong>for</strong>the end user’s in<strong>for</strong>mational purposes only <strong>and</strong> is subject to change or withdrawal by Computer AssociatesInternational, Inc. (“<strong>CA</strong>”) at any time.This documentation may not be copied, transferred, reproduced, disclosed or duplicated, in whole or in part, withoutthe prior written consent of <strong>CA</strong>. This documentation is proprietary in<strong>for</strong>mation of <strong>CA</strong> <strong>and</strong> protected by the copyrightlaws of the United States <strong>and</strong> international treaties.Notwithst<strong>and</strong>ing the <strong>for</strong>egoing, licensed users may print a reasonable number of copies of this documentation <strong>for</strong>their own internal use, provided that all <strong>CA</strong> copyright notices <strong>and</strong> legends are affixed to each reproduced copy. Onlyauthorized employees, consultants, or agents of the user who are bound by the confidentiality provisions of thelicense <strong>for</strong> the software are permitted to have access to such copies.This right to print copies is limited to the period during which the license <strong>for</strong> the product remains in full <strong>for</strong>ce <strong>and</strong>effect. Should the license terminate <strong>for</strong> any reason, it shall be the user’s responsibility to return to <strong>CA</strong> the reproducedcopies or to certify to <strong>CA</strong> that same have been destroyed.To the extent permitted by applicable law, <strong>CA</strong> provides this documentation “as is” without warranty of any kind,including without limitation, any implied warranties of merchantability, fitness <strong>for</strong> a particular purpose ornoninfringement. In no event will <strong>CA</strong> be liable to the end user or any third party <strong>for</strong> any loss or damage, direct orindirect, from the use of this documentation, including without limitation, lost profits, business interruption,goodwill, or lost data, even if <strong>CA</strong> is expressly advised of such loss or damage.The use of any product referenced in this documentation <strong>and</strong> this documentation is governed by the end user’sapplicable license agreement.The manufacturer of this documentation is Computer Associates International, Inc.Provided with “Restricted Rights” as set <strong>for</strong>th in 48 C.F.R. Section 12.212, 48 C.F.R. Sections 52.227-19(c)(1) <strong>and</strong> (2) orDFARS Section 252.227-7013(c)(1)(ii) or applicable successor provisions.© 2003 Computer Associates International, Inc.All trademarks, trade names, service marks, <strong>and</strong> logos referenced herein belong to their respective companies.
Technical UpdatesMay 2003The following table lists May 2003 Cookbook updates introduced in thisdocument. This version completely replaces the October 2002 version.ChapterImplementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong><strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390EnvironmentImplementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong><strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390EnvironmentImplementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong><strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390EnvironmentImplementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong><strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390EnvironmentImplementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong><strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390EnvironmentImplementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong><strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390EnvironmentDescriptionIn<strong>for</strong>mation on the BPXROOT acid addedto the "ACIDS Needed to Install UnixSystems Services" section.In<strong>for</strong>mation on how to concatenate the<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> BPXWIRACmember ahead of the IBM REXX exec inthe "TSO ISHELL Support" section.Updated syntax <strong>for</strong> the ST comm<strong>and</strong> inthe "Tracing UNIX System Services(OMVS)" section.Additional syntax added to “How toDefine a Sysem Default User (UID) <strong>and</strong>Group (GID)” section.Additional syntax added to “<strong>OS</strong>/390ServerPac Upgrade” section regardingadministering source protection in <strong>eTrust</strong><strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>.Added “Third Party Vendor” section.Technical Updatesiii
ContentsChapter 1: Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or<strong>OS</strong>/390 Environmentz/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 Compatibility ............................................................... 1–2Upgrade Solutions ........................................................................ 1–2Upgrade Solution Updates ................................................................. 1–3Hyper Solution Delivery ................................................................... 1–3z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 Product/Component Naming Convention ..................................... 1–4z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 Release-Specific <strong>Security</strong> Concerns ............................................ 1–4z/<strong>OS</strong> V1R1 <strong>and</strong> Above .................................................................... 1–5z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 V2R10 <strong>and</strong> Above........................................................ 1–5<strong>OS</strong>/390 V2R9 <strong>and</strong> Above .................................................................. 1–5<strong>OS</strong>/390 V2R8 <strong>and</strong> Above .................................................................. 1–5<strong>OS</strong>/390 V2R7 <strong>and</strong> Above .................................................................. 1–6<strong>CA</strong> LDAP Server <strong>for</strong> z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 ......................................................... 1–6OpenEdition MVS / UNIX System Services Support ............................................. 1–6Controlling Access to UNIX System Services................................................. 1–8How to Define UNIX System Services Users ............................................. 1–8How to Define UNIX System Services Groups............................................ 1–9How to Assign Users to Groups under <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> ............................. 1–10How to Dynamically Change Your Default Group ....................................... 1–10How to Define a System Default User (UID) <strong>and</strong> Group (GID) ............................ 1–10How to use the AutoUID/AutoGID Enhancement <strong>for</strong> <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> ............... 1–11How to Refresh UID <strong>and</strong> GID Tables ................................................... 1–12How to List All UIDs <strong>and</strong> GIDs ........................................................ 1–12How to List Who Has UID(0) .......................................................... 1–12Password Assignment <strong>for</strong> UID(0) Acids .................................................... 1–13ACIDs Needed to Install UNIX System Services............................................. 1–13Defining the OMVS Started Task ACIDs ................................................ 1–13Defining Other OMVS Started Task ACIDs ................................................. 1–15TSO ISHELL Support..................................................................... 1–15How to Create the Superuser Administrator ACID .......................................... 1–15Contentsiii
Superuser Granularity ................................................................... 1–16CHOWN UNRESTRICTED (Control Option) ........................................... 1–18z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 UNIX System Services: User Limits ...................................... 1–18z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 ServerPac upgrade ..................................................... 1–19Logging UNIX System Services <strong>Security</strong> Calls .............................................. 1–19Tracing UNIX System Services (OMVS) ....................................................... 1–20UNIX System Services Reporting.......................................................... 1–21TSSOERPT Output Description ....................................................... 1–23Using TCP/IP............................................................................... 1–29Establishing <strong>Security</strong> <strong>for</strong> TCP/IP <strong>and</strong> OE/TCPIP (Communications Server IP <strong>for</strong> z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390)........................................................................................ 1–29TCP/IP SERVAUTH Class ............................................................... 1–30VMCF <strong>and</strong> TNF subsystems (<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> started be<strong>for</strong>e JES) ....................... 1–31IP Address Protection .................................................................... 1–32Using FTP .................................................................................. 1–32How to Secure FTP ...................................................................... 1–33How to Secure FTP <strong>for</strong> UNIX System Services .............................................. 1–33Using TELNET.............................................................................. 1–35How to Secure TELNET <strong>for</strong> UNIX System Services ......................................... 1–35InfoPrint Server <strong>for</strong> z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 (z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 Print Server) .......................... 1–36WebSphere Application Server <strong>for</strong> z/<strong>OS</strong> AND <strong>OS</strong>/390 ......................................... 1–36Authorization Checking.................................................................. 1–38Server Authorization Checking........................................................ 1–39Level of Trust <strong>and</strong> Authority <strong>for</strong> Regions............................................... 1–39User Identification, Authentication <strong>and</strong> Network <strong>Security</strong> ................................... 1–40Identification <strong>and</strong> Authentication ..................................................... 1–43WASADM .............................................................................. 1–43<strong>Security</strong> Auditing........................................................................ 1–47Lotus Domino Go Webserver ................................................................. 1–47Installing Domino Go Webserver on a <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>-secured System.................. 1–48Lotus Notes Server .......................................................................... 1–50Lotus Notes <strong>and</strong> Novell Directory Services <strong>for</strong> z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 ................................ 1–51Digital Certificate Support ................................................................... 1–51Associating a Unique Digital Certificate with a User ........................................ 1–52General Rules ........................................................................... 1–53Third Party Vendors ..................................................................... 1–53Adding a Digital Certificate to an ACID Record ............................................ 1–54Generating a Digital Certificate <strong>and</strong> Adding It to a User ..................................... 1–56Listing Digital Certificate In<strong>for</strong>mation ..................................................... 1–60Generating a Certificate Request .......................................................... 1–61Changing a User's Certificate ............................................................. 1–62iv<strong>Security</strong> Cookbook
Certificate Replacement (Renewal)......................................................... 1–62Changing a Certificate's Status ............................................................ 1–63Changing a Certificate's Label ............................................................. 1–63Removing a Certificate from a User ........................................................ 1–64Determining if a Certificate has been Added to <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> ......................... 1–64Exporting Certificates to Data Sets ......................................................... 1–65Sharing Certificates on Key Rings.......................................................... 1–66Creating a Key Ring .................................................................. 1–66Adding a Certificate to a Key Ring ..................................................... 1–67Removing a Key ring from an acid ..................................................... 1–67Extracting Certificates from Key Rings ..................................................... 1–68Extracting Private Keys ................................................................... 1–68Reconnecting Private Keys ................................................................ 1–69Listing Key Ring In<strong>for</strong>mation ............................................................. 1–69Managing Certificate Serial Numbers ...................................................... 1–69CERTADM .............................................................................. 1–70Certificate Name Filtering Support ............................................................ 1–73Managing Certificate Name Filters......................................................... 1–75Managing Criteria Maps .................................................................. 1–77Creating Certificate Name Filter Scenarios.................................................. 1–78Listing Filtering In<strong>for</strong>mation .............................................................. 1–79Init ACEE Changes <strong>for</strong> Search Sequence.................................................... 1–79Search Sequence Scenario ............................................................. 1–80Kerberos .................................................................................... 1–81Local Server Configuration................................................................ 1–81Customizing your Local Environment...................................................... 1–82Defining Your Local Realm ............................................................... 1–82Defining Local Principals ................................................................. 1–84Password Change Server ACID ........................................................... 1–85Preparing Local Principal ACIDs <strong>for</strong> Kerberos .............................................. 1–85DCE Incompatibility.................................................................. 1–86<strong>Security</strong> Considerations ............................................................... 1–86Mapping of Foreign Environments ............................................................ 1–87Mapping Foreign Realms ................................................................. 1–87Mapping Foreign Principal Names......................................................... 1–89DCE Support ................................................................................ 1–90Distributed File Service (DFS) ................................................................. 1–90Distributed File Server SMB SUPPORT ........................................................ 1–91SMB ENCRYPTED PASSWORD SUPPORT................................................. 1–91NFS (Network File System) ................................................................... 1–92<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> Support <strong>for</strong> z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 NFS.................................... 1–93Contentsv
WLM (Workload Management)............................................................... 1–94z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 <strong>Security</strong> Server Support..................................................... 1–94RACF .................................................................................. 1–95DCE <strong>Security</strong> Server ..................................................................... 1–96Firewall Technologies .................................................................... 1–97LDAP Server ............................................................................ 1–98DB2 <strong>Security</strong> Exit ........................................................................ 1–99Integrated Cryptographic Services ........................................................ 1–99Chapter 2: Controlling Access to the Hierarchical File SystemControlling HFS Using the Native UNIX <strong>Security</strong> Model ..........................................2–1Processes that Affect HFS <strong>Security</strong> ..........................................................2–3HFS FASTPATH Checking .............................................................2–3MOUNT N<strong>OS</strong>ECURITY ................................................................2–3Program Control in the UNIX Environment ..............................................2–3Controlling HFS Using <strong>CA</strong> SAF HFS <strong>Security</strong> ....................................................2–4<strong>CA</strong> SAF File Access <strong>Security</strong> ................................................................2–4Path Name Translation .................................................................2–5HFSSEC Resource Class ................................................................2–6Permission Considerations..............................................................2–6Reporting .................................................................................2–7Securing HFS Functions........................................................................2–7System Functions ..........................................................................2–7System Functions (IBMFAC ATTRIBUTE)................................................2–8File Functions .............................................................................2–9File Functions (IBMFAC) ...............................................................2–9Sample Permissions...................................................................... 2–10Implementing <strong>CA</strong> SAF HFS <strong>Security</strong> .......................................................... 2–11HFSSEC Control Option ..................................................................... 2–12Exit Processing .......................................................................... 2–12Troubleshooting ......................................................................... 2–14Reporting ........................................................................... 2–14OPTIONS(32) ....................................................................... 2–14Diagnostics.......................................................................... 2–15TSSUTIL/SAF Reference Tables ....................................................... 2–15<strong>CA</strong> SAF HFS ADD/PERMIT Generation Utility ............................................ 2–22Messages ................................................................................... 2–27vi<strong>Security</strong> Cookbook
Chapter 3: Using the Sysplex Coupling FacilityThe SYSPLEX XES Function ................................................................... 3–1The SYSPLEX XCF Function ................................................................... 3–3<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> <strong>and</strong> the SYSPLEX XES Function............................................ 3–3<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> <strong>and</strong> the SYSPLEX XCF Function ........................................... 3–5XCF(*) Control Option..................................................................... 3–5Controlling Access to XCF Policies.......................................................... 3–5Defining the Sysplex to <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> ................................................... 3–6Managing the Coupling Facility ................................................................ 3–6CFRM Policy............................................................................... 3–7Altering the Coupling Facility Structure Size..................................................... 3–7Rebuilding the Coupling Facility Structure .................................................. 3–8Connecting to the Structure ................................................................ 3–9Defining SYSTEM LOGGER to <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> ............................................ 3–9Appendix A: IMVSECURIMVSECUR ................................................................................. A–1Appendix B: RACF to <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> TranslationADDGRP .................................................................................... B–3ADDUSER ................................................................................... B–3ALTUSER.................................................................................... B–3CLASS....................................................................................... B–3PERMIT ..................................................................................... B–4RDEFINE .................................................................................... B–4RACF Attribute Translation.................................................................... B–5IndexContentsvii
Chapter1Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong><strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390Environment<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>® <strong>Security</strong> <strong>for</strong> z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 (<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>)protects in<strong>for</strong>mation systems <strong>and</strong> the data they manage from unauthorizeddisclosure, modification, <strong>and</strong> destruction. Since its inception, <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong><strong>Secret</strong> has maintained leadership in the <strong>OS</strong>/390 marketplace through aggressivedelivery of new releases, high-quality technical support services, <strong>and</strong> adapting tothe ever-changing mainframe marketplace.The initial release of <strong>OS</strong>/390 provided an installation vehicle that packagedtogether the products that you normally selected when building your baseoperating system (ESA 5.2.2 <strong>and</strong> major subsystems such as VTAM, Data FacilityProduct, Open Edition <strong>and</strong> JES). With each new release of z/<strong>OS</strong>, additionalcomponents have been added. Each component is tested together, providing ahigher level of quality assurance. In addition, this methodology also af<strong>for</strong>ds<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> a more supportable environment.As each new release of z/<strong>OS</strong> is made available, <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> providesfull support of new features. The required maintenance <strong>and</strong> administrativechanges are fully documented in the product in<strong>for</strong>mational solutions (seeUpgrade Solutions section of this document). The majority of changes to z/<strong>OS</strong>,which affect security, are related to UNIX System Services <strong>and</strong> the couplingfacility. This document discusses these topics in detail. Traditional security taskssuch as CICS <strong>and</strong> data set protection are largely unaffected by z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390<strong>and</strong> are covered in the st<strong>and</strong>ard <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> documentation.This cookbook provides a "how to" guide <strong>for</strong> implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong><strong>Secret</strong> in a UNIX System Services z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 environment.The administrative comm<strong>and</strong>s used in this book are also included in Appendix A<strong>and</strong> in <strong>CA</strong>I.SAMPJCL (IMVSECUR, WASADM) on the <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>maintenance tape.Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–1
z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 Compatibilityz/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 CompatibilityOur maintenance philosophy is to test each new z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 release atminimum with the two most recent generally available genlevels. Any requiredcompatibility maintenance is prepared <strong>and</strong> published concurrently with IBM’savailability. It is not our intent to time releases of <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> tocoincide with each z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 release.In general, the first Service Pack published after a z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 release willincorporate any compatibility maintenance. For those clients requiringcompatibility prior to Service Pack availability, <strong>CA</strong> has developed the followingmechanisms to provide this maintenance immediately. This in<strong>for</strong>mation is madegenerally available in Upgrade Solutions through StarTCC on the Web or usingtelephone support.Upgrade SolutionsUpgrade solutions exist <strong>for</strong> each GA release of z/<strong>OS</strong> or <strong>OS</strong>/390. <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong><strong>Secret</strong> documentation changes (update packets) are normally sent out with eachnew <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> genlevel. Changes to the support of z/<strong>OS</strong> or <strong>OS</strong>/390that occur between <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> genlevels are documented in thesesolutions.These solutions:■■■Exist <strong>for</strong> each release of z/<strong>OS</strong> or <strong>OS</strong>/390Provide a list of the latest recommended maintenanceInclude z/<strong>OS</strong> or <strong>OS</strong>/390 release-specific in<strong>for</strong>mationTo receive the latest updates:■■Download Upgrade solutions from StarTCC (<strong>CA</strong> Support on the Internet)eSupport.<strong>CA</strong>I.COMCall Computer Associates Technical Support <strong>and</strong> request the specific z/<strong>OS</strong>or <strong>OS</strong>/390 release solutionTo download or view solutions from StarTCC, per<strong>for</strong>m the following stepsstarting at the StarTCC main menu:1. Select SEARCH <strong>CA</strong> KNOWLEDGE BASE – SIMPLE.2. Select UPGRAD—GENERAL UPGRADE from the product drop-downwindow.3. Input TSSMVS as the keyword.4. Select the SEARCH button.1–2 Cookbook
z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 CompatibilityThe list returned will include all of the <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> upgrade solutions.In addition to the z/<strong>OS</strong> or <strong>OS</strong>/390 specific solutions, the COMPATIBILITY OFeTRUST <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> WITH OTHER PRODUCTS solution will also be listed. Itis important that you review both the z/<strong>OS</strong> or <strong>OS</strong>/390 <strong>and</strong> compatibilitysolutions.Upgrade Solution UpdatesTo determine if an in<strong>for</strong>mational upgrade solution has been recently updated,per<strong>for</strong>m the following steps from the StarTCC main menu:1. Select DISPLAY NEWS ITEMS.2. Select UPGRAD SOLUTIONS UPDATED SINCE xx/xx/xxxx (latest dateavailable).3. Finally, select <strong>and</strong> view the <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> solution (will appear onlist if updated since date).The news items list provides 3 weekly "updated since" options at any given time.It is recommended that you check this option on a twice per month basis.Hyper Solution DeliveryStarTCC provides the option <strong>for</strong> you to receive an email automatically (sent toyour Internet email address) whenever an <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> APAR ispublished as a Hyper. This includes any z/<strong>OS</strong> or <strong>OS</strong>/390-related Hypersolutions.To set up this Hyper Solution Delivery option under StarTCC, per<strong>for</strong>m thefollowing steps, starting at the main menu:1. Select Hyper Solution Delivery2. Select TSSMVS—5.1 or 5.2—TSSMVS from the product group drop-downwindow3. Select the CHECKOFF buttonOnce you have completed these steps, an email is sent automatically to yourInternet email address (as specified in your StarTCC profile) whenever any newHyper maintenance or product announcements are made.Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–3
z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 Product/Component Naming Conventionz/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 Product/Component Naming ConventionAs each release of an operating system is made generally available, IBM oftenchanges the name of the supplied components or products. The following tablesprovide a reference <strong>for</strong> these supported releases.ProductTCP/IPCommunications Server IP <strong>for</strong> <strong>OS</strong>/390SecureWay Communications Server<strong>for</strong> <strong>OS</strong>/390Operating System Release<strong>OS</strong>/390 Version 2 Release 4 <strong>and</strong> Below<strong>OS</strong>/390 Version 2 Release 5 <strong>and</strong> Above<strong>OS</strong>/390 Version 2 Release 8 <strong>and</strong> AboveProductOpen Edition MVSUNIX System Services <strong>for</strong> <strong>OS</strong>/390Operating System Release<strong>OS</strong>/390 Version 2 Release 5 <strong>and</strong> Below<strong>OS</strong>/390 Version 2 Release 6 <strong>and</strong> AboveProductInternet Connection <strong>Security</strong> ServerOperating System Release<strong>OS</strong>/390 Version 1 Release 3 <strong>and</strong> BelowLotus Domino Go Webserver <strong>OS</strong>/390 Version 2 Release 4 & 5SecureWay Application Server <strong>for</strong><strong>OS</strong>/390<strong>OS</strong>/390 Version 2 Release 8 <strong>and</strong> AboveProductCICSCICS Transaction ServerOperating System ReleaseMVS 5.1 <strong>and</strong> BelowMVS/ESA 5.2 <strong>and</strong> Abovez/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 Release-Specific <strong>Security</strong> ConcernsSeveral z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 release-specific <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> securityrequirements exist. In addition to the following in<strong>for</strong>mation, it is important thatyou review the in<strong>for</strong>mational solutions discussed in the Upgrade Solutionssection of this document. These solutions contain the latest z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390release-specific implementation procedures <strong>and</strong> a list of the latest recommended<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> maintenance.1–4 Cookbook
z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 Release-Specific <strong>Security</strong> Concernsz/<strong>OS</strong> V1R1 <strong>and</strong> AboveTwo new resource classes have been introduced by the Websphere ApplicationServer as EJBROLE <strong>and</strong> GEJBROLE. These classes are used to control access tomethods within Enterprise Java Beans (EJB). <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> now allowsresource names to be in mixed case to support the functioning of these resourceclasses.<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> now supports two new SAF callable services, R_cacheserv<strong>and</strong> R_proxyserv. R_cacheserv is used to request the storage or retrieval ofin<strong>for</strong>mation from a cache. R_proxyserv is used to request the LDAP Server toretrieve in<strong>for</strong>mation from a directory in<strong>for</strong>mation tree (DIT).z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 V2R10 <strong>and</strong> Above<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> fully supports the Network <strong>and</strong> Privacy AuthenticationServer, known as Kerberos. <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> stores <strong>and</strong> administersin<strong>for</strong>mation about realms <strong>and</strong> principals <strong>for</strong> network authentication in the SDT<strong>and</strong> in the security file.In addition, <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> fully supports the SERVAUTH class. Withz/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 V2R10, TCP/IP uses the SERVAUTH class to protect variousTCP/IP resources from unauthorized access.<strong>OS</strong>/390 V2R9 <strong>and</strong> Above<strong>OS</strong>/390 V2R9 introduces support <strong>for</strong> Digital Certificate keyring <strong>and</strong> filteringfunctionality. Contact <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> Support to obtain the requiredmaintenance <strong>for</strong> the above new features.<strong>OS</strong>/390 V2R8 <strong>and</strong> Above<strong>OS</strong>/390 V2R8 introduces support <strong>for</strong> a more granular approach to securingsuperuser authorities. <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> can be used to grant limited (orselected) subsets of superuser privileges to specific users, rather than having togrant complete superuser authority.<strong>OS</strong>/390 V2R8 also introduces support <strong>for</strong> User Limits. With this support you cancontrol the amount of resources consumed by individual <strong>OS</strong>/390 UNIX users.The BPXPRMxx member of PARMLIB determines resource limits <strong>for</strong> <strong>OS</strong>/390UNIX users (global setting). <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> can be used to store supporteduser limit settings <strong>for</strong> each acid.Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–5
<strong>CA</strong> LDAP Server <strong>for</strong> z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390<strong>OS</strong>/390 V2R7 <strong>and</strong> AboveIf you attempt to access an 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 will occur if the HFS data set is not mounted to OMVS. This can occur on<strong>OS</strong>/390 2.7 <strong>and</strong> higher systems. When data set in<strong>for</strong>mation is requested <strong>for</strong> anunmounted HFS data set, <strong>OS</strong>/390 UNIX services will write in<strong>for</strong>mation to the/tmp directory. If the user making the request does not have write access, theerror message is displayed. To avoid this error, you must ensure that the publicaccess permission <strong>for</strong> the /tmp directory is set to allow all access. The permissionbits <strong>for</strong> the /tmp directory should be set to 777 to allow all access.<strong>CA</strong> LDAP Server <strong>for</strong> z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> permits secured access to user in<strong>for</strong>mation throughst<strong>and</strong>ard LDAP protocols. For example, an LDAP session can query, delete, add,<strong>and</strong> modify in<strong>for</strong>mation including user-defined fields stored within the <strong>eTrust</strong><strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> acid record. <strong>CA</strong> clients are able to take advantage of these LDAPcapabilities using the <strong>CA</strong> supplied LDAP-compliant directory server <strong>for</strong> thez/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 plat<strong>for</strong>m. The <strong>CA</strong> LDAP Server <strong>for</strong> z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 includesthese capabilities:■■■■■■Integration with <strong>CA</strong> Common Services <strong>for</strong> z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390Access control <strong>for</strong> directory in<strong>for</strong>mationStrong LDAP server authenticationInteroperability with both <strong>CA</strong> <strong>and</strong> third party LDAP clientsA high-per<strong>for</strong>mance repositoryIntegration with the <strong>CA</strong> <strong>eTrust</strong> Solution SuiteOpenEdition MVS / UNIX System Services SupportIn distributed environments where users move across hardware plat<strong>for</strong>ms <strong>and</strong>operating systems to access multiple n-tier applications, security is a majorconcern. Sites want <strong>and</strong> need the same control over, <strong>and</strong> accountability <strong>for</strong>, data<strong>and</strong> resources accessed in an open system as they are used to having in theirmainframe environment.1–6 Cookbook
OpenEdition MVS / UNIX System Services SupportEach z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 release has included new <strong>and</strong> more robust versions ofUNIX System Services (USS). Initially called OpenEdition by IBM, these servicesallow UNIX applications to run on a z/<strong>OS</strong> or <strong>OS</strong>/390 mainframe. Since, theirinitial appearance in MVS 5.2.2, <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> has provided the ability toper<strong>for</strong>m the UNIX security administration necessary to manage these services<strong>and</strong> the UNIX file system. Beyond the base requirements to support thisenvironment, <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> provides powerful trace <strong>and</strong> reportingfunctions that allow you to audit UNIX security events.UNIX security is based on users <strong>and</strong> groups having a unique binary identifier, aUserID (UID) or a GroupID (GID). <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> lets you to define UIDs<strong>and</strong> GIDs <strong>and</strong> give them to those users needing UNIX services. Additionally,<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> provides the support to secure access to the UNIX filesystem.Specifically, <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> supports the following services in a UNIXSystem Services z/<strong>OS</strong> or <strong>OS</strong>/390 environment:■■■■■■■■Callable servicesHierarchical File System (HFS)Userid (UID) <strong>and</strong> Groupid (GID) definitionsHome <strong>and</strong> Path definitionsUNIX System Services AuditingUNIX System Services <strong>Security</strong> Trace FacilityUNIX System Services MVS Shell Setup Utility (ISHELL)Digital CertificatesThis section discusses <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> support <strong>for</strong> UNIX System Services(USS). Specifically, it covers these topics:■■■■■■■Acids needed to install UNIX System Services MVSDefining a default UID <strong>and</strong> GIDControlling access to UNIX System ServicesControlling access to the Hierarchical File System<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> records <strong>for</strong> UNIX System ServicesLogging UNIX System Services MVS security callsTracing UNIX System ServicesFor explanations <strong>and</strong> syntax of <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> comm<strong>and</strong> functions, seethe Comm<strong>and</strong> Functions Guide. For details on the reporting facility available with<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>, see the Report <strong>and</strong> Tracking Guide.Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–7
OpenEdition MVS / UNIX System Services SupportControlling Access to UNIX System ServicesWhen a user attempts to enter the UNIX System Services shell, <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong><strong>Secret</strong> verifies that the user is a USS user be<strong>for</strong>e the system initializes the shell.Be<strong>for</strong>e allowing access to the requested resource, <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> alsoverifies that the user associated with a program attempting to access a USSresource is a USS user.To define an acid as an UNIX System Services user, you must:■■■■define the user to <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>assign a UNIX System Services Groupassign a UNIX System Services UID to the userassign the user to a default groupHow to Define UNIX System Services UsersUNIX System Services recognizes acids by their assigned UID. UIDs can be anynumeric value from zero to 2,147,483,647. The OMVS segment of the acid definesan acid's UID, the user's home directory, <strong>and</strong> the initial program that the userwill run. The initial program is generally the shell program that the user invokes.The MS<strong>CA</strong> acid can not be used to sign on to USS.UID—A numeric keyword that accepts values from zero to 2,147,483,647. A UIDdefined with a value of zero indicates that this user is a superuser.This keyword must be unique to maintain individual accountability <strong>and</strong> control.A UID is required <strong>for</strong> all acids in UNIX System Services. <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> willnot allow a UID to be given if it is already assigned to another acid. A UID(0) isthe only UID that can be given to more than one acid.HOME—Defines the initial directory pathname. This is the initial directory usedwhen a user enters the OMVS comm<strong>and</strong> or enters the ISPF shell. The HOMEkeyword accepts from one to 1024 characters. Both uppercase <strong>and</strong> lowercasecharacters are allowed. If HOME isn't defined, UNIX System Services sets theinitial directory <strong>for</strong> the user to the root directory. HOME is optional.OMVSPGM—Defines the user's UNIX System Services shell program. This isthe first program started when the OMVS comm<strong>and</strong> is entered or when an USSbatch job is started using the BPXBATCH program. The OMVSPGM keywordaccepts from one to 1024 characters. Both uppercase <strong>and</strong> lowercase characters areallowed. If OMVSPGM isn't entered, USS gives control to the default shellprogram. OMVSPGM is optional.1–8 Cookbook
OpenEdition MVS / UNIX System Services SupportThe following example shows how to define user OMVSUSR as a superuser.Since HOME <strong>and</strong> OMVSPGM aren't explicitly specified, the defaults are taken<strong>for</strong> these fields.TSS ADD(OMVSUSR) UID(0)This example shows how to define user OMVSU2 as a regular user. The HOME<strong>and</strong> PROGRAM keywords are also used.TSS ADD(OMVSU2) UID(199) HOME(/u/omvsu2) OMVSPGM(/bin/sh)SUPERUSER—A superuser passes all UNIX System Services security checks<strong>and</strong>, there<strong>for</strong>e, can access all UNIX files. An acid can become a superuser in oneof two ways:■or■Have a UID(0)Use the SU (switch user) comm<strong>and</strong> if resource IBMFAC(BPX.SUPERUSER)has been permitted to that user.Other than the required started task acids, the only acids requiring a UID(0) arethe system programmers responsible <strong>for</strong> installing USS. All other acids shouldhave a non-zero UID <strong>and</strong> be permitted the necessary authorities in the classIBMFAC plus file permissions. The <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> resource class IBMFACis equivalent to the IBM FACILITY class.How to Define UNIX System Services GroupsUNIX System Services security is based on user <strong>and</strong> group ownership of files<strong>and</strong> processes. <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> uses the DFLTGRP <strong>and</strong> GROUP fields ofthe acid record to assign the user to a UNIX System Services group.<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> requires that the UID be unique <strong>for</strong> each acid (except UID0) <strong>and</strong> that the GID is unique <strong>for</strong> each group acid. (Only UID 0 can be assigned tomore than one acid.)The GROUP type acid defines UNIX System Services groups to <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong><strong>Secret</strong>. The GROUP type acid contains the OMVS segment, which consists of onefield: the GID keyword.GID is a numeric field that accepts values from zero to 2,147,483,647. This valuemust be unique to maintain control over a particular group. You can assign up to256 groups to a user, using the GROUP field.The following example shows how to create an OMVS GROUP acid <strong>for</strong> a groupcalled OMVSGRP <strong>and</strong> assign it a GID of 1.TSS CREATE(OMVSGRP) TYPE(GROUP) NAME(‘OMVSGROUP’) DEPT(OMVSDEPT)TSS ADD(OMVSGRP) GID(1)At least one OMVS group acid must exist prior to implementation.Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–9
OpenEdition MVS / UNIX System Services SupportFor more in<strong>for</strong>mation about how to set the owner, group, <strong>and</strong> other permissions<strong>for</strong> a file, see the MVS/ESA UNIX System Services User's Guide.How to Assign Users to Groups under <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>You assign a user's default group by setting the DFLTGRP field in that user'sacid.This example shows how to assign acid OMVSU2 to group OMVSGRP <strong>and</strong> thenassign that group as its default.TSS ADD(OMVSU2) GROUP(OMVSGRP)TSS ADD(OMVSU2) DFLTGRP(OMVSGRP)How to Dynamically Change Your Default GroupYou can change your default group by specifying a group when you log on toTSO. <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> validates the specified group by checking to see if itis in your GROUP list. If it isn't in your GROUP list, you won't have a defaultgroup <strong>for</strong> the current session.How to Define a System Default User (UID) <strong>and</strong> Group (GID)If a user has not been defined with a UID <strong>and</strong> group, <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> canbe used to define default values. Sites must evaluate their own security policy todetermine if all users should be given their own UIDs <strong>and</strong> GIDs. Overuse of thedefault feature is not recommended because it limits your ability to audit accesspermissions under USS.<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> provides support <strong>for</strong> default UID <strong>and</strong> GID through thecontrol options OMVSUSR <strong>and</strong> OMVSGRP. This is functionally equivalent toIBM's RACF implementation using FACILITY BPX.DEFAULT.USER.First, an acid must be defined with a valid OMVS segment. For example, a UID, aHOME <strong>and</strong> an OMVSPGM. This acid can then be used to provide these defaultsby specifying the OMVSUSR control option, which can be done dynamically orvia the TSS PARMFILE:TSS MODIFY(omvsusr(acidname))OMVSUSR(acidname)There are two methods <strong>for</strong> extracting the OMVS segment from a group. Bothmethods require a TYPE GROUP acid be defined. The first method is done usingcontrol option OMVSGRP:TSS MODIFY(omvsgrp(grpacid))OMVSGRP(grpacid)1–10 Cookbook
OpenEdition MVS / UNIX System Services SupportIf the OMVSGRP control option is not specified, the DFLTGRP from theOMVSUSR acid are used. Thus, the second way to specify a default group is toadd the default group to the OMVSUSR acid:TSS ADD('acidname') DFLTGRP('grpacid')To prevent a user with no UID or group from using the default values, add theNOOMVSDF attribute to the user acid.TSS ADD(acid) NOOMVSDFIf you define the BPX.DEFAULT.USER profile, all users will have access to z/<strong>OS</strong>or <strong>OS</strong>/390 UNIX. To limit access, define an OMVS segment with no UID. Doingthis will prevent unauthorized users from using a UNIX service. If users musthave anonymous access (<strong>for</strong> FTP or other socket use) without using the shell,define the initial program <strong>for</strong> the default user as /bin/echo. This allows users tohave a default UID without using the shell.How to use the AutoUID/AutoGID Enhancement <strong>for</strong> <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>The auto-assignment of the UID/GID numbers <strong>for</strong> the ADD or REPLACEcomm<strong>and</strong> includes the following features:■■■User can define a default rangeUser can restrict the search <strong>for</strong> an open number by entering a specific rangeIf no number is assigned <strong>and</strong> no range is given, AutoUID/GID restricts thesearch by checking through the defined default range■ If no range is given <strong>and</strong> there is no default range, AutoUID/GID starts at 1<strong>and</strong> searches until an available UID/GID is found■Zeros are excluded in the range searchExamplesTSS ADD|REP(acid|Group Acid) UID|GID(?) RANGE(,)orTSS ADD|REP(acid|Group Acid) UID|GID(?)orTSS ADD|REP(acid|Group Acid) UID|GID(?) RANGE(300,400)GID—Group Identification Number. Used in OMVS.UID—User Identification Number. Used in OMVS.range—Specifies a low <strong>and</strong> high value to be searched through in order to assigna UID/GID. The range can be 1 up to 2,147,483,647.Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–11
OpenEdition MVS / UNIX System Services SupportHow to Refresh UID <strong>and</strong> GID Tables<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> maintains in-storage tables of UIDs <strong>and</strong> GIDs <strong>and</strong> theirrelated acids. These tables are built during the initial startup of <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong><strong>Secret</strong>. These tables must be refreshed after a UID or GID is ADDed orREMOVEd from an acid. The following comm<strong>and</strong> will refresh these tables.TSS MODIFY(OMVSTABS)How to List All UIDs <strong>and</strong> GIDsA list of all UIDs <strong>and</strong> GIDs can be obtained by executing the followingcomm<strong>and</strong>s:TSS WHOOWNS UID(*)TSS WHOOWNS GID(*)How to List Who Has UID(0)A list of all users with UID(0) can also be obtained by executing the followingcomm<strong>and</strong>:TSS WHOHAS UID(0)FACILITY Class Resources (IBMFAC)See the UNIX Systems Services Planning Guide <strong>for</strong> more details of the BPX facilityresources classes.BPX.SUPERUSER—Allows non-superusers to gain superuser authority.(Control over UNIX comm<strong>and</strong> su). BPX.SUPERUSER ownership needs to beestablished in the following fashion:TSS ADD(dept) IBMFAC(BPX.)TSS permit comm<strong>and</strong>s can then be used to grant access to specific resourceslisted below.TSS PER(acid) IBMFAC(BPX.SMF)BPX.DAEMON—Allows daemon programs to validate user password <strong>and</strong> thenchange identity of a spawned address space (control over setuid () <strong>and</strong> seteuid () ).BPX.SERVER—Allows daemon programs to customize the securityenvironment of a thread.BPX.SMF—To restrict access <strong>for</strong> C/C++ applications to generate SMF recordswithout requiring APF authorization.BPX.DEBUG—To allow users to use dbx to debug programs that run asAPF-authorized or with BPX.SERVER authority.BPX.WLMSERVER—To allow users to use WLM server functions.1–12 Cookbook
OpenEdition MVS / UNIX System Services SupportBPX.STOR.SWAP—To allow users to make address spaces nonswappable.BPX.FILEATTR.APF—To allow users to turn on the APF-authorized attribute <strong>for</strong>an HFS file.BPX.FILEATTR.PROGCTL—To allow users to turn on the program controlledattribute <strong>for</strong> an HFS file.TSS PER(acid) IBMFAC(BPX.SMF) ACC(READ)Password Assignment <strong>for</strong> UID(0) AcidsA potential security concern exists <strong>for</strong> all acids defined with NOPW <strong>and</strong> UID(0).In certain scenarios, unauthorized access can occur with these acids using Telnetor Rlogin. To eliminate this potential security concern, you should addpasswords to all UID(0) assigned acids.TSS REPL(acid) PASS(xxxx,0)Several of the created started task acid definitions described in this documentspecify a password. Started task acids with passwords will cause a passwordprompt at the console on startup. This prompting is optional <strong>and</strong> can be turnedoff using the following methods:■■Control option setting OPTIONS(4) eliminates the console password promptat startup <strong>for</strong> the password protected STC acids.The OPTIONS control option must be set via the <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>parameter file. It can not be set with a MODIFY comm<strong>and</strong>.ACIDs Needed to Install UNIX System ServicesDuring the installation of UNIX System Services, you must create an acid <strong>for</strong> theOMVS started task <strong>and</strong> define the installer’s acid (typically a SYSPROG) as asuperuser via a UID(0).Defining the OMVS Started Task ACIDsUNIX System Services must be assigned an acid be<strong>for</strong>e you can begin using<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in this environment. Follow the steps below to create theOMVS started task acid.Step 1—Create the GROUP acids to which the started task acid are attached byissuing the following TSS comm<strong>and</strong>s:TSS CREATE(OMVSGRP) TYPE(GROUP) NAME('OMVS GROUP') DEPT(OMVSDEPT)TSS CREATE(TTY) TYPE(GROUP) NAME('REQ OMVS TTY GROUP') DEPT(OMVSDEPT)USS requires that a group name "TTY" must also exist, <strong>and</strong> it must be connectedto the OMVS started task acid. See the UNIX System Services Planning Guide <strong>for</strong>an explanation of TTY.Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–13
OpenEdition MVS / UNIX System Services SupportStep 2—Assign a GID (groupid) to the GROUP acids you created in Step 1.(Every group must have a GID number assigned to it.) A GID can be any numberfrom 0 to 2,147,483,647. Define a GID of 1 <strong>for</strong> the OMVSGRP group <strong>and</strong> a GID of2 <strong>for</strong> the TTY group by issuing the following TSS comm<strong>and</strong>:TSS ADD(OMVSGRP) GID(1)TSS ADD(TTY) GID(2)Step 3—You can now create the acid to be used <strong>for</strong> the OMVS started task.TSS CREATE(OMVSKERN) TYPE(USER) NAME('OMVS STC ACID') PASS(password,0)DEPT(dept) FACILITY(STC,APPC)FACILITY(APPC) is not required with <strong>OS</strong>/390 V2R4 <strong>and</strong> above.Step 4—Assign the acid to UNIX System Services MVS in the STC record.TSS ADD(STC) PROCNAME(OMVS) ACID(OMVSKERN)This example shows an acid created <strong>for</strong> OMVS as a started task.Step 5—Assign a UID to the STC acid created in Step 3. You must define theUNIX System Services MVS kernel started task acid as a superuser by assigningit a UID of 0.TSS ADD(OMVSKERN) UID(0)In accordance with UNIX System Services MVS requirements, giving an acid aUID of zero automatically designates her as a superuser.Step 6—Assign a default group to the STC acid.TSS ADD(OMVSKERN) DFLTGRP(OMVSGRP)Step 7—Assign the OMVSGRP <strong>and</strong> TTY groups to the OMVS acid by issuing thefollowing TSS comm<strong>and</strong>s:TSS ADD(OMVSKERN) GROUP(OMVSGRP)TSS ADD(OMVSKERN) GROUP(TTY)Step 8—Create the BPXROOT acid. The BPXPRMxx parameter SUPERUSER(xxxxxxx) identifies the userid to be used when a user issues 'SU' to change theirUID to 0. SU uses the function setuid() to accomplish this task. If theSUPERUSER(xxxxxxx) parameter is not specified in BPXPRMxx the useriddefaults to BPXROOT. This acid must be defined with a UID(0) <strong>and</strong> must nothave BPX.DAEMON authorization. Create this acid by issuing these comm<strong>and</strong>s:TSS CREATE(BPXROOT) TYPE(USER) NAME('BPXROOT ACID')PASS(password,0)DEPT(OMVSDEPT) FACILITY(APPC)TSS ADD(BPXROOT) GROUP(OMVSGRP) DFLTGRP(OMVSGRP) UID(0)FACILITY(APPC) is not required with <strong>OS</strong>/390 V2R4 <strong>and</strong> above.Step 9—Refresh the UID <strong>and</strong> GID tables.The following comm<strong>and</strong> will refresh these tables.TSS MODIFY(OMVSTABS)1–14 Cookbook
OpenEdition MVS / UNIX System Services SupportNow that the UNIX System Services kernel acid has been defined to <strong>eTrust</strong><strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>, you can start USS by issuing the st<strong>and</strong>ard operator comm<strong>and</strong> <strong>for</strong>started tasks. Starting with <strong>OS</strong>/390 V1R3, the OMVS kernel is part of BCP. Thest<strong>and</strong>ard MVS start <strong>and</strong> stop comm<strong>and</strong>s no longer apply.Defining Other OMVS Started Task ACIDsDefine acids <strong>for</strong> other OMVS started tasks by issuing the following comm<strong>and</strong>s:TSS CRE(INETD) TYPE(USER) NAME('OMVS INETD STC')DEPT(dept) FAC(STC) PASSWORD(password,0)TSS ADD(INETD) UID(0) GROUP(OMVSGRP) DFLTGRP(OMVSGRP)HOME(/) OMVSPGM(/bin/sh)TSS CRE(RMFGAT) TYPE(USER) NAME('OMVS RMFGAT')DEPT(dept) FAC(STC) PASSWORD(password,0)TSS ADD(RMFGAT) UID(0) GROUP(OMVSGRP) DFLTGRP(OMVSGRP)HOME(/) OMVSPGM(/bin/sh)TSS ADD(STC) PROCNAME(INETD) ACID(INETD)TSS ADD(STC) PROCNAME(RMFGAT) ACID(RMFGAT)TSS ADD(STC) PROCNAME(BPXOINIT) ACID(OMVSKERN)TSS ADD(STC) PROCNAME(BPXAS) ACID(OMVSKERN)TSO ISHELL SupportThe <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> TSSOPMAT file contains a replacement member <strong>for</strong>the IBM REXX exec BPXWIRAC. Copy TSSOPMAT(BPXWIRAC) to a partitioneddata set compatible with your TSO SYSEXEC data sets. Assure that this file isconcatenated ahead of the IBM supplied SYSEXEC data sets. Failure to do thisresults in a S0C1 ABEND when entering the ISHELL.How to Create the Superuser Administrator ACIDThe UNIX System Services Shell <strong>and</strong> Utilities installation process createsdirectories in the Hierarchical File System (HFS). To per<strong>for</strong>m the installationsteps, the user must have superuser authority.A superuser is a special User acid under UNIX System Services. The superuser isa trusted acid who can maintain the UNIX System Services system <strong>and</strong>administer security in the HFS. It is important to note that assigning superuserauthority to an acid doesn't give the user any authority within <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong><strong>Secret</strong>, only authority in UNIX System Services. A superuser's UID has a value ofzero.Use caution when assigning acids the superuser authority. A superuser passes allsecurity checks, meaning the superuser can access any UNIX file in the filesystem.Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–15
OpenEdition MVS / UNIX System Services SupportTo create a Superuser Administrator acid <strong>and</strong> give it the authority it needs,follow these directions:Step 1—Define the acid as a superuser by issuing the following TSS comm<strong>and</strong>:TSS ADD(acid) UID(0)ACID SYSPROG1 is defined as a superuser by setting the UID value to zero.Step 2—Define SYSPROG1 as a member of a group by issuing:TSS ADD(acid) GROUP(OMVSGRP) DFLTGRP(OMVSGRP)The example shows ACID SYSPROG1 changed so that this user can sign on <strong>and</strong>be validated as a member of group OMVSGRP. The acids of group OMVSGRPare a special subset of users who per<strong>for</strong>m system-related tasks.Superuser GranularitySuperuser Granularity support lets you avoid giving users superuser authorityvia UID(0). This is accomplished by allowing non-superuser users to have accessto new resources in the UNIXPRIV class. At <strong>OS</strong>/390 V2R8 <strong>and</strong> above, if a userdoesn't have a UID=0, but they do have access to one of the new resources,access is allowed. The following table defines the new resources <strong>and</strong> what accessis allowed by the resource.<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> SAF HFS security provides much greater superusergranularity than this method. See Chapter 2 of this guide <strong>for</strong> details onimplementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>'s SAF HFS security. Activating <strong>eTrust</strong><strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> SAF HFS security will override the superuser granularitysupport described in this section if there is an equivalent SAF HFS securityresource <strong>for</strong> the UNIXPRIV resource. If there is no SAF HFS resource, theUNIXPRIV resource is checked instead.Resource Name Access Given Functions AffectedSUPERUSER.FILESYS.FILE (READaccess or higher)SUPERUSER.FILESYS.FILE(UPDATE access or higher)SUPERUSER.FILESYS.FILE(CONTROL Access)SUPERUSER.FILESYS.CHOWNAllows a user to read any HFSfile <strong>and</strong> read or search anyHFS directoryAllows a user to write to anyexisting HFS file.Allows a user to write to anyHFS directory.Allows a user to changeownership of any file.Open*( <strong>for</strong> read, opendir(),readlink(), stat(), realpath(0)Open() <strong>for</strong> writeLink(), mkdir(), rename(),mdir(), syslink(), unlink().Chown()1–16 Cookbook
OpenEdition MVS / UNIX System Services SupportResource Name Access Given Functions AffectedSUPERUSER.FILESYS.MOUNTAllows a user to issue mount,unmount, quiesce, <strong>and</strong>unquiesce requests. changeownership of any file.SUPERUSER.FILESYS.PFSCTL Allows a user to call pfsctl() Pfsctl()SUPERUSER.FILESYS.VREGISTERSUPERUSER.IPC.RMIDSUPERUSER.PROCESS.GETPSENTSUPERUSER.PROCESS.KILLSUPERUSER.PROCESS.PTRACESUPERUSER.SETPRIORITYAllows a user to issuevregister() to register as a vfsfile serverAllows a user to do ipcrm callsto clean up leftover IPCmechanismsAllows users to see allprocessesAllows user to send signals toany processAllows users to use dbx totrace any processAllows a user to increase hispriority.Mount(), unmount(), quiesce(),unquiesce()Vregister()Ipcrm comm<strong>and</strong> user ofIPC_RMID <strong>for</strong> msgct(),semctl(), shmctl()Getpsent()—ps comm<strong>and</strong>Kill()DbxSetpriority(), nice()Superuser Granularity examples:Be<strong>for</strong>e you can give a user access to a SUPERUSER resource in the UNIXPRIVclass, you must per<strong>for</strong>m the following ADD comm<strong>and</strong>:TSS ADD(dept) UNIXPRIV(SUPERUSE)The following permission gives USER01 authority to read to any HFS file.TSS PERMIT(acid) UNIXPRIV(SUPERUSER.FILESYS.FILE) ACCESS(READ)The following permission gives USER01 authority to change ownership of a file.TSS PERMIT(acid) UNIXPRIV(SUPERUSER.FILESYS.CHOWN) ACCESS(READ)Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–17
OpenEdition MVS / UNIX System Services SupportCHOWN UNRESTRICTED (Control Option)A new <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> control option (CHOWNURS) exists to allow usersto use the CHOWN function to change file ownership <strong>for</strong> files that they own.This control option can be set using a TSS MODIFY comm<strong>and</strong>. To determine thecurrent active setting of CHOWNURS, issue a TSS MODIFY STATUS(BASE)comm<strong>and</strong>. This control option can be set to ON or OFF.ON—Allows users to use the chown function to change file ownership <strong>for</strong> theirfiles.OFF—User cannot change file ownership unless he is a superuser or is givenaccess to UNIXPRIV class SUPERUSER.FILESYS.CHOWN. This is the defaultsetting.z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 UNIX System Services: User LimitsWith this support, you can control the amount of resources that are consumed byindividual z/<strong>OS</strong> or <strong>OS</strong>/390 UNIX users. Prior to <strong>OS</strong>/390 V2R8, the BPXPRMxxmember of the PARMLIB determined resource limits <strong>for</strong> most z/<strong>OS</strong> or <strong>OS</strong>/390UNIX users. At <strong>OS</strong>/390 V2R8 <strong>and</strong> above, you can now override, at the user level,the parmlib setting defined in BPXPRMxx. The following table defines the newresources <strong>and</strong> what access is allowed by the resource.TSS Resource Range Member inBPXPRMxxDescriptionOECPUTMASSIZE7 to2,147,483,64710,485,760 to2,147,483,647MaxcputimeMaxassizeMaximum time (seconds) a process isallowed to use.Maximum address space region sizeallowed per process created via rlogin ortelnet.OEFILEP 3 to 65,535 Maxfileproc Maximum number of files that a singleprocess can have active or openconcurrently.PROCUSER 3 to 32,767 Maxprocuser Maximum number of processes a user canhave open at the same time.THREADS 0 to 100,000 Maxthreads Maximum number of pthread_createdthreads, including those running, queued,<strong>and</strong> exited but not detached, that a singleprocess can have concurrently active.MMAPAREA 1 to 16,777,216 Maxmmaparea Maximum amount of dataspace storage(pages) that can be allocated <strong>for</strong> memorymapping of HFS files.1–18 Cookbook
OpenEdition MVS / UNIX System Services SupportThe following authorization will limit USER01 to a maximum of 200 openprocesses at the same time.TSS ADD(acid) PROCUSER(200)To remove the above PROCUSER authorization, issue the following comm<strong>and</strong>:TSS REMOVE(acid) PROCUSERz/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 ServerPac upgradePrior to restoring the HFS, you must ensure that the proper authority is given tothe user ID that will submit the dialog jobs. This user ID must be a superuser(UID=0). 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 <strong>and</strong> thisutility does not yet use the BPX.SUPERUSER facility class to establish superuseridentification.To authorize the acid to run the PAX utility follow these directions:Step 1—Define the acid as a superuser by issuing the following TSS comm<strong>and</strong>:TSS ADD(acid) UID(0)ACID SYSPROG1 is defined as a superuser by setting the UID value to zero.Step 2—Define SYSPROG1 as a member of a group by issuing:TSS ADD(acid) GROUP(OMVSGRP) DFLTGRP(OMVSGRP)Step 3—IBMFAC authorizations:TSS PERMIT(acid) IBMFAC(BPX.FILEATTR.APF) ACC(READ)TSS PERMIT(acid) IBMFAC(BPX.FILEATTR.PROGCTL) ACC(READ)orTSS PERMIT(acid) IBMFAC(BPX.FILEATTR.) ACC(READ)Logging UNIX System Services <strong>Security</strong> CallsAudit capability at the file level exists within the UNIX System Servicesenvironment. To implement audit within UNIX System Services at the file ordirectory level use:CHAUDIT—specify audit options <strong>for</strong> individual files or directoriesOnce audit is set <strong>for</strong> a file or directory using the CHAUDIT comm<strong>and</strong>, SMFrecords are written <strong>for</strong> the file or directory designated activity. This can includeaccess, as well as, changes to permission bit settings.The full syntax of the CHAUDIT comm<strong>and</strong> is documented in the <strong>OS</strong>/390 UNIXSystem Services Comm<strong>and</strong> Reference Guide.Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–19
Tracing UNIX System Services (OMVS)Tracing UNIX System Services (OMVS)The SECTRACE facility, used to trace SAF requests in the <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>environment, also is available to trace SAF requests made by OMVS. The onlyallowable value <strong>for</strong> the DEST= parameter of the TYPE=OMVS SECTRACEcomm<strong>and</strong> is DEST=SYSLOG.To start SECTRACE <strong>for</strong> OMVS, issue the following comm<strong>and</strong>:ST SET,TYPE=OMVS,FUNC=XXXX,DEST=SYSLOG,ENDFUNC ID=xxx can be one of seven values. Each function traces a set of relatedOMVS services.The seven functions <strong>and</strong> the services that they trace are:FunctionALLCHANGECHECKGETINITMAKEMISCSETServiceTraces all OMVS services.Traces R_chown, R-chaudit, <strong>and</strong> R_cmod.Traces ck_access, ck_priv, ck_process_owner,ck_file_owner, R_ptrace, ck_IPC_access,ck_owner_two_files, R_IPC_ctl, <strong>and</strong> R_dceauth.Traces getUMAP, getGMAP, R_getgroups,R_getgroupsbyname, get_uid_gid_supgrps, R_dceinfo,R_dcekey, R_dceuid, <strong>and</strong> R_usermap.Traces initACEE, initUSP, deleteUSP, <strong>and</strong> R_<strong>for</strong>k.Traces makeFSP, makeISP, <strong>and</strong> make_root_FSP.Traces audit, query_file_security_options, <strong>and</strong>query_system_security_options.Traces R_umask, R_setegid, R_seteuid, R_setgid,R_setuid, R_exec, clear_setid, <strong>and</strong> R_admin.The OMVS services are documented in the IBM <strong>OS</strong>/390 <strong>Security</strong> Services CallableServices Guide. You should only use the OMVS SECTRACE when instructed to by<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> Technical Support due to the large volume of trace entriespossible in the OMVS environment. It is usually easier to debug an OMVSproblem using the TSSOERPT report, because it shows more in<strong>for</strong>mation thanthe trace. All of the OMVS services write SMF records when the service returnswith a non-zero return code.1–20 Cookbook
Tracing UNIX System Services (OMVS)Stopping the SECTRACE <strong>for</strong> OMVSTo disable the SECTRACE <strong>for</strong> OMVS, issue the following comm<strong>and</strong>, where xxxxis the identifier assigned to the SECTRACE:ST DISABLE,ID=XXXX,ENDYou can restart a disabled trace by entering an enable comm<strong>and</strong>. To start adisabled trace, issue the following comm<strong>and</strong>, where xxxx is the identifierassigned to the SECTRACE:ST ENABLE,ID=XXXX,ENDTo stop the SECTRACE <strong>for</strong> OMVS, issue the following comm<strong>and</strong>, where xxxx isthe identifier assigned to the SECTRACE:ST DEL,ID=XXXX,ENDUNIX System Services ReportingTSSOERPT UtilityAuthority <strong>and</strong> ScopeThe batch utility program, TSSOERPT, processes security-related activityrecorded in SMF data sets. To monitor user activity in a UNIX System Servicesenvironment, <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> logs security events under UNIX SystemServices to SMF using the st<strong>and</strong>ard <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> SMF record. Logrecords are written <strong>for</strong> any security event that denies the acid access to a UNIXSystem Services facility. These records can assist you in determining the UID <strong>and</strong>GID of the acid involved in the attempted access.<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> per<strong>for</strong>ms authorization checking to determine whether theperson submitting the TSSOERPT job is authorized to view or manipulate theinput SMF data. You can only extract those incidents that are generated <strong>for</strong> acidswithin the scope of your authority. The scopes are:■■■■■■S<strong>CA</strong>—every eventLS<strong>CA</strong>—every event within the LS<strong>CA</strong>s scopeZ<strong>CA</strong>—entire zone or specific divisions, departments or acids within the zoneV<strong>CA</strong>—entire division or specific departments or acids within the divisionD<strong>CA</strong>—entire department or specific acids within the departmentUSER—himselfImplementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–21
Tracing UNIX System Services (OMVS)The following sample JCL, or a user-written substitute <strong>for</strong> the job stream, can beused to run the TSSOERPT report.//TSSOERPT JOB 1,'UNIX SYSTEM SERVICES MVS RPT',MSGCLASS=A,TYPRUN=HOLD//*//REPORT EXEC PGM=TSSOERPT//SYSPRINT DD SYSOUT=*//SYSUDUMP DD SYSOUT=*//RECMAN1 DD DSN=SYS1.MAN1,DISP=SHR//SYSIN DD.The selection criteria used in generating UNIX System Services MVS reports arelisted below, with brief descriptions. All selection criteria are described in detailafter the listing.TITLE(string)—Specifies a character string added to other title in<strong>for</strong>mation at thetop of the report. This character string can be up to 35 characters in length. If youdo not specify this parameter, the report generator uses the first 35 characters inthe PARM field of the EXEC statement. If this character string is longer than 35characters, the first 35 characters are used.LINECNT(linecount)—The LINECNT(linecount) parameter specifies thenumber of output lines to be printed on a page. To prevent splitting ofin<strong>for</strong>mation, <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> report generators that issue multiple linereports check to see whether a complete report item will fit on a page. Themaximum number of output lines per page is limited only by the physicalconstraints of the output media being used, or to 99,999 lines.SDATE(00000|yyddd)—Specifies the start date of the report in Julian date<strong>for</strong>mat. SMF records generated be<strong>for</strong>e the SDATE value are ignored. The default,00000, specifies all available records.EDATE(99365|yyddd)—Specifies the ending Julian date from which reportin<strong>for</strong>mation is selected. When combined with the SDATE parameter, thisparameter creates a window <strong>for</strong> report content. The default, 99365, specifies upto the time the job is run.STIME(0000|hhmm)—Specifies the start time <strong>for</strong> the interval from which SMFrecords are selected. Specifies the time at which reporting on the selected SMFrecords is to begin. This time is based on a 24-hour clock. Any SMF recordsgenerated be<strong>for</strong>e this specified time of day are ignored. The selection of recordsbegins at the STIME specified <strong>for</strong> each date in the SDATE/EDATE range. Thedefault, 0000, specifies midnight.ETIME(2359|hhmm)—Specifies the end time <strong>for</strong> the interval from which SMFrecords are selected. Specifies the time at which reporting on the selected SMFrecords is to end. Any SMF records generated after this specified time of day areignored. The default, 2359, specifies one minute be<strong>for</strong>e midnight.UID(value)—Specifies the UNIX System Services MVS UserID <strong>for</strong> which youintend to collect security in<strong>for</strong>mation. Acceptable numeric values range fromzero to 2,147,483,647. This field is not maskable.1–22 Cookbook
Tracing UNIX System Services (OMVS)GID(value)—Specifies the UNIX System Services MVS GroupID <strong>for</strong> which youintend to collect security in<strong>for</strong>mation. Acceptable numeric values range fromzero to 2,147,483,647. This field is not maskable.USER(acid)—Specifies the acid <strong>for</strong> which you want UNIX System Services MVSsecurity in<strong>for</strong>mation collected. This field is not maskable.GROUP(acid)—Specifies the group <strong>for</strong> which you want UNIX System ServicesMVS security in<strong>for</strong>mation collected. This field is not maskable.SERVICE(service)—Specifies the name of the SAF callable service <strong>for</strong> which youwant security in<strong>for</strong>mation collected.TSSOERPT Output DescriptionTSSOERPT <strong>for</strong>mats <strong>and</strong> reports security events occurring in the UNIX SystemServices environment. The output is extracted from the System ManagementFacility (SMF) data sets.The following is a sample of the output of TSSOERPT with DETAIL specified inthe job. TSSOERPT shows the logging of security events in an UNIX SystemServices MVS environment:02/02/98 98.033 11.54.44 — OMVS LOGGING REPORT — PAGE 1SERVICE USERID GROUP UID GID SAF RC RSNDATE TIME JOBNAME SOURCE SYSID CPUINIT_USP STRTE01 OMVSGRP 0 2 0 0 002/02/98 98.033 11:52:50 STRTE01 XE14 XE14Home : /U/STRTE01CHECK_ACCESS STRTE01 OMVSGRP 0 2 0 0 002/02/98 98.033 11:52:51 STRTE01 XE14 XE14Requested Access: SearchFunction: chdirUser Type: <strong>Security</strong> Defined Local UserPathname: /U/STRTE01Filename: /ROOTVolume : SMS001 Owner: rwx Group: --- Other: ---File Identifier: 000107000000000003Owning UID: 0 Owning GID: 0User Audit Options : Read Failure Write Failure Exec/Search FailureAuditor Audit Options: Read Failure Write Failure Exec/Search FailureDELETE_USP STRTE01 OMVSGRP 0 0 0 0 002/02/98 98.033 11:52:52 STRTE01 XE14 XE14This sample output shows one log entry <strong>for</strong> a INIT_USP request, one entry <strong>for</strong> aCHECK_ACCESS request, <strong>and</strong> one entry <strong>for</strong> a DELETE_USP request.In this example, the services of INIT_USP <strong>and</strong> DELETE_USP result in two-linelog entries consisting of field in<strong>for</strong>mation. The CHECK_ACCESS request resultsin log entries that consist of two lines plus additional lines of in<strong>for</strong>mation aboutthe request. This happens because different in<strong>for</strong>mation is logged <strong>for</strong> differenttypes of requests.Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–23
Tracing UNIX System Services (OMVS)Field definitions <strong>for</strong> these entries follow. Included are descriptions of the securityservices <strong>and</strong> fields that can appear on the TSSOERPT when DETAIL is specified.Output Report Field DescriptionsSERVICE—shows the types of service requested. The entries appearing in thisfield vary depending on whether Summary or Detail was specified in the inputparameters. All possible service requests <strong>and</strong> details are described on ServiceField Values.USERID—shows the acid of the user <strong>for</strong> which the request was made.GROUP—shows the GROUP with which the user is associated.UID—shows the UID number of the user.GID—shows the GID number of the user.SAF—shows the SAF return code. For all services:■■■0—Successful completion4—<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> not active8—Request denied.RC—The <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> return code. For all services:■■0—Successful completion8—Request denied.RSN—shows the SAF reason code. See explanation line.DATE—shows the Julian <strong>and</strong> Gregorian date when the access was attempted.TIME—shows the time of day when the access attempt occurred.JOBNAME—shows the name of the job under which the access was issued.SOURCE—shows the logical input source from which the request was issued.SYSID—shows the System CPU ID associated with the logging records.CPU—shows the SMF name of the CPU that validated the request.1–24 Cookbook
Tracing UNIX System Services (OMVS)Service Field valuesPossible values <strong>for</strong> the SERVICE field of the TSSOERPT report follows.Additional in<strong>for</strong>mation that can appear on the report <strong>for</strong> each request when theDETAIL option is specified is a function of the particular call being made is alsoprovided.AUDIT—A record cut in addition to a security service record; it suppliesadditional in<strong>for</strong>mation about the file being audited. For more in<strong>for</strong>mation, seethe <strong>Security</strong> Credentials <strong>and</strong> File <strong>Security</strong> Packets section of this document.CHANGE_AUDIT_OPT—Indicates that a file's Audit Options have beenchanged.■■User Audit Options—Indicates the type of user access to this file that shouldbe audited.Auditor Audit Options—Indicates the type of auditor access to this file thatshould be audited.CHANGE_FILE_MODE—Indicates a file's permissions (mode) have beenchanged.■■File Type—The file type of the file whose permissions are being changed. Itindicates if a file is a directory, a regular file, or one of several special types offiles.File Permissions—The file access permissions assigned to the indicated file.These are displayed in the fields named Owner, Group, <strong>and</strong> Other. Values<strong>for</strong> the fields are r <strong>for</strong> READ, w WRITE, x <strong>for</strong> EXECUTE, <strong>and</strong> s <strong>for</strong> SEARCH.CHANGE_OWNER_GRP—Changes a file's owning UID <strong>and</strong> GID to a newvalue.■■UID To Be Set— Changed UID number of the file's owning UID.GID To Be Set—Changed GID number of the file's owning GID.CHECK_ACCESS—Determines if a user has the requested access (READ,WRITE, EXECUTE or SEARCH) to the specified file or directory.CHECK_FILE_OWNER—Checks if a current process is a superuser or the ownerof the specified file. A process could be the owner of a file if the effective UID isequal to the file owner's UID.CHECK_PRIVILEGE—Determines if the calling process is a superuser.CHK_PROCESS_OWNR—Checks to see if the calling process is the owner of aprocess being called.CLEAR_SETID—Clears temporary access that has been given to a file ordirectory (i.e., resets the S_ISUID, S_ISGID <strong>and</strong> S_ISVTX bits in the file's ordirectory's access permissions back to zero.DELETE_USP—Indicates that the user's access to UNIX System Services MVSterminated.Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–25
Tracing UNIX System Services (OMVS)EXEC_SET—Changes the effective <strong>and</strong> saved UID or GID or both.■■Set UID—Change made to UID.Set GID—Change made to GID.FORK_EXIT—Indicates that a call was made to get the security in<strong>for</strong>mation <strong>for</strong> a<strong>for</strong>ked process.GET_GMAP—Indicates that a call was made to determine the GID <strong>for</strong> agroupname or the groupname <strong>for</strong> a GID.GET_SUPPL_GROUP—Indicates that a call was made to determine whatgroups the current process or user belongs to.GET_UMAP—Indicates that a call was made to determine the UID <strong>for</strong> ausername or the username <strong>for</strong> a UID.GET_USERS_GROUPS—Indicates that a call was made to determine the groupsto which a specific userid belongs.INIT_USP—Indicates initial user access to UNIX System Services MVS.■■Home—The home directory of the user at initial access to UNIX SystemServices MVS.Program—The name of the program <strong>for</strong> the indicated user at initial access toUNIX System Services MVS.MAKE_FSP—Seen when a file or directory is created.■■File Type—The filetype of the file <strong>for</strong> which the FSP is being created. It tellswhether a file is a directory, a regular file or one of several special types offiles.File Permissions—The file access permissions to be assigned to the indicatedfile. These are displayed in the fields named Owner, Group, <strong>and</strong> Other.Values <strong>for</strong> the fields are r <strong>for</strong> READ, w <strong>for</strong> WRITE, x <strong>for</strong> EXECUTE, <strong>and</strong> s <strong>for</strong>SEARCH.MAKE_ROOT_FSP—Indicates that a new file system is being initialized in anew PDSE/x data set.PTRACE_AUTH_CHK—Indicates that a check was made to see if a callingprocess can ptrace a target process it is calling.QUERY_FILE_OPTS—Indicates that file security options were queried todetermine the settings.QUERY_SEC_OPTION—Indicates that system security options were queried todetermine the settings.1–26 Cookbook
Tracing UNIX System Services (OMVS)SET_EFFECTIV_GID—Changes the effective GID to a different GID.■■■■GID To Be Set—The GID which 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 beingvalidated.Saved GID—Internally used GID.SET_EFFECTIV_UID—Changes the effective UID to a different UID.■■■■UID To Be Set—The UID which 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 beingvalidated.Saved UID—Internally used UID.SET_FILE_MASK—Change of permissions that a program sets in a new file ordirectory when it creates a new file or directory.SET_GID—Change the real, effective <strong>and</strong> saved GIDs to a different GID.■■■■GID To Be Set—The GID, which 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 beingvalidated.Saved GID—Internally used GID.SET_UID—Change the real, effective <strong>and</strong> saved UID to a different UID.■■■■UID To Be Set—The UID which 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 beingvalidated.Saved UID—Internally used UID.SUMMARY—Specifies the report is to include a three-line entry <strong>for</strong> each eventlogged. Produces a three-line entry <strong>for</strong> each logged event.DETAIL—Specifies the report is to include all the in<strong>for</strong>mation available <strong>for</strong> eachlogging event. Produces report entries that include all the in<strong>for</strong>mation available<strong>for</strong> each logging event. The default is a detailed report.TITLE—'TITLE <strong>for</strong> TSSOERPT' specifies a character string added to other titlein<strong>for</strong>mation at the top of the report.Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–27
Tracing UNIX System Services (OMVS)<strong>Security</strong> Credentials <strong>and</strong> File <strong>Security</strong> PacketsMany log entries show additional in<strong>for</strong>mation about the request. Thein<strong>for</strong>mation is contained internally as <strong>Security</strong> Credentials (CRED) <strong>and</strong> File<strong>Security</strong> Packets (FSP). This in<strong>for</strong>mation is common to many calls <strong>and</strong> can appearin the following fields on the TSSOERPT report if it is available:FUNCTION—The function attempted <strong>for</strong> a file or directory. (I.e., OPEN,SEARCH, etc.)PATHNAME—The full pathname of a file or directory, including the file ordirectory name itself. There could be two pathnames specified if the call involvedmore than one file or directory.FILENAME—The name of a file or directory. In the case of a CHECK_ACCESS,this field names the part of the path currently being validated <strong>for</strong> access (i.e., ifthe path is aa/bb/cc then three separate CHECK_ACCESS calls would be seen: thefirst with a filename of aa, the second with a filename of bb, <strong>and</strong> a third with thefilename of cc). There can also be two filenames specified if the call involvedmore than one file or directory.FILE PERMISSIONS—Access permissions <strong>for</strong> the file's owning UID (owner),the file's owning GID (group) <strong>and</strong> all others attempting access (other).OWNING UID—UID of the owner of the file or directory. If the real UID of auser/process attempting access to this file matches the owning UID, then accessis granted according to the owner file permissions.OWNING GID—GID of the owner of the file or directory. If the real GID of auser/process attempting access to this file matches the owning GID, then accessis granted according to the group file permissions. If the process/user does nothave the owning GID as its primary GID, but has a supplemental group thatmatches the owning GID, then access will also be determined by the group filepermissions.If neither the GID nor UID match the owner's GID or UID, then the other filepermissions 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 Filenameindicated in a call. In this case, using the File Identifier validates access. Todetermine what the Path <strong>and</strong> Filename are <strong>for</strong> this call, find the last previous callwith the same File Identifier. The Pathname <strong>and</strong> Filename <strong>for</strong> that call are thesame as <strong>for</strong> the call in question.1–28 Cookbook
Using TCP/IPFILE AUDIT OPTIONS—There are two types of file audit options:■■User—Indicates the type of file access that should be logged <strong>for</strong> a user. Forexample, if the report shows 'Read Failure, Write All, Exec/Search None,' itmeans that all failed READ attempts, all WRITEs, but no EXECs orSEARCHes are to be logged to SMF <strong>for</strong> the user.Auditor—Indicates the type of file access that should be logged <strong>for</strong> anauditor. For example, if the report shows 'Read Failure, Write All,Exec/Search None,' it means that all failed READ attempts, all WRITEs, butno EXECs or SEARCHes are to be logged to SMF <strong>for</strong> the auditor.Using TCP/IPTCP/IP (Transmission Control Protocol/Internet Protocol) is a file transferprotocol used to store <strong>and</strong> <strong>for</strong>ward jobs between nodes. TCP/IP is the protocolused on the Internet, which allows computers to talk to each other, <strong>and</strong> is wellestablished in the midrange <strong>and</strong> PC plat<strong>for</strong>ms.Prior to <strong>OS</strong>/390 V2R5, TCP/IP ran as a native MVS application, or as an UNIXSystem Services application. Starting with <strong>OS</strong>/390 V2R5, TCP/IP relies on UNIXSystem Services <strong>and</strong> must be configured as an UNIX System Services application.<strong>Security</strong> configuration depends on the environment in which it runs.Establishing <strong>Security</strong> <strong>for</strong> TCP/IP <strong>and</strong> OE/TCPIP (Communications Server IP <strong>for</strong> z/<strong>OS</strong><strong>and</strong> <strong>OS</strong>/390)To establish a proper security connection, you must follow these steps.Step 1—Define TCP/IP to <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>.To define TCP/IP to <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>, you must add a facility definition <strong>for</strong>TCP/IP to the Facility Matrix Table. Add the definition by renaming a USERxxentry as shown in the following.FAC(USER11=NAME=TCP)FAC(TCP=PGM=xxx)FAC(TCP=NOTSOC,RES,NOIJU,AUTHINIT)Depending on the release of TCP/IP being used, the program name (xxx) are asfollows:■■■TCP/IP 3.1 PGM=MVPTCP/IP 3.2 PGM=EZATCP/IP 3.4 PGM=EZBImplementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–29
Using TCP/IPSet all other FACILITY parameters according to your site-specific needs.Note: If the RES attribute is omitted from the FACILITY definition, no user orprofile data set rules are loaded into the TCP address space.Step 2—Create a Region acid.The comm<strong>and</strong> used to create this acid should look like the example shown in thefollowing.TSS CRE(TCP) NAME('TCPIP/FTP REGION ACID') FAC(BATCH,STC)PASS(password,0) DEPT(DEPT) MASTFAC(TCP)NOVOLCHK NODSNCHK NOLCFCHK NORESCHK N<strong>OS</strong>UBCHKTSS ADD(TCP) UID(0) GROUP(OMVSGRP)DFLTGRP(OMVSGRP) HOME(/)OMVSGPGM (/bin/sh)The Region acid must have:■■The NODSNCHK attribute or a permit <strong>for</strong> DSN(*****) ACC(ALL).The N<strong>OS</strong>UBCHK attribute. If this attribute is omitted, DRC157 errors onsubmit of batch jobs from the TCP address space will occur.To properly secure job submission, the JES facility must be in FAIL MODE.Step 3—Define the TCP procedure to the <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> STC Record.TSS ADD(STC) PROCNAME(TCPPROC) ACID(TCP)TCP/IP SERVAUTH ClassTCP/IP in <strong>OS</strong>/390 2.10 uses the SERVAUTH resource class to protect TCP/IPresources from unauthorized access. There are four functions protected by theSERVAUTH class. They are:Stack Access—Controls which users can get access to the TCP/IP stack.Resource name: EZB.STACKACCESS.sysname.tcpipidNet Access—Controls which users can access individual networks.Resource name: EZB.NETACCESS.sysname.tcpipid.netnamePort Access—Controls which users can use TCP <strong>and</strong> UDP ports.Resource name: EZB.PORTACCESS.sysname.tcpipid.portnameTN3270 controls which users can use the secured ports.Resource name: EZB.TN3270.sysname.tcpipid.PORTnnnn1–30 Cookbook
Using TCP/IPwheresysname is the name of the systemtcpipid is the name of the TCP/IP started tasknetname is the network name in PROFILE.TCPIPportname is the port name in PROFILE.TCPIPnnnn is the port number with leading zero'sSee the IBM <strong>OS</strong>/390 V2R10 IP Configuration Guide <strong>for</strong> additional in<strong>for</strong>mationabout these functions.Support <strong>for</strong> the SERVAUTH class is available beginning with <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong><strong>Secret</strong> 5.1 SP04. For earlier maintenance levels, you must apply APAR LO82040,which is required when using <strong>OS</strong>/390 2.10. This APAR adds an internal RDTentry <strong>for</strong> SERVAUTH. You must add rules giving READ access to theSERVAUTH resources to acids that require access. If no rule allowing accessexists, you can receive several different error messages, including:EDC5111I permission deniedThe EZB.STACKACCESS violation is seen on all systems running <strong>OS</strong>/390 2.10that do not have rules allowing access. Calls <strong>for</strong> the other three functions are notmade unless additional setup is done in PROFILE.TCPIP. See the IBM <strong>OS</strong>/390V2R10 IP Configuration Guide <strong>for</strong> additional in<strong>for</strong>mation.To allow access to these resources, issue the following comm<strong>and</strong>s to define theresource to <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>:TSS ADD(dept) SERVAUTH(EZB.)TSS PER(dept) SERVAUTH(EZB.STACKACCESS.) ACC(READ)TSS PER(dept) SERVAUTH(EZB.NETACCESS.) ACC(READ)TSS PER(dept) SERVAUTH(EZB.PORTACCESS.) ACC(READ)TSS PER(dept) SERVAUTH(EZB.TN3270.) ACC(READ)VMCF <strong>and</strong> TNF subsystems (<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> started be<strong>for</strong>e JES)If a restartable VMCF <strong>and</strong> TNF subsystems are to be used, add to the <strong>eTrust</strong><strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> STC table the following started task entries: VMCF, TNF,EZAZSSI.TSS ADD(STC) PROCNAME(VMCF) ACID(acid)TSS ADD(STC) PROCNAME(TNF) ACID(acid)The acids associated with these STCs require access to facility STC <strong>and</strong> data sethlq SEZATCP.TSS ADD(dept) DSNC(SEZATCP.)TSS PER(acid) DSN(SEZATCP.) ALL(READ)Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–31
Using FTPIP Address ProtectionSecuring an IP address using <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> (or any external securityproduct) requires that the TCP/IP product installed pass the IP address packet.Not all TCP/IP vendor products pass this in<strong>for</strong>mation. IBM’s TCP/IP productdoes pass the IP address.IP address protection is not available if your TCP/IP product does not pass theIP address packet.The IP packet passed is generated from the user's originating IP address. Thus,these IP packets often have no resemblance to st<strong>and</strong>ard LU names. Each node ofthe IP address is translated into a character representation of the hex value of thenode. For example, the IP address 141.202.201.56 would appear as terminal8D<strong>CA</strong>C938. The hex value of 141 is 8D, the hex value of 202 is <strong>CA</strong>, <strong>and</strong> so on.<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> allows you two mechanisms to implement security of an IPaddress. Dotted IP is converted to hex pairs. If you want to restrict a particularuser to enter the system only through a given IP address, you would use sourcerestriction. For example:TSS ADD(aicd) SOURCE(8D<strong>CA</strong>C938) equivalent to 141.202.201.56If you want to protect an IP address or range from use, you would useTERMINAL restriction. For example, to restrict use of all IP addresses starting141.202 <strong>for</strong> all users:TSS ADD(dept) TERMINAL(8D<strong>CA</strong>)To permit userid2 to use IP addresses starting 141.202:TSS PERMIT(userid2) TERMINAL(8D<strong>CA</strong>)To permit userid3 to use IP addresses starting 141.202.201:TSS PERMIT(userid3) TERMINAL(8D<strong>CA</strong>C9)Using FTPFTP is a feature of TCP/IP that allows users to transfer files to <strong>and</strong> from themainframe. In addition, remote users can submit jobs to MVS. Users are requiredto identify themselves when using FTP.FTP runs as an MVS or UNIX System Services application. <strong>Security</strong> configurationis similar <strong>for</strong> both.1–32 Cookbook
Using FTPHow to Secure FTPFTP runs as its own started task which needs to be associated with a Region acid,<strong>and</strong> the TCP/IP facility. The comm<strong>and</strong> used to create this acid should look likethe one shown in the following.TSS CRE(FTP) NAME('FTP SERVER ACID')FAC(BATCH,STC) PASS(password,0)DEPT(DEPT) MASTFAC(TCP)NOVOLCHK NODSNCHK NOLCFCHK NORESCHK N<strong>OS</strong>UBCHKNote: The use of the bypass attributes such as NODSNCHK <strong>and</strong> N<strong>OS</strong>UBCHK,are entered <strong>for</strong> simplicity. You can choose to omit them <strong>and</strong> explicitly permit theacid to all resources it will access.Define the FTP procedure to the <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> STC record with thefollowing comm<strong>and</strong>:TSS ADD(STC) PROCNAME(FTPSERVE) ACID(FTP)How to Secure FTP <strong>for</strong> UNIX System ServicesPackaged with TCP/IP OE Application Services, OE/FTP is an OMVSapplication that executes under UNIX System Services to facilitate the filetransfer of HFS files throughout a TCP/IP network.OE/FTP is different than the more common mainframe FTP product. OE/FTPtypically executes under a started-task named FTPD whereas FTP typicallyexecutes under a started-task named FTPSERVE.To complement OE/FTP, the above package includes an optional message-logdaemon (called Syslog-D) which can be used to log both past <strong>and</strong> presentmessage traffic related to OE/FTP. This optional logging task should beconsidered because, without it, there is no ongoing log of OE/FTP activity.The following steps replace the IBM requirements when installing OE/FTP with<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>.1. The O/E FTP started task (daemon) typically runs under a userid of FTPD.The exception occurs when the task is automatically started by OMVS, inwhich case it inherits the identity of the OMVS kernel, typically OMVS orOMVSKERN.If running as an FTPD, the following example shows the administrationneeded to properly define the acid.TSS CRE(FTPD) TYPE(USER) NAME('OE/FTP STC ID') DEPT(anydept)FAC(STC) PASSWORD(password,0) MASTFAC(TCP)TSS ADD(FTPD) UID(0) GROUP(OMVSGRP) DFLTGRP(OMVSGRP)TSS ADD(STC) PROCname(FTPD) ACID(FTPD)If running under the OMVS kernel ID, no additional setup is necessary.Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–33
Using FTP2. The FTP server acid requires the ability to per<strong>for</strong>m work on behalf of userslogging on to FTP, <strong>and</strong> at times switch its identity to that of a user.Accordingly, it requires superuser authority. This can be done as shownabove, by adding UID(0) to the acid. Alternatively, you can give the acid anon-zero UID <strong>and</strong> permit it access to Superuser authority as follows:TSS PERMIT(FTPD) IBMFAC(BPX.SUPERUSER) ACCESS(READ)IBM recommends that you increase your level of security by protectingdaemon authority. This is accomplished in <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> by owningthe resource IBMFAC(BPX.DAEM). Once this is done, you must explicitlypermit daemon authority to the server, even if it is running under UID(0), byentering the following comm<strong>and</strong>:TSS PERMIT(FTPD) IBMFAC(BPX.DAEMON) ACCESS(READ)3. The TSS Facility named "TCP" is used to control which end users are able toaccess OE/FTP. Access to the "TCP" Facility must be given to user acids thataccess OE/FTP.Considerations <strong>for</strong> Securing FTPUsers accessing FTP must log on to the service be<strong>for</strong>e using it. This requires themto supply their userids <strong>and</strong> passwords <strong>and</strong> <strong>for</strong> their userids to have access to theTCPIP facility. FTP also supports anonymous logons.In the FTPDATA configuration file, the parameter ANONYMOUS controlswhether this feature can be used. The parameter can be specified in one of threeways:ANONYMOUSANONYMOUS useridANONYMOUS userid/passwordIf the parameter is specified without a following userid, <strong>and</strong> an FTP userspecifies anonymous at logon time, RACINIT are issued <strong>for</strong> the acidANONYMOU. If this acid is defined to <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> <strong>and</strong> has access tothe TCP/IP facility, the user is allowed to log on <strong>and</strong> run under the authority ofthe "ANONYMOU" acid.If the parameter is specified with a following userid, the user must provide thecorrect password <strong>for</strong> this userid. If the parameter is specified with both USERID<strong>and</strong> PASSWORD, these values are used to sign on the user.The use of ANONYMOUS logon should be carefully considered, <strong>and</strong> if used, canbe a c<strong>and</strong>idate <strong>for</strong> auditing.1–34 Cookbook
Using TELNETTerminal Source RestrictionFTP logons specify a terminal ID when logging on a user. This terminal IDsupplied is generated from the user's originating IP address. Thus, these terminalIDs often have no resemblance to st<strong>and</strong>ard LU names. Each node of the IPaddress 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 8D<strong>CA</strong>C938.The hex value of 141 is 8D, the hex value of 202 is <strong>CA</strong>, etc. To administer sourceprotection in <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>, issue the following:TSS ADD(acid) SOURCE(8D<strong>CA</strong>C938)Using TELNETTELNET is a feature of TCP/IP, which allows users terminal access to a systemover a TCP/IP network. TELNET runs under both native MVS <strong>and</strong> UNIX SystemServices.If running under native MVS, users can be <strong>for</strong>ced to log on to TELNET itself.This will occur if the TELNET configuration statements, in the TCP/IP profiledata set, do not specify a DFLTAPPL. If configured this way, users logging on toTELNET will require the TCP/IP facility. Alternatively, DFLTAPPL can bespecified, which directs all logons to a session manager such as Unicenter ®<strong>CA</strong>-TPX. The session manager then controls access through its securityinterface.How to Secure TELNET <strong>for</strong> UNIX System ServicesWhen using TELNET under OMVS, RLOGIN runs under its own acid until theuser successfully signs on. The ID of this acid is specified in the configuration fileetc/inetd/conf. It is delivered specifying an ID of OMVSKERN <strong>and</strong> must bedefined with both superuser <strong>and</strong> daemon authority.The following comm<strong>and</strong>s would define such an acid.TSS CRE(OMVSKERN) TYPE(USER)NAME('OMVS ACID') PASS(password,0)DEPT(dept)TSS ADD(OMVSKERN) UID(0) GROUP(OMVSGRP)DFLTGRP(OMVSGRP) HOME(/)OMVSPGM(/bin/sh)If you are using OMVSKERN, it is likely that this ID was defined as part of yourOMVS installation.Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–35
InfoPrint Server <strong>for</strong> z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 (z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 Print Server)In addition, if you are securing daemon authority, the TELNET server ID musthave the following permission:TSS PER(OMVSKERN) IBMFAC(BPX.DAEMON)InfoPrint Server <strong>for</strong> z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 (z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 PrintServer)The z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 Print Server available with <strong>OS</strong>/390 V2R5 allowed <strong>for</strong>consolidation of print files from multiple servers into one central server. At<strong>OS</strong>/390 V2R8, the Print Server was renamed to InfoPrint Server <strong>for</strong> z/<strong>OS</strong> <strong>and</strong><strong>OS</strong>/390. Control of the resources defined under the Print Server requires thedefinition of two groups: AOPOPER <strong>and</strong> AOPADMIN. These are IBM defaults.AOPOPER is the operator group with authority to start <strong>and</strong> stop the printinterface. AOPADMIN provides authority to administer the printer inventory<strong>and</strong> controls. If the separation of authority is not necessary, then one group namecan be defined <strong>for</strong> both functions.Use the following steps to define the security environment <strong>for</strong> <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong><strong>Secret</strong>:TSS CRE(AOPADMIN) TYPE(GROUP) NAME('PRINT SERVER') DEPT(dept)TSS ADD(AOPADMIN) GID(6)TSS ADD(admin acid) GROUP(AOPADMIN)TSS CRE(AOPER) TYPE(GROUP) NAME('PRINT SERVER') DEPT(dept)TSS ADD(AOPER) GID(7)TSS ADD(acid) GROUP(AOPER)TSS ADD(JDCSYS) IBMFAC(AOPADMIN)TSS PERMIT(dept acid) IBMFAC(AOPADMIN) ACCESS(ALL)WebSphere Application Server <strong>for</strong> z/<strong>OS</strong> AND <strong>OS</strong>/390WebSphere <strong>for</strong> z/<strong>OS</strong> supports access to resources by clients <strong>and</strong> servers in adistributed network. Part of your security strategy should be to determine howto control access to these resources <strong>and</strong> prevent inadvertent or maliciousdestruction of the system or data.1–36 Cookbook
WebSphere Application Server <strong>for</strong> z/<strong>OS</strong> AND <strong>OS</strong>/390These are the pieces in the distributed network that you must consider:■■■■You must authorize servers to the base operating system services in z/<strong>OS</strong> or<strong>OS</strong>/390. These services include <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> security, databasemanagement, <strong>and</strong> transaction management.For the servers, you must distinguish between control regions <strong>and</strong> serverregions. Control regions run authorized system code, so they are trusted.Server regions run application code <strong>and</strong> are given access to resources, so youshould carefully consider the authorizations you give server regions.You must also distinguish between the level of authority given to run-timeservers compared to your own application servers. For example, the SystemManagement server needs the authority to start other servers, while yourown application servers do not need this authority.You must authorize clients (users) to servers <strong>and</strong> objects within servers. Thecharacteristics of each client requires special consideration:- Is the client on the local system or is it remote? The security of thenetwork becomes a consideration <strong>for</strong> remote clients.- Will you allow unidentified (unauthenticated) clients to access thesystem? Some resources on your system can be intended <strong>for</strong> publicaccess, while others must be protected. In order to access protectedresources, clients must establish their identities <strong>and</strong> have authorizationto use those resources.- What kind of objects will the client access? Enterprise beans <strong>and</strong> CORBAobjects 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 asauthentication. In a distributed network supported by WebSphere <strong>for</strong> z/<strong>OS</strong>,clients can be accessing resources from:■■■■Within the same system as a serverWithin the same sysplex as the serverRemote z/<strong>OS</strong> or <strong>OS</strong>/390 systemsHeterogeneous systems, such as WebSphere on distributed plat<strong>for</strong>ms, CICS,or other CORBA-compliant systems.Additionally, clients can request a service that requires a server to <strong>for</strong>ward therequest to another server. In such cases the system must h<strong>and</strong>le delegation, theavailability of the client identity <strong>for</strong> use by intermediate servers <strong>and</strong> targetservers.Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–37
WebSphere Application Server <strong>for</strong> z/<strong>OS</strong> AND <strong>OS</strong>/390Finally, in a distributed network, how do you ensure that messages being passedare confidential <strong>and</strong> have not been tampered? How do you ensure that clients arewho they claim to be? How do you map network identities to z/<strong>OS</strong> or <strong>OS</strong>/390identities? These issues are addressed by the following support in WebSphere <strong>for</strong>z/<strong>OS</strong>:■■■The use of SSL <strong>and</strong> digital certificatesKerberosDistributed Computing Environment (DCE)Network security is not required <strong>for</strong> your initial installation <strong>and</strong> customization ofWebSphere <strong>for</strong> z/<strong>OS</strong>. This in<strong>for</strong>mation is provided to introduce you toWebSphere <strong>for</strong> z/<strong>OS</strong> security <strong>and</strong> allow you to make early planning decisionsabout system security. The following topics describe how WebSphere <strong>for</strong> z/<strong>OS</strong>supports security. The descriptions are organized under the following subtopics:■■Authorization CheckingUser Identification, Authentication <strong>and</strong> Network <strong>Security</strong>Authorization CheckingEach control region, server region, <strong>and</strong> client must have its own MVS user ID(more about user identification <strong>and</strong> authentication later). When a request flowsfrom a client to the server or from a server to a server, WebSphere <strong>for</strong> z/<strong>OS</strong>passes the user identity (client or server) with the request. Thus each request isper<strong>for</strong>med on behalf of the user identity <strong>and</strong> the system checks to see if the useridentity has the authority to make such a request.ControlAccess control lists in LDAPCBIND classDATASET classDCEUUIDS <strong>and</strong> IBMFACclassesDSNR classEJBROLE classIBMFA<strong>CA</strong>uthorizationControlled access to WebSphere <strong>for</strong> z/<strong>OS</strong>naming <strong>and</strong> interface repository dataAccess to a serverAccess to data setsMapping DCE credentials to <strong>Top</strong> <strong>Secret</strong> userIdsAccess to DB2Access to methods in enterprise beansSSL key rings, certificates <strong>and</strong> mappings(IRR.DIGTCERT.GENCERT) &(IRR.DIGTCERT.LIST) &(IRR.DIGTCERT.LISTRING)1–38 Cookbook
WebSphere Application Server <strong>for</strong> z/<strong>OS</strong> AND <strong>OS</strong>/390ControlIBMFAC class(IMSXCF.OTMACI)IBMFAC Class(IRR.RUSERMAP)File permissionsGRANTs (DB2)LOGSTRM classOPERCMDS classPTKTDATA classSERVER classSOMDOBJS classSTCSURROGAT class (*.DFHEXCI)AuthorizationAccess to OTMA <strong>for</strong> IMS accessKerberos credentialsAccess to HFS filesDB2 access to plans <strong>and</strong> databaseAccess to log streamsStart <strong>and</strong> stop servers by DaemonPassticket enabling in the Sysplex (Thisrelates to the session keys in the NDT in <strong>Top</strong><strong>Secret</strong>)Access to control region by a server regionAccess to methods in CORBA objectsAssociate procname <strong>and</strong> userid in the STCtableAccess to EXCI <strong>for</strong> CICS accessServer Authorization CheckingTo control access to WebSphere <strong>for</strong> z/<strong>OS</strong> resources, give greater authority tocontrol regions <strong>and</strong> less authority to server regions.Level of Trust <strong>and</strong> Authority <strong>for</strong> RegionsRegionControl regionServer regionLevel of trust <strong>and</strong> access authorityContains WebSphere <strong>for</strong> z/<strong>OS</strong> system code.Trusted, deals with multiple users. Greaterauthorization. Runs APF-authorized.Contains application code. Untrusted. Otherthan having authorization to get work <strong>and</strong> toattach to data stores, should rununauthorized.Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–39
WebSphere Application Server <strong>for</strong> z/<strong>OS</strong> AND <strong>OS</strong>/390Regarding the WebSphere <strong>for</strong> z/<strong>OS</strong> run-time servers, the rule of thumb is to giveless authority to the Daemon <strong>and</strong> Naming Server, <strong>and</strong> greater authority to theSystem Management Server, as explained in the following table:Run-time Server Region Required AuthoritiesDaemon Server Control STC Control, access WLM services,access to DNS, OPERCMDS access toSTART, STOP, <strong>CA</strong>NCEL, FORCE &MODIFY other servicesNaming Server Control STC Control STARTED class, access toWLM servicesNaming Server Server STC control, READ auth to the SERVERclass, DBADM <strong>for</strong> the LDAP DatabaseSys. MGMT. Server Control STC ControlSys. Mgmt. Server Server Started class, Read auth. to the SERVERclass, OPERCMDS access to START,STOP, <strong>CA</strong>NCEL FORCE <strong>and</strong> MODIFYOther servicesInterface RepositoryServerInterface RepositoryServerControlServerSTARTED classSTC Control, READ Auth. to theSERVER Class, DBADM <strong>for</strong> the LDAPdatabaseAssigning authorities to WebSphere <strong>for</strong> z/<strong>OS</strong> run-time server control <strong>and</strong> serverregions:■■Remember to protect the RRS log streams.Protect the WebSphere <strong>for</strong> z/<strong>OS</strong> environment files, especially if they containpasswords.User Identification, Authentication <strong>and</strong> Network <strong>Security</strong>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 theLDAP name space, allowing any client to access naming services.1–40 Cookbook
WebSphere Application Server <strong>for</strong> z/<strong>OS</strong> AND <strong>OS</strong>/390You can use the CBIND class to restrict a client’s ability to access servers. Thereare two types of resources, WebSphere <strong>for</strong> z/<strong>OS</strong> uses in the CBIND class:■One that controls whether a local or remote client can access servers.The name of the resource has this <strong>for</strong>m:CB.BIND.server_namewhere server_name is the name of the server.■One that controls whether a client can use objects in a server. The name ofthe resource has this <strong>for</strong>m:CB.server_namewhere server_name is the name of the server.Note: When you add a new server, you must authorize all systemsmanagement user IDs (<strong>for</strong> example, CBADMIN) to have read access to theCB.server_name <strong>and</strong> CB.BIND.server_name resources.Example:CBADMIN needs read authority to the CB.BBOASR1 <strong>and</strong>CB.BIND.BBOASR1 servers:TSS ADD(deptacid) CBIND(CB.)TSS PERMIT(CBADMIN) CBIND(CB.BBOASR1) ACCESS(READ)TSS PERMIT(CBADMIN) CBIND(CB.BIND.BBOASR1) ACCESS(READ)Use the EJBROLE (or GEJBROLE) class in <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> to control aclient’s access to enterprise beans. There are two distinct sets of tasks that arerequired to protect an application using EJB roles.■The security administrator must define the roles <strong>and</strong> set up access rights in<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>.– Define a profile name using the EJBROLE (or GEJBROLE) class.Example:TSS ADD(dept) EJBROLE(ROLE_NAME)Where department is a department already defined in the <strong>Top</strong> <strong>Secret</strong>database <strong>and</strong> role_name matches the security role attribute specified inthe jar file or <strong>for</strong> the application. A role name cannot contain blanks, <strong>and</strong>cannot exceed 245 characters. Role names, however, can be in mixedcase.Create membership in the role by permitting <strong>Top</strong> <strong>Secret</strong> userID’s orprofiles permission to the defined EJBROLE resource.Example:TSS PERMIT(acid) EJBROLE(role_name)Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–41
WebSphere Application Server <strong>for</strong> z/<strong>OS</strong> AND <strong>OS</strong>/390■The application assembler must assign method permissions to the bean ormethod using the Application Assembly Tool.– Define the roles relevant to the application. These role names mustmatch the resource names defined to <strong>Top</strong> <strong>Secret</strong>.– Once defined, the role can be assigned to access an application (as amethod permission).– After the application assembly is complete, the application must bereinstalled using the Administration application.Use the SOMDOBJS class in <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> to control a client’s accessto CORBA objects. Resource names in SOMDOBJS have the <strong>for</strong>m:■server_name.home.methodWhere server_name is the server name. It must be 8 characters or less. homeis the home name. It must be 192 characters or less. method is the methodname. It can be up to the length of the remainder of 244 minus the sum of theserver <strong>and</strong> home name lengths.Example:If the server name is 8 characters, <strong>and</strong> the home name is:128 characters, the method name can be 108 (244 - (8 + 128)). If a method isprotected by SOMDOBJS <strong>and</strong>:– A client program is using the method to update an attribute of an object,give the client UPDATE authorization <strong>for</strong> the method.– A client program is using the method to read an attribute of an object,give the client READ authorization <strong>for</strong> the method.All names are folded into uppercase characters, regardless of how youenter them. Thus, there is no difference betweenMY_server.MY_home.MY_method <strong>and</strong>MY_SERVER.MY_HOME.MY_METHOD.In addition to the SOMDOBJS definitions, you must specifymethod-level access checking through the WebSphere <strong>for</strong> z/<strong>OS</strong>Administration application. Check the box <strong>for</strong> method-level accesschecking when you define your application’s container.Resource managers such as DB2, IMS, <strong>and</strong> CICS have implemented theirown resource controls, which control the ability of clients to access resources.When resource controls are used by DB2, use the DSNR <strong>Top</strong> <strong>Secret</strong> class orissue the relevant DB2 GRANT statements.Access to OTMA <strong>for</strong> IMS access is through the IBMFAC Class(IMSXCF.OTMACI). Access to EXCI <strong>for</strong> CICS is through the SURROGATclass (*.DFHEXCI). You can control access to data sets through the DATASETclass <strong>and</strong> HFS files through file permissions or the HFSSEC class.1–42 Cookbook
WebSphere Application Server <strong>for</strong> z/<strong>OS</strong> AND <strong>OS</strong>/390Identification <strong>and</strong> AuthenticationFor identification, each control region <strong>and</strong> server region start procedure musthave its own user ID <strong>and</strong> you must define it in the STC record. Control regionsare trusted, while server regions are not. Because you should give differingresource authorizations to each, you should give different user IDs to controlregions <strong>and</strong> server regions.Additional user IDs are required <strong>for</strong> installation. We provide the definitions <strong>for</strong>these user IDs in our <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> sample. See the customizedinstructions produced when you run the customization dialog.■■■■User IDs <strong>for</strong> control regions <strong>and</strong> server regions.A user ID <strong>for</strong> the installation verification program <strong>and</strong> its application server.Our <strong>Top</strong> <strong>Secret</strong> sample uses CBIVP.A user ID called CBADMIN used by the Administration application.A default local <strong>and</strong> remote user ID associated with each server through theAdministration application. We use CBGUEST.Necessary user IDs <strong>and</strong> <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> definitions <strong>for</strong> the WebSphere <strong>for</strong>z/<strong>OS</strong> run time are provided by our <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> sample.Regarding authentication, an operator starts a server by using the STARTcomm<strong>and</strong> <strong>and</strong> the control region start procedure. Authentication of the startprocedure’s user ID is made by virtue of the fact that an operator started the startprocedure—that is, no password is required. If you want to restrict an operator’sability to start servers, do so through the STC record in <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>.WASADMThe following is a copy of the <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> supplied CLIST, WASADM.This CLIST will run <strong>and</strong> execute the <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> comm<strong>and</strong>s requiredto create the environment <strong>for</strong> the Websphere implementation. It can be found inthe SAMPJCL file on the <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> installation tape.PROC 0/* =============================================================== *//* CREATING GROUPS AND PROFILES FOR WAS BASE SERVERS. *//* =============================================================== */TSS CREATE(WASDEPT) TYPE(DEPT) NAME('WAS DEPARTMENT')TSS CREATE(CBCTL1) TYPE(GROUP) NAME('WAS BASESERVER GRP') DEPT(WASDEPT)TSS ADDTO(CBCTL1) GID(2211)TSS CREATE(CBCTL1P) TYPE(PROF) NAME('WAS BASESERVER GRP') DEPT(WASDEPT)TSS CREATE(CBSR1) TYPE(GROUP) NAME('WAS BASESERVER GRP') DEPT(WASDEPT)TSS ADDTO(CBSR1) GID(2201)TSS CREATE(CBSR1P) TYPE(PROF) NAME('WAS BASESERVER GRP') DEPT(WASDEPT)/* =============================================================== *//* CREATE WAS CONFIGURATION GROUP. *//* =============================================================== */TSS CREATE(CBCFG1) TYPE(GROUP) NAME('WAS CONFIG GRP') DEPT(WASDEPT)TSS ADDTO(CBCFG1) GID(2300)Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–43
WebSphere Application Server <strong>for</strong> z/<strong>OS</strong> AND <strong>OS</strong>/390/* =============================================================== *//* CREATING GROUP FOR WAS ADMINISTRATORS. *//* =============================================================== */TSS CREATE(CBADMGP) TYPE(GROUP) NAME('WAS ADMIN GRP') DEPT(WASDEPT)TSS ADDTO(CBADMGP) GID(2203)/* =============================================================== *//* CREATING GROUP FOR DEFAULT WAS USERID. *//* =============================================================== */TSS CREATE(CBCLGP) TYPE(GROUP) NAME('DFLT WAS USER GRP') DEPT(WASDEPT)TSS ADDTO(CBCLGP) GID(2202)/* =============================================================== *//* CREATING SERVER REGION GROUP AND PROFILE FOR IVP1 SERVER. *//* =============================================================== */TSS CREATE(CBASR1) TYPE(GROUP) NAME('SERVR REG GRP IVP1') DEPT(WASDEPT)TSS ADDTO(CBASR1) GID(2205)TSS CREATE(CBASR1P) TYPE(PROF) NAME('SERVR REG GRP IVP1') DEPT(WASDEPT)/* =============================================================== *//* CREATING GROUP FOR IVP1 USERIDS. *//* =============================================================== */TSS CREATE(CBIVPGP) TYPE(GROUP) NAME('IVP1 USER GRP') DEPT(WASDEPT)TSS ADDTO(CBIVPGP) GID(2209)/* =============================================================== *//* CREATING SERVER REGION GROUP AND PROFILE FOR IVP2 SERVER. *//* =============================================================== */TSS CREATE(CBASR2) TYPE(GROUP) NAME('SERVR REG GRP IVP2') DEPT(WASDEPT)TSS ADDTO(CBASR2) GID(2216)TSS CREATE(CBASR2P) TYPE(PROF) NAME('SERVR REG GRP IVP2') DEPT(WASDEPT)/* =============================================================== *//* CREATING GROUP FOR IVP2 USERIDS. *//* =============================================================== */TSS CREATE(CBIVPGP2) TYPE(GROUP) NAME('IVP2 USER GRP') DEPT(WASDEPT)TSS ADDTO(CBIVPGP2) GID(2217)/* =============================================================== *//* ADDING USERS FOR WAS CONTROL REGIONS. *//* =============================================================== */TSS CREATE(CBDMNCR1) DFLTGRP(CBCTL1) HOME(/tmp) -OMVSPGM(/bin/sh) NAME('CB390 DAEMON CR') DEPT(WASDEPT) PASS(NOPW,0)TSS ADDTO(CBDMNCR1) UID(2111)TSS ADDTO(CBDMNCR1) FAC(STC)TSS CREATE(CBNAMCR1) DFLTGRP(CBCTL1) HOME(/tmp) -OMVSPGM(/bin/sh) NAME('CB390 NAMING CR') DEPT(WASDEPT) PASS(NOPW,0)TSS ADDTO(CBNAMCR1) UID(2113)TSS ADDTO(CBNAMCR1) FAC(STC)TSS CREATE(CBSYMCR1) DFLTGRP(CBCTL1) HOME(/tmp) -OMVSPGM(/bin/sh) NAME('CB390 SYSMGT CR') DEPT(WASDEPT) PASS(NOPW,0)TSS ADDTO(CBSYMCR1) UID(2112)TSS ADDTO(CBSYMCR1) FAC(STC)TSS CREATE(CBINTCR1) DFLTGRP(CBCTL1) HOME(/tmp) -OMVSPGM(/bin/sh) NAME('CB390 INTFRP CR') DEPT(WASDEPT) PASS(NOPW,0)TSS ADDTO(CBINTCR1) UID(2114)TSS ADDTO(CBDMNCR1) FAC(STC)/* =============================================================== *//* ADDING USERS FOR WAS SERVER REGIONS. *//* =============================================================== */TSS CREATE(CBNAMSR1) DFLTGRP(CBSR1) HOME(/tmp) -OMVSPGM(/bin/sh) NAME('CB390 NAMING SR') DEPT(WASDEPT) PASS(NOPW,0)TSS ADDTO(CBNAMSR1) UID(2105)TSS ADDTO(CBNAMSR1) FAC(STC)TSS CREATE(CBSYMSR1) DFLTGRP(CBSR1) HOME(/tmp) -OMVSPGM(/bin/sh) NAME('CB390 SYSMGT SR') DEPT(WASDEPT) PASS(NOPW,0)TSS ADDTO(CBSYMSR1) UID(2104)TSS ADDTO(CBSYMSR1) FAC(STC)TSS CREATE(CBINTSR1) DFLTGRP(CBSR1) HOME(/tmp) -OMVSPGM(/bin/sh) NAME('CB390 INTFRP SR') DEPT(WASDEPT) PASS(NOPW,0)TSS ADDTO(CBINTSR1) UID(2106)TSS ADDTO(CBINTSR1) FAC(STC)1–44 Cookbook
WebSphere Application Server <strong>for</strong> z/<strong>OS</strong> AND <strong>OS</strong>/390/* =============================================================== *//* ADDING USERS FOR IVP CONTROL AND SERVER REGIONS *//* =============================================================== */TSS CREATE(CBACRU1) DFLTGRP(CBCTL1) HOME(/tmp) -OMVSPGM(/bin/sh) NAME('CB390 IVP1 CR') DEPT(WASDEPT) PASS(NOPW,0)TSS ADDTO(CBACRU1) UID(2107)TSS ADDTO(CBACRU1) FAC(STC)TSS CREATE(CBASRU1) DFLTGRP(CBASR1) HOME(/tmp) -OMVSPGM(/bin/sh) NAME('CB390 IVP1 SR') DEPT(WASDEPT) PASS(NOPW,0)TSS ADDTO(CBASRU1) UID(2110)TSS ADDTO(CBASRU1) FAC(STC)/* =============================================================== */TSS CREATE(STCRACF) DFLTGRP(SYS1) NAME('CB390 TRACE WRITER') -TYPE(USER) DEPT(WASDEPT) PASS(NOPW,0)TSS ADDTO(STCRACF) FAC(STC)/* =============================================================== */TSS CREATE(CBACRU2) DFLTGRP(CBCTL1) HOME(/tmp) -OMVSPGM(/bin/sh) NAME('CB390 IVP2 CR') DEPT(WASDEPT) PASS(NOPW,0)TSS ADDTO(CBACRU2) UID(2115)TSS ADDTO(CBACRU2) FAC(STC)TSS CREATE(CBASRU2) DFLTGRP(CBASR2) HOME(/tmp) -OMVSPGM(/bin/sh) NAME('CB390 IVP2 SR') DEPT(WASDEPT) PASS(NOPW,0)TSS ADDTO(CBASRU2) UID(2116)TSS ADDTO(CBASRU2) FAC(STC)/* =============================================================== *//* ADDING WAS ADMIN USERID. *//* =============================================================== */TSS CREATE(CBADMIN) DFLTGRP(CBADMGP) HOME(/tmp) -OMVSPGM(/bin/sh) NAME('CB390 ADMINISTRATOR') DEPT(WASDEPT) PASS(NOPW,0)TSS ADDTO(CBADMIN) UID(2103)TSS ADDTO(CBADMIN) FAC(STC,BATCH)/* =============================================================== *//* ADDING USERS TO RUN IVP1. *//* =============================================================== */TSS CREATE(CBIVP) DFLTGRP(CBIVPGP) TYPE(USER) HOME(/tmp) -OMVSPGM(/bin/sh) NAME('CB390 IVP1 USER') DEPT(WASDEPT) PASS(NOPW,0)TSS ADDTO(CBIVP) UID(2109)TSS ADDTO(CBIVP) FAC(STC,BATCH)/* =============================================================== *//* ADDING USERS TO RUN IVP2. *//* =============================================================== */TSS CREATE(CBIVP2) DFLTGRP(CBIVPGP2) TYPE(USER) HOME(/tmp) -OMVSPGM(/bin/sh) NAME('CB390 IVP2 USER') DEPT(WASDEPT) PASS(NOPW,0)TSS ADDTO(CBIVP2) UID(2117)TSS ADDTO(CBIVP2) FAC(STC,BATCH)/* =============================================================== *//* ADDING DEFAULT CB390 USERID FOR BASE SERVERS. *//* =============================================================== */TSS CREATE(CBGUEST) DFLTGRP(CBCLGP) TYPE(USER) HOME(/tmp) -OMVSPGM(/bin/sh) NAME('CB390 DEFAULT USER') DEPT(WASDEPT) PASS(NOPW,0)TSS ADDTO(CBGUEST) UID(2102)TSS ADDTO(CBGUEST) FAC(STC,BATCH)/* =============================================================== *//* CONNECTING CB ADMINISTRATOR TO THE CB CONFIGURATION GROUP. *//* =============================================================== */TSS ADDTO(CBADMIN) GROUP(CBCFG1)/* =============================================================== *//* CONNECTING USERS TO THE CB CONFIGURATION GROUP. *//* =============================================================== */TSS ADDTO(CBDMNCR1) GROUP(CBCFG1)TSS ADDTO(CBNAMCR1) GROUP(CBCFG1)TSS ADDTO(CBSYMCR1) GROUP(CBCFG1)TSS ADDTO(CBINTCR1) GROUP(CBCFG1)TSS ADDTO(CBNAMSR1) GROUP(CBCFG1)TSS ADDTO(CBSYMSR1) GROUP(CBCFG1)TSS ADDTO(CBINTSR1) GROUP(CBCFG1)Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–45
WebSphere Application Server <strong>for</strong> z/<strong>OS</strong> AND <strong>OS</strong>/390/* =============================================================== *//* CONNECTING IVP CR AND SR USERIDS TO THE CB CONFIGURATION GROUP. *//* =============================================================== */TSS ADDTO(CBACRU1) GROUP(CBCFG1)TSS ADDTO(CBASRU1) GROUP(CBCFG1)TSS ADDTO(CBACRU2) GROUP(CBCFG1)TSS ADDTO(CBASRU2) GROUP(CBCFG1)/* =============================================================== *//* CONNECTING STC ACIDS TO THE CB PROFILES *//* =============================================================== */TSS ADDTO(CBDMNCR1) PROF(CBCTL1P)TSS ADDTO(CBNAMCR1) PROF(CBCTL1P)TSS ADDTO(CBNAMSR1) PROF(CBSR1P)TSS ADDTO(CBSYMCR1) PROF(CBCTL1P)TSS ADDTO(CBSYMSR1) PROF(CBSR1P)TSS ADDTO(CBINTCR1) PROF(CBCTL1P)TSS ADDTO(CBINTSR1) PROF(CBSR1P)TSS ADDTO(CBACRU1) PROF(CBCTL1P)TSS ADDTO(CBASRU1) PROF(CBASR1P)TSS ADDTO(CBACRU2) PROF(CBCTL1P)TSS ADDTO(CBASRU2) PROF(CBASR2P)/* =============================================================== */TSS ADDTO(WASDEPT) LOGSTRM(DEFAULT_LOGSTREAM_NAME)TSS PERMIT(ALL) LOGSTRM(DEFAULT_LOGSTREAM_NAME) ACCESS(READ)TSS PERMIT(CBCTL1P) LOGSTRM(DEFAULT_LOGSTREAM_NAME) ACCESS(UPDATE)TSS PERMIT(CBSR1P) LOGSTRM(DEFAULT_LOGSTREAM_NAME) ACCESS(UPDATE)TSS PERMIT(CBASR1P) LOGSTRM(DEFAULT_LOGSTREAM_NAME) ACCESS(UPDATE)TSS PERMIT(CBASR2P) LOGSTRM(DEFAULT_LOGSTREAM_NAME) ACCESS(UPDATE)/* =============================================================== *//* DEFINE CBIND(CB.) *//* =============================================================== */TSS ADDTO(WASDEPT) CBIND(CB.)/* =============================================================== *//* DEFINING CBIND CB.BIND.GENERIC_SERVER. *//* =============================================================== */TSS PERMIT(CBCTL1P) CBIND(CB.BIND.CBDAEMON) ACCESS(CONTROL)TSS PERMIT(CBCTL1P) CBIND(CB.BIND.CBNAMING) ACCESS(CONTROL)TSS PERMIT(CBCTL1P) CBIND(CB.BIND.CBSYSMGT) ACCESS(CONTROL)TSS PERMIT(CBCTL1P) CBIND(CB.BIND.CBINTFRP) ACCESS(CONTROL)TSS PERMIT(CBCTL1P) CBIND(CB.BIND.BBOASR1) ACCESS(CONTROL)TSS PERMIT(CBCTL1P) CBIND(CB.BIND.BBOASR2) ACCESS(CONTROL)/* =============================================================== *//* DEFINING CBIND CB.GENERIC_SERVER. *//* =============================================================== */TSS PERMIT(ALL) CBIND(CB.) ACCESS(NONE)/* =============================================================== *//* DEFINING CBIND CB.GENERIC_SERVER ACCESS FOR CB SYSTEMS SERVERS *//* =============================================================== */TSS PERMIT(ALL) CBIND(CB.CBDAEMON) ACCESS(READ)TSS PERMIT(ALL) CBIND(CB.CBNAMING) ACCESS(READ)TSS PERMIT(ALL) CBIND(CB.CBSYSMGT) ACCESS(READ)TSS PERMIT(ALL) CBIND(CB.CBINTFRP) ACCESS(READ)/* =============================================================== *//* DEFINING CBIND CB.GENERIC_SERVER FOR IVP1 SERVERS AS UACC(READ) *//* =============================================================== */TSS PERMIT(ALL) CBIND(CB.BBOASR1) ACCESS(READ)/* =============================================================== *//* DEFINING CBIND CB.GENERIC_SERVER FOR IVP2 SERVERS AS UACC(READ) *//* =============================================================== */TSS PERMIT(ALL) CBIND(CB.BBOASR2) ACCESS(READ)/* =============================================================== *//* DEFINING SERVER CB.SERVER_INSTANCE.GENERIC_SERVER. *//* =============================================================== */TSS ADDTO(WASDEPT) SERVER(CB.)TSS PERMIT(ALL) SERVER(CB.) ACCESS(NONE)/* =============================================================== */1–46 Cookbook
Lotus Domino Go Webserver/* PERMITTING SERVER CLASS ACCESS. *//* =============================================================== */TSS PERMIT(CBNAMSR1) SERVER(CB.*.CBNAMING) ACCESS(READ)TSS PERMIT(CBSYMSR1) SERVER(CB.*.CBSYSMGT) ACCESS(READ)TSS PERMIT(CBINTSR1) SERVER(CB.*.CBINTFRP) ACCESS(READ)TSS PERMIT(CBASRU1) SERVER(CB.*.BBOASR1) ACCESS(READ)TSS PERMIT(CBASRU2) SERVER(CB.*.BBOASR2) ACCESS(READ)/* =============================================================== *//* ASSIGNING USERIDS TO STARTED TASKS. *//* =============================================================== */TSS ADDTO(STC) PROCNAME(BBODMN) ACID(CBDMNCR1)TSS ADDTO(STC) PROCNAME(BBONM) ACID(CBNAMCR1)TSS ADDTO(STC) PROCNAME(BBONMS) ACID(CBNAMSR1)TSS ADDTO(STC) PROCNAME(BB<strong>OS</strong>MS) ACID(CBSYMCR1)TSS ADDTO(STC) PROCNAME(BB<strong>OS</strong>MSS) ACID(CBSYMSR1)TSS ADDTO(STC) PROCNAME(BBOIR) ACID(CBINTCR1)TSS ADDTO(STC) PROCNAME(BBOIRS) ACID(CBINTSR1)TSS ADDTO(STC) PROCNAME(BBOWTR) ACID(STCRACF)TSS ADDTO(STC) PROCNAME(BBOASR1) ACID(CBACRU1)TSS ADDTO(STC) PROCNAME(BBOASR1S) ACID(CBASRU1)TSS ADDTO(STC) PROCNAME(BBOASR2) ACID(CBACRU2)TSS ADDTO(STC) PROCNAME(BBOASR2S) ACID(CBASRU2)/* =============================================================== *//* SETTING UP THE PASSTICKET. *//* =============================================================== */TSS ADDTO(NDT) PSTKAPPL(CBS390) SESSKEY(0123456789ABCDEF)/* =============================================================== */EXIT<strong>Security</strong> Auditing<strong>Security</strong> auditing is h<strong>and</strong>led in the usual way by the security product.WebSphere <strong>for</strong> z/<strong>OS</strong> uses the System Authorization Facility (SAF), whichprovides an auditing mechanism consistent with other functions in z/<strong>OS</strong> or<strong>OS</strong>/390.Lotus Domino Go WebserverThe Lotus Domino Go Webserver is an IBM offering that allows the MVSmainframe to act as an Internet web server. This offering is installed <strong>and</strong>managed as an UNIX System Services application. By default, the Domino GoWebserver materials are installed within the OMVS environment in a directorynamed /usr/lpp/internet.As documented by IBM, installation of the Domino Go Webserver includesseveral steps using the RACF security administrator. Listed below are thedeviations <strong>and</strong> equivalent comm<strong>and</strong>s needed when installing this offering <strong>and</strong>using <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>.Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–47
Lotus Domino Go WebserverInstalling Domino Go Webserver on a <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>-secured SystemNote: Previously defined UNIX System Services <strong>and</strong> TCP/IP requirements musthave been completed be<strong>for</strong>e you attempt to install the Domino Go Webserver.The examples in the following steps reflect default procnames, typical groupnames, <strong>and</strong> typical GID value. Overall, these comm<strong>and</strong>s simply ensure that avalid OMVS UID <strong>and</strong> GID exist <strong>for</strong> each of the started tasks that access OMVS.1. A TSS FACILITY should be created <strong>for</strong> the web server. Once created, thisfacility can be added to each user acid that is allowed to log on to the webserver. Tailor the following comm<strong>and</strong> <strong>and</strong> then add it to the existing <strong>eTrust</strong><strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> startup control options:TSS MODIFY FAC(USERx=NAME=IMWEB)2. The Domino Go Webserver requires an acid <strong>for</strong> the web server started task<strong>and</strong> <strong>for</strong> a web administrator. Both of these acids must be connected to anOMVS Group ID <strong>for</strong> the web server. The following comm<strong>and</strong>s accomplishthis using the IBM default values.The web server started task, whose procname is IMWEBSRV, is also referredto by IBM as the web server daemon. Also, changing the ID of the webadministrator is recommended; however, this change must be coordinatedwith updates to the web server configuration file.TSS CRE(IMWEB) TYPE(GROUP) NAME('WEBSERVER GROUP') DEPT(anydept)TSS ADD(IMWEB) GID(205)TSS CRE(WEBADM) TYPE(USER) NAME('WEB ADMINISTRATOR')DEPT(anydept) FAC(IMWEB) PASSWORD(password,0)TSS ADD(WEBADM) UID(206) GROUP(IMWEB) DFLTGRP(IMWEB)HOME(/usr/lpp/internet) OMVSPGM(/bin/sh)TSS CRE(WEBSRV) TYPE(USER) NAME('WEBSERVER DAEMON/STC')DEPT(dept) FAC(STC,IMWEB)PASSWORD(password,0)TSS ADD(WEBSRV) UID(0) GROUP(IMWEB) DFLTGRP(IMWEB)HOME(/usr/lpp/internet) OMVSPGM(/bin/sh)MASTFAC(IMWEB)TSS ADD(STC) PROCNAME(IMWEBSRV) ACID(WEBSRV)3. Three other user acids, each having their own connected group, are requiredunless "surrogate user" support is disabled. This feature permits users toaccess the web server without requiring a signon. <strong>CA</strong> recommends that thisfeature be disabled <strong>for</strong> security reasons.1–48 Cookbook
Lotus Domino Go WebserverTo disable this feature, change the "Userid" option to "%%CLIENT%%"within the web server configuration file. See IBM documentation. If notdisabled, the following comm<strong>and</strong>s will create acids <strong>and</strong> groups <strong>for</strong> surrogatesupport following IBM examples:TSS CRE(EXTERNAL) TYPE(GROUP) NAME('WEB GROUP') DEPT(dept)TSS ADD(EXTERNAL) GID(999)TSS CRE(EMPLOYEE) TYPE(GROUP) NAME('WEB GROUP') DEPT(dept)TSS ADD(EMPLOYEE) GID(500)TSS CRE(SPECIAL) TYPE(GROUP) NAME('WEB GROUP') DEPT(dept)TSS ADD(SPECIAL) GID(255)TSS CRE(PUBLIC) TYPE(USER) NAME('WEB SURROGATE ID')DEPT(dept) FAC(IMWEB) PASSWORD(NOPW,0)TSS ADD(PUBLIC) UID(998) GROUP(EXTERNAL) DFLTGRP(EXTERNAL)HOME(/) OMVSPGM(/bin/sh)TSS CRE(INTERNAL) TYPE(USER) NAME('WEB SURROGATE ID')DEPT(dept) FAC(IMWEB) PASSWORD(NOPW,0)TSS ADD(INTERNAL) UID(537) GROUP(EMPLOYEE) DFLTGRP(EMPLOYEE)HOME(/) OMVSPGM(/bin/sh)TSS CRE(PRIVATE) TYPE(USER) NAME('WEB SURROGATE ID')DEPT(dept) FAC(IMWEB) PASSWORD(NOPW,0)TSS ADD(PRIVATE) UID(416) GROUP(SPECIAL) DFLTGRP(SPECIAL)HOME(/) OMVSPGM(/bin/sh)4. The acid <strong>for</strong> the web server started task (that is, Daemon) requires access tothe following IBMFAC <strong>and</strong> SURROGAT resources. Note that the final threepermits are not needed if surrogate support is disabled:TSS ADD(dept) IBMFAC(BPX.)TSS PERMIT(WEBSRV) IBMFAC(BPX.DAEMON) ACCESS(READ)TSS PERMIT(WEBSRV) IBMFAC(BPX.SERVER) ACCESS(UPDATE)TSS ADD(dept) SURROGAT(BPX.)TSS PERMIT(WEBSRV) SURROGAT(BPX.SRV.WEBADM) ACCESS(READ)TSS PERMIT(WEBSRV) SURROGAT(BPX.SRV.PUBLIC) ACCESS(READ)TSS PERMIT(WEBSRV) SURROGAT(BPX.SRV.PRIVATE) ACCESS(READ)TSS PERMIT(WEBSRV) SURROGAT(BPX.SRV.INTERNAL) ACCESS(READ)5. IBM documentation includes one install step where "RACF program control"is discussed. In the first part of this step, all users are given read access tothree load libraries related to the web server. This part is easily translated asfollows:TSS ADD(dept) DSNAME(CEE.)TSS ADD(dept) DSNAME(IMW.)TSS ADD(dept) DSNAME(SYS1.)TSS PERMIT(ALL) DSNAME(CEE.V1R5M0.SCEERUN)TSS PERMIT(ALL) DSNAME(IMW.V1R1M0.IMWMOD1)TSS PERMIT(ALL) DSNAME(SYS1.LINKLIB)ACCESS(READ)ACCESS(READ)ACCESS(READ)This step also describes several (RDEFINE <strong>and</strong> SETROPTS) comm<strong>and</strong>sneeded to exempt the above libraries from RACF "PADS" checking. Thesecomm<strong>and</strong>s are not applicable to <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> <strong>and</strong> can be skipped.Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–49
Lotus Notes Server(To RACF, these comm<strong>and</strong>s mark all programs in these libraries as"NOPADCHK". This means that any program-restricted data set accessshould not have to list any of the programs from these libraries. In otherwords, this marks all programs from these libraries as being trusted <strong>and</strong>there<strong>for</strong>e exempt from any program accessed data set / PADS checks. Thesecomm<strong>and</strong>s are not applicable to <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>.)6. Install steps, which discuss permission bits <strong>and</strong> the "sticky bit", are related toOMVS file security itself <strong>and</strong> are unrelated to RACF. There<strong>for</strong>e, such stepsshould be followed as described.Lotus Notes ServerThe Lotus Notes Server (email) can run on a z/<strong>OS</strong> or <strong>OS</strong>/390 environment. Theexternal security interface requires a facility <strong>and</strong> a DOMINO console interface(identified in IBM as DOMCON). This interface facilitates sending comm<strong>and</strong>sfrom z/<strong>OS</strong> or <strong>OS</strong>/390 to stop, start <strong>and</strong> manage Lotus Notes Server runningunder UNIX Systems Services.The Lotus Notes Server requires an acid <strong>for</strong> the server started task <strong>and</strong> a groupacid. The following comm<strong>and</strong>s accomplish this using the IBM default values.TSS CREATE(LOTUSGRP) TYPE(GROUP) NAME(LOTUSGROUP) DEPT(OMVSDEPT)TSS ADD(LOTUSGRP) GID(6789)TSS CREATE(DOMCON) TYPE(USER) NAME('LOTUS STC ACID') PASS(password,0)DEPT(OMVSDEPT) FACILITY(STC)TSS ADD(DOMCON) GROUP(LOTUSGRP) DFLTGRP(LOTUSGRP)TSS ADD(STC) PROCNAME(?????) ACID(DOMCON)The above comm<strong>and</strong> adding the stc should be done <strong>for</strong> all LOTUS PROCs. Therecan be multiple procs associated with this address space beginning with"DOMIN".TSS ADD(DOMCON) UID(0) HOME(/u/domcon) OMVSPGM(/bin/sh)TSS PERMIT(DOMCON) IBMFAC(BPX.DAEMON) ACCESS(READ)TSS ADD(DEPTACID) DSN(DOMCOM.WTO.LOAD)TSS PERMIT(DOMCON) DSN(DOMCOM.WTO.LOAD) ACCESS(READ)1–50 Cookbook
Lotus Notes <strong>and</strong> Novell Directory Services <strong>for</strong> z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390Lotus Notes <strong>and</strong> Novell Directory Services <strong>for</strong> z/<strong>OS</strong> <strong>and</strong><strong>OS</strong>/390This support was introduced at <strong>OS</strong>/390 V2R8. This enhancement enables <strong>eTrust</strong><strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> to map a user identity from a Lotus Notes or Novell DirectoryServices <strong>for</strong> z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 application to a <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> acid. Afteran application has determined a user's <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> acid, it mightchoose to use this acid when accessing MVS resources, such as data sets, <strong>and</strong>z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 UNIX System Services (z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 UNIX) files.An example of the <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> comm<strong>and</strong> needed to map a Lotus Notes<strong>for</strong> z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 user identity name would be:TSS ADD(acid) SNAME(lotus user identity name)An example of the <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> comm<strong>and</strong> needed to map a NovellDirectory Services <strong>for</strong> z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 user identity name would be:TSS ADD(acid) UNAME(Novell Directory Services user identity name)Digital Certificate SupportDigital certificates are a secure method <strong>for</strong> identifying users, typically through aweb-based application. Digital certificates are encrypted packages issued by atrusted third party called a certificate authority (<strong>CA</strong>). A certificate is used as anacid <strong>and</strong> password substitute. Because they are encrypted, digital certificatescannot be tampered with easily. A server can only decrypt them with access tothe proper key. Thus, digital certificates are protected from inspection whilepassing through the network.A digital certificate is associated to a <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> user through theuser's acid record, or the predefined acid CERTAUTH or CERTSITE. More thanone certificate can be issued to a user <strong>and</strong> <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> allows morethan one certificate to be added to a user's acid record. Since each certificateissued by a certificate authority is unique to a particular user, a certificate cannotbe added to more than one acid. However, more than one acid can use the samecertificate when the certificate is attached to a key ring.A key ring is a collection of digital certificates associated with an individual user.Once a user has had their identity verified to a system by a certificate that isunique to the user, the user can have access to additional resources through thecertificates on their key ring. Key rings provide an installation-wide method toshare digital certificates across multiple servers. A user can have more than onekey ring.Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–51
Digital Certificate SupportAn additional feature of <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> lets you check to see if a certificatehas already been added to the <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> <strong>Security</strong> File <strong>and</strong> with whatacid it is associated. Also, once a certificate has been added to <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong><strong>Secret</strong> it can be exported to a new data set.See the Comm<strong>and</strong> Functions Guide <strong>for</strong> exp<strong>and</strong>ed details beyond what ispresented in this Cookbook.The user ACID record can be administered with the TSS ADDTO, REPLACE,REMOVE, GENCERT, GENREQ, EXPORT, <strong>and</strong> CHKCERT comm<strong>and</strong>s.■■■■■■Use ADD <strong>and</strong> REPLACE to add or replace a certificate, label, or the START,FOR, UNTIL, TRUST, HITRUST <strong>and</strong> NOTRUST parameters.Use REMOVE only to remove the certificate from the user.Use GENCERT to generate a certificate from <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> <strong>and</strong> addit to a user.Use GENREQ to generate a PKCS#10 base 64-encoded digital certificaterequest <strong>and</strong> writes it to a data set.Use EXPORT to export a certificate from <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> to a new dataset.Use CHKCERT to see if a certificate has been added to the <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong><strong>Secret</strong> security file <strong>and</strong> with what acid it is associated.Associating a Unique Digital Certificate with a UserDigital certificates issued by a certificate authority are associated with a user byadding the certificate to the user's ACID record, or the predefined acidCERTAUTH or CERTSITE. If <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> generates a certificate it isadded to the user's ACID record when the certificate is created using the TSSGENCERT comm<strong>and</strong>.The certificate must be unique to the user. A certificate can be added to only oneuser's ACID record. Certificates can be shared only when they are attached to akey ring.1–52 Cookbook
Digital Certificate SupportGeneral RulesThe following rules <strong>and</strong> procedures apply <strong>for</strong> <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>administrators. They must have ACID(MAINTAIN) <strong>for</strong> users within their scope,plus MISC4(authority levels). Details <strong>for</strong> authority levels of MISC4 can be foundin the Comm<strong>and</strong> Functions Guide. Administrators must be defined with anOMVS segment UID, Group, <strong>and</strong> Default Group to per<strong>for</strong>m any digital certificatecomm<strong>and</strong>s <strong>and</strong> the Unix System Services (Open Edition) must be active.If the certificate is generated by the <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> GENCERT comm<strong>and</strong>,it is to be used <strong>for</strong> SSL server authentication. The certificate must beexported/imported to the client’s side repository so the public key is available inorder to successfully decrypt the server’s certificate during the SSLauthentication h<strong>and</strong>shake. Client software might be PC Workstation, Internetbrowser, AS400, Windows NT, MQSeries, FTPSSL, QWSSSL, etc. They also needauthority to the IBMFAC. To establish this authority, the IBMFAC must beowned:TSS ADD(tssdept) IBMFAC(IRR)Then permit to the administrator:TSS PERMIT(tssadmin1) IBMFAC(IRR.DIGTCERT.LISTRING) ACCESS(UPDATE)If the administrator submits batch scripts <strong>for</strong> Digital Certificates, they mustinclude REGION=0M in their job statement within the JCL.Third Party VendorsAny certificate obtained from third party vendors, such as Verisign, can beregistered to <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> via the TSS ADD comm<strong>and</strong>. Once thecertificate is received from the vendor it must be placed into a cataloged MVSdata set so that it can be accessed by <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>. This data set wouldthereby represent the value specified in the DCDSN keyword of the TSS ADDcomm<strong>and</strong>.TSS ADD(name) DIGICERT(namecert) DCDSN(name.certificate.data) TRUSTImplementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–53
Digital Certificate SupportAdding a Digital Certificate to an ACID RecordWhen adding a digital certificate, the DIGICERT <strong>and</strong> DCDSN keywords arerequired on the TSS ADD comm<strong>and</strong>. All other keywords are optional.The syntax <strong>for</strong> the ADD comm<strong>and</strong> follows:TSS ADD(acid|CERTAUTH|CERTSITE) DIGICERT(8-byte name) DCDSN(dsname)[START(sdate)][FOR(ddd)|UNTIL(date)][LABLCERT(label name)][TRUST|NOTRUST|HITRUST][ICSF][PKCSPASS(‘PKCSPASS PASSWORD’)]ACID—A user acid or you can specify:CERTAUTH—Is an acid in which your installation can maintain certificates thatwere generated by a third party certificate authority (<strong>CA</strong>). This acid ispre-defined in <strong>Top</strong> <strong>Secret</strong>. You cannot add a KEYRING to this ACID.CERTSITE—Is an acid in which your installation can maintain site-generatedcertificates. This acid is pre-defined in <strong>Top</strong> <strong>Secret</strong>. You cannot add a KEYRING tothis ACID.DIGICERT—Specifies a one- to eight-character ID that identifies the certificatewith the user acid.DCDSN—Specifies the MVS data set containing the digital certificate. The dataset must be defined as physical sequential (DSORG=PS) <strong>and</strong> variable blockeddata set (RECFM=VB). The data set name is entered as a fully qualified namewithout enclosed quotes. The data set must be cataloged <strong>and</strong> up to 26 characterlong (8.8.8.2).The certificate contained in the data set must be BER-encoded, PKCS-7BER-encoded, or Privacy Enhanced Mail (PEM)-encoded. PEM certificates mustbe transported to MVS as TEXT; the other <strong>for</strong>mats must be transported asBINARY. The length of the serial number <strong>and</strong> certificate authority distinguishedname must be less than 246.An example <strong>for</strong> the DCDSN comm<strong>and</strong> follows:TSS ADD(USER01) DIGICERT(DIGI0001) DCDSN(USER01.CERTIF.001)START—Specifies an optional activation date. This date is not the same as theactivation date defined in the certificate itself. The web server validates that date.This date gives the security administrator the ability to specify when thecertificate will become active on MVS.An example <strong>for</strong> the START comm<strong>and</strong> follows:TSS ADD(USER01) DIGICERT(DIGI0001) DCDSN(USER01.CERTIF.001) START(10/01/03)1–54 Cookbook
Digital Certificate SupportFOR|UNTIL—Specifies an optional expiration date. This date is not the same asthe expiration date defined in the certificate. The web server validates that date.This date gives the security administrator the ability to specify when thecertificate will expire on MVS.Examples <strong>for</strong> the FOR|UNTIL comm<strong>and</strong>s follow:TSS ADD(USER01) DIGICERT(DIGI0001) DCDSN(USER01.CERTIF.001) FOR(30)TSS ADD(USER01) DIGICERT(DIGI0001) DCDSN(USER01.CERTIF.001) UNTIL(10/01/03)LABLCERT—Specifies the label to be associated with the certificate being addedto the user. Up to 32 characters can be specified <strong>for</strong> the label name. Spaces areallowed if you use single quotes. This label is used as an identifier instead of theserial number <strong>and</strong> issuer's distinguished name, <strong>and</strong> must be unique <strong>for</strong> theindividual user. If a label is not specified, the label field will default to the valuespecified within the DIGICERT keyword.An example <strong>for</strong> the LABLCERT comm<strong>and</strong> follows:TSS ADD(USER01) DIGICERT(DIGI0001) LABLCERT(‘label <strong>for</strong> digicert 001’)TRUST|NOTRUST | HITRUST—A certificate can be associated with a useronly when TRUST is specified. The default is NOTRUST.Examples <strong>for</strong> the TRUST|NOTRUST |HITRUST comm<strong>and</strong>s follow:TSS ADD(USER01) DIGICERT(DIGI0001) DCDSN(USER01.CERTIF.001) TRUSTTSS ADD(USER01) DIGICERT(DIGI0001) DCDSN(USER01.CERTIF.001) NOTRUSTTSS ADD(CERTAUTH) DIGICERT(DIGI0001) DCDSN(USER01.CERTIF.001) HITRUST ** Important! HITRUST is only valid <strong>for</strong> the Acid named CERTAUTH.ICSF—If ICSF is specified <strong>and</strong> the IBM ICSF feature is enabled,(ICSF is theinterface to the cryptographic hardware on z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390. You must havecryptographic hardware installed <strong>and</strong> enabled on your system) the private key isstored in the ICSF data facility.An example <strong>for</strong> the ICSF attribute follows:TSS ADD(USER01) DIGICERT(DIGI0001) DCDSN(USER04.CERTIF.001) ICSFNote: If the certificate's private key resides in an ICSF storage facility <strong>and</strong> the<strong>for</strong>mat of PKCS12DER or PKCS12B64 is specified in the TSS EXPORT comm<strong>and</strong>,the comm<strong>and</strong> is rejected <strong>and</strong> a TSS0533E message is issued.PKCSPASS—The PKCCS-password can be up to 255 characters, is case sensitive,<strong>and</strong> can contain blanks.Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–55
Digital Certificate SupportGenerating a Digital Certificate <strong>and</strong> Adding It to a UserThe GENCERT comm<strong>and</strong> gives the administrator the ability to create a digitalcertificate <strong>and</strong> potentially a public/private key pair.The DIGICERT keyword is required on the TSS GENCERT comm<strong>and</strong>. If bothDCDSN <strong>and</strong> SUBJECTN are specified, the SUBJECTN in<strong>for</strong>mation overrides therequest data set name. If SUBJECTN is specified, only one of the SUBJECTN subfields is required to be entered.The syntax <strong>for</strong> the GENCERT comm<strong>and</strong> follows:TSS GENCERT [{CERTAUTH|CERTSITE|acid}] DIGICERT(8-byte-name)[DCDSN(request-data-set-name)\][SUBJECTN ('CN="common-name"T="title"OU="organizational-unit-name1,organizational-unit-name2"O="organizational-name"L="locality"ST="2-character-only-state-or-province"C="country"')][ALTNAME('IP=numeric-IP-address DOMAIN=internet-domain-nameEMAIL=email-address URI=universal-resource-identifier')][ICSF][KEYSIZE(key-size)][KEYUSAGE(‘HANDSHAKE DATAENCRYPT DOCSIGN CERTSIGN’)][LABLCERT(label-name)][NBDATE(mm/dd/yy) NBTIME(hh:mm:ss)][NADATE(mm/dd/yy) NATIME(hh:mm:ss)][SIGNWITH(acid,digicert)]The sub keywords of the GENCERT function specify the in<strong>for</strong>mation that is to becontained within the certificate that is being created.ACID—A user acid or you can specify.CERTAUTH—Is an acid in which your installation can maintain certificates thatwere generated by a third party certificate authority (<strong>CA</strong>). This acid ispre-defined in <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>. You cannot add a KEYRING to this acid.CERTSITE—Is an acid in which your installation can maintain site-generatedcertificates. This acid is pre-defined in <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>. You cannot add aKEYRING to this acid.DIGICERT—Specifies a one- to eight-character ID that identifies the certificatewith the user acid. The DIGICERT must be entered as part of all GENCERTcomm<strong>and</strong>s since this keyword indicates the name to be used in the digitalcertificate.An example <strong>for</strong> the DIGICERT comm<strong>and</strong> follows:TSS ADD(USER01) DIGICERT(DIGI0001)1–56 Cookbook
Digital Certificate SupportDCDSN(request-data-set-name)—Specifies the name of an optional data set thatcontains the PKCS#10 certificate request data. The request data set name can bethe output from a TSS GENREQ comm<strong>and</strong>. The request data contains the user'sgenerated public key <strong>and</strong> X.509 distinguished name. The request data must besigned, DER-encoded, <strong>and</strong> then Base64 encoded according to PKCS#10 st<strong>and</strong>ard.The data set must be cataloged <strong>and</strong> up to 26 characters long (8.8.8.2).If DCDSN is not specified, <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> does not generate a key pairbecause this data set contains the user's public key. If DCDSN is specified,SIGNWITH must also be specified because the request-data-set-name (inDCDSN) does not contain a private key.An example <strong>for</strong> the DCDSN comm<strong>and</strong> follows:TSS GENCERT(USER01) DIGICERT(DIGI0001) DCDSN(USER01.CERTIF.001)SUBJECTN—The attributes can consist of 229 characters if it is a self-signedcertificate. Otherwise, if it is a non-self signed certificate, the maximum length is225-characters. You can use A-Z <strong>and</strong> 0-9. The only exception is ST=STATE orPROVINCE. This is a 2-digit value field. If DCDSN or SUBJECTN is notspecified, the SUBJECTN will default to the acid name field. Note: If any of thevalues contain blanks, they must be enclosed in double quotes. The completeSUBJECTN phase must be enclosed in parenthesis <strong>and</strong> single quotes.An example <strong>for</strong> the SUBJECTN comm<strong>and</strong> follows:TSS GENCERT(USER01) DIGICERT(DIGI0001) SUBJECTN(‘CN=”Ted User” ST=NJ’)ALTNAME—Specifies the appropriate values <strong>for</strong> the SubjectAltname extension,of which one or more values might be coded. There is no default. The followingare possible values that can be used:■■■IP—Specifies a string containing a fully qualified IP address in IPV4 dotteddecimal <strong>for</strong>m, which is four decimal numbers (each number must be a valuefrom 0-255) separated by periods.For example: 203.9.102.100DOMAIN—Specifies a string containing a fully qualified internet domainname.For example: <strong>CA</strong>.COMEMAIL—Specifies a string containing a fully qualified email address.For example: david@kindgom.netImplementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–57
Digital Certificate Support■URI—Specifies the universal resource identifier.For example: www.ca.comNotes:– When you specify multiple parameters to ALTNAME, you must includeone single quote at the beginning <strong>and</strong> end of parameter list.For example: ALTNAME('IP=201.100.10.9 EMAIL=my.email@test.net')– Multiple parameters are separated with a space (see example above).ICSF—If ICSF is specified <strong>and</strong> the IBM ICSF feature is enabled, the private key isstored in the ICSF data facility.An example <strong>for</strong> the ICSF attribute follows:TSS GENCERT(USER01) DIGICERT(DIGI0001) ICSFKEYSIZE—Specifies the size of the private key in decimal bits. The maximumkey size is determined by United States of America export regulations <strong>and</strong> iscontrolled by non <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> code in z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390. Currently,the st<strong>and</strong>ard sizes <strong>for</strong> keys are:■■■512—low-strength key768—medium-strength key1024—high-strength key (Default)Examples <strong>for</strong> the KEYSIZE comm<strong>and</strong> follow:TSS ADD(USER01) DIGICERT(DIGI0001) DCDSN(USER01.CERTIF.001) KEYSIZE(512)TSS ADD(USER01) DIGICERT(DIGI0001) DCDSN(USER01.CERTIF.001) KEYSIZE(768)TSS ADD(USER01) DIGICERT(DIGI0001) DCDSN(USER01.CERTIF.001) KEYSIZE(1024)KEYUSAGE—Specifies key attribute in<strong>for</strong>mation, including the appropriatevalues <strong>for</strong> the KeyUsage certificate extension, of which one or more of the valuesmight be coded. For certificate authority certificates (CERTAUTH) the default isCERTSIGN <strong>and</strong> is always set. There is no default <strong>for</strong> certificates that are notcertificate-authority certificates. Valid values <strong>for</strong> KEYUSAGE include thefollowing:■■■■HANDSHAKE - Facilitates identification <strong>and</strong> key exchange during securityh<strong>and</strong>shakes, such as SSL, which set the digital signature <strong>and</strong> keyencipherment indicators.DATAENCRYPT - Encrypts data, which sets the data enciphermentindicator.DOCSIGN - Specifies a legally-binding signature, which set thenon-repudiation indicator.CERTSIGN - Specifies a signature <strong>for</strong> the other digital certificates <strong>and</strong> CRLs,which sets the keyCertSign an cRLSign indicators.1–58 Cookbook
Digital Certificate SupportNote: Include single quotes if specifying more than one value with KEYUSAGE.For example:KEYUSAGE('HANDSHAKE DATAENCRYPT')LABLCERT—Specifies an optional <strong>and</strong> case-sensitive label to be associated withthe certificate being added to the user. Up to 32 characters can be specified <strong>for</strong>the label name. Spaces are allowed if you use single quotes. This label is used asa h<strong>and</strong>le instead of the serial number <strong>and</strong> issuer's distinguished name, <strong>and</strong> mustbe unique <strong>for</strong> the individual user. If a label is not specified, the label field willdefault to the value specified within the DIGICERT keyword.NADATE/NATIME—The optional NADATE <strong>and</strong> NATIME keywords specifythe effective dates <strong>and</strong> times to not be used in the digital certificate. TheNADATE specifies the “not after” date after which a digital certificate cannot beused. The NATIME specifies the “not after” time after which the certificatecannot be used. The certificate is deactivated after this date <strong>and</strong> time.An example <strong>for</strong> the NADATE/NATIME comm<strong>and</strong> follows:TSS GENCERT(user1) DIGICERT(cert0001) DCDSN(user1.cert.data)NADATE(09/01/03) NATIME(00:00:01)Date <strong>and</strong> time fields are optional, except if time is specified, date is required. IfNADATE is omitted, the default is one year from the date the certificate isgenerated.NBDATE/NBTIME— The optional NBDATE <strong>and</strong> NBTIME keywords specifythe effective dates <strong>and</strong> times to be used in the digital certificate. The NBDATEspecifies the “not be<strong>for</strong>e” date which a digital certificate can be used. TheNBTIME specifies the “not be<strong>for</strong>e” time which the certificate can be used. Thecertificate is activated at the specified date <strong>and</strong> time.An example <strong>for</strong> the NBDATE/NBTIME comm<strong>and</strong> follows:TSS GENCERT(user1) DIGICERT(cert0001) DCDSN(user1.cert.data)NBDATE(09/01/02) NBTIME(08:00:01)Date <strong>and</strong> time fields are optional, except if time is specified, date is required.SIGNWITH—Specifies the certificate with a private key that is signing thecertificate. If not specified, the default is to sign the certificate with a private keyof the certificate that is being generated. This creates a self-signed certificate. IfSIGNWITH is specified, it must refer to a certificate that has a private keyassociated with it. If no private key is associated with the certificate, anin<strong>for</strong>mational message is generated <strong>and</strong> processing stops. If DCDSN is specifiedon the GENCERT comm<strong>and</strong>, the SIGNWITH keyword is required.Self-signed certificates are always trusted, while all other certificates are createdwith the trust status of the certificate specified in the SIGNWITH keyword. If thecertificate specified in the SIGNWITH keyword is not trusted, an in<strong>for</strong>mationalmessage is issued, but the certificate is still generated.Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–59
Digital Certificate SupportAn example <strong>for</strong> the SIGNWITH keyword follows:TSS GENCERT(USER01) DIGICERT(CERT0001) DCDSN(USER1.CERT.DATA) -SIGNWITH(USER02,CERT002)Listing Digital Certificate In<strong>for</strong>mationTo list in<strong>for</strong>mation about a digital certificate, identify the digital certificate by itscertificate name or label, or by both its serial number <strong>and</strong> the issuer'sdistinguished name, or by segment data. The syntax follows:TSS LIST(acid|CERTAUTH|CERTSITE) {LABLCERT('label name')}{DIGICERT(8-byte name)}{SERIALNUM(serial-number) ISSUERDN(issuer's DN)}{SEGMENT(certdata)}{SEGMENT(ALL)}{KEYRING(8-byte name)}{LABLRING(237-byte name)}For each certificate, the list comm<strong>and</strong> displays the following in<strong>for</strong>mation:■■■■■■■■■■■serial numberissuer's distinguished namelabelstatusvalidity datesprivate key size (If private key is present)private key type (If private key is present)rings (If private key is present)keyusagealtnamesubject's name as found in the certificate itself, up to 256 bytesYou can list all the acids <strong>and</strong> the digital certificates associated with them byexecuting the following comm<strong>and</strong>:TSS LIST(SDT) DIGICERT(ALL)You can list all the acids <strong>and</strong> their keyrings associated with them by executingthe following comm<strong>and</strong>:TSS LIST(SDT) KEYRING(ALL)1–60 Cookbook
Digital Certificate SupportYou can list the associated SEGMENT in<strong>for</strong>mation <strong>for</strong> a specific ACID byexecuting the following comm<strong>and</strong>:TSS LIST(USER01) SEGMENT(CERTDATA)TSS LIST(USER01) SEGMENT(RINGDATA)TSS LIST(USER01) SEGMENT(ALL)You can list the associated DIGICERT <strong>for</strong> a specific acid by executing thefollowing comm<strong>and</strong>. The comm<strong>and</strong> must contain the name of the DIGICERT orKEYRING already associated with the ACID.TSS LIST(USER01) DIGICERT(CERT001)orTSS LIST(USER01) KEYRING(ACCTRING)Generating a Certificate RequestYou can send a request to a certificate authority to verify the validity of a digitalcertificate. If <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> generated the certificate, the request isimported to <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> just as if the certificate authority was anothercompany.The request contains the subject's distinguished name <strong>and</strong> public key <strong>and</strong> issigned with the private key associated with the specified certificate. A PKCS#10base64-encoded request is generated <strong>and</strong> written to data set. The GENREQDCDSN must not be defined. Meaning the output DCDSN cannot be allocatedor cataloged, this happens when you use the GENREQ comm<strong>and</strong>. The data setcan be used as the DCDSN in a TSS GENCERT comm<strong>and</strong>.The syntax <strong>for</strong> the GENREQ comm<strong>and</strong> requires the DCDSN, <strong>and</strong> that youidentify the certificate using DIGICERT or LABLCERT (or both).TSS GENREQ(acid|CERTAUTH|CERTSITE) DCDSN(output data set name){DIGICERT(name)}or{LABLCERT('label name')}An example <strong>for</strong> the GENREQ comm<strong>and</strong> follows:TSS GENREQ(user1) DIGICERT(cert0001) DCDSN(USER3.CERT.DATA) LABLCERT(‘REQUEST 3’)ACID—A user acid or you can specify,CERTAUTH—Is an acid in which your installation can maintain certificates thatwere generated by a third party certificate authority (<strong>CA</strong>). This acid ispre-defined in <strong>Top</strong> <strong>Secret</strong> or you can specify. You cannot add a KEYRING to thisACID.CERTSITE—Is an acid in which your installation can maintain site-generatedcertificates. This acid is pre-defined in <strong>Top</strong> <strong>Secret</strong>. You cannot add a KEYRING tothis ACID.Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–61
Digital Certificate SupportDCDSN(output-data-set-name)—The data set will be allocated <strong>and</strong> cataloged,<strong>and</strong> will contain the ouput data set from the genreq’ed digital certificate. Thedata set name will con<strong>for</strong>m to the MVS st<strong>and</strong>ards, up to a maximum of 26characters.DIGICERT—Specifies a one- to eight-character ID that identifies the certificatewith the user acid.LABLCERT—Specifies an optional <strong>and</strong> case-sensitive label to be associated withthe certificate being added to the user. Up to 32 characters can be specified <strong>for</strong>the label name. Spaces are allowed if you use single quotes. This label is used asa h<strong>and</strong>le instead of the serial number <strong>and</strong> issuer’s distinguished name, <strong>and</strong> mustbe unique <strong>for</strong> the individual user. If a label is not specified, the label field willdefault to the value specified within the DIGICERT keyword.Changing a User's CertificateUse the REPLACE comm<strong>and</strong> to update a user certificate.If the certificate has a connection to a user key ring, the certificate is replaced <strong>and</strong>all key ring connections continue with the new certificate. This lets you update auser's certificate without the need to reconnect the certificate to key rings.On a REPLACE comm<strong>and</strong>, the digital certificate that you want to update can beidentified three different ways: by using DIGICERT or LABLCERT, or by usingboth SERIALNUM <strong>and</strong> ISSUERDN.The syntax <strong>for</strong> the REPLACE comm<strong>and</strong> to replace as user certificate requires theDCDSN parameter as shown next.TSS REPLACE(acid|CERTAUTH|CERTSITE) DCDSN(dsname){DIGICERT(name)}{LABLCERT(label name)}{SERIALNUM(serial number) ISSUERDN(issuer's dist' name)}SERIALNUM—Specifies the certificate's serial number.ISSUERDN—Specifies the certificate issuer's distinguished name.Certificate Replacement (Renewal)As part of the TSS Replace comm<strong>and</strong> processing, a certificate can be replacedwithout deleting <strong>and</strong> reinserting it. To replace an existing certificate, make surethat one of the following three(3) cases is satisfied:Case #1. The certificate being added is a duplicate of the existing certificate(i.e.,has the same serial number <strong>and</strong> issuer’s distinguished name) <strong>and</strong> the labels <strong>and</strong>record keys of both certificates are the same;1–62 Cookbook
Digital Certificate SupportCase #2. The certificate being added is NOT a duplicate of the existing certificate,has the same subject’s distinguished name, issuer’s distinguished name, <strong>and</strong>public key as the existing certificate, the end date <strong>and</strong> time on the certificatebeing added is later than on that of the existing certificate, the existing certificateis NOT expired, <strong>and</strong> the record keys of both certificates are the same;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 keyassociated with the existing certificate in the database, the existing certificate isNOT expired, <strong>and</strong> the record keys of both certificates are the same.An example <strong>for</strong> the REPLACE comm<strong>and</strong> follows:TSS REPLACE(USER01) DIGICERT(DIGI0001) DCDSN(USER1.CERT.DATA)Changing a Certificate's StatusThe trust status of a certificate can be changed <strong>for</strong> a specified user or certificateauthority. The status of the certificate is updated according to whether TRUST,NOTRUST or HITRUST is specified on the comm<strong>and</strong>.Important! HITRUST is only valid <strong>for</strong> the Acid named CERTAUTH.On a REPLACE comm<strong>and</strong>, the digital certificate that you want to update can beidentified three different ways: by using DIGICERT or LABLCERT, or by usingboth SERIALNUM <strong>and</strong> ISSUERDN.The syntax <strong>for</strong> the REPLACE comm<strong>and</strong> follows:TSS REP(acid|CERTAUTH|CERTSITE) {DIGICERT(name)}{LABLCERT(label name)}{SERIALNUM(serial number) ISSUERDN(issuer's dist' name)}TRUST|NOTRUST|HITRUSTAn example <strong>for</strong> the REPLACE comm<strong>and</strong> follows:TSS REPLACE(user1) DIGICERT(cert0001) NOTRUSTChanging a Certificate's LabelThe label <strong>for</strong> a certificate can be changed. The syntax requires that the certificate<strong>for</strong> which the label is being updated be identified using DIGICERT or by usingSERIALNUM <strong>and</strong> ISSUERDN.Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–63
Digital Certificate SupportThe syntax <strong>for</strong> using the REPLACE comm<strong>and</strong> to change a label follows:TSS REPLACE(acid|CERTAUTH|CERTSITE) {DIGICERT(name)}{SERIALNUM(serial number) ISSUERDN(issuer's dist' name)}LABLCERT(label name)An example <strong>for</strong> the LABLCERT comm<strong>and</strong> follows:TSS REPLACE(USER01) DIGICERT(DIGI0001) LABLCERT(‘label <strong>for</strong> digicert 002’)Removing a Certificate from a UserYou can use the REMOVE comm<strong>and</strong> to remove a certificate from a user.If the certificate has a connection to a user key ring, the certificate is removedalong with any key ring connections it can have.On a REMOVE comm<strong>and</strong>, the digital certificate can be identified three differentways: by using DIGICERT or LABLCERT, or by using both SERIALNUM <strong>and</strong>ISSUERDN.Use the following comm<strong>and</strong> to remove a certificate from a user:TSS REM(acid|CERTAUTH|CERTSITE) {DIGICERT(8-byte name)}{LABLCERT(label name)}{SERIALNUM(serial number) ISSUERDN(issuer's dist' name)}An example <strong>for</strong> the REMOVE comm<strong>and</strong> follows:TSS REMOVE(USER01) DIGICERT(DIGI0001)Determining if a Certificate has been Added to <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>You can check to see who has a certificate in a specified data set. The CHKCERTcomm<strong>and</strong> determines whether the digital certificate in the specified data set hasbeen added to the <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> security file <strong>and</strong> associated with an acid.Use the following syntax <strong>for</strong> TSS CHKCERT:TSS CHKCERT DCDSN(input data-set-name) PKCSPASS(pksc12-password)DCDSN(input-data-set-name)—Specifies the name of an optional data set thatcontains the PKCS#10 certificate request data. The request data set name can bethe output from a TSS GENREQ comm<strong>and</strong>. The request data contains the user'sgenerated public key <strong>and</strong> X.509 distinguished name. The request data must besigned, DER-encoded, <strong>and</strong> then Base64 encoded according to PKCS#10 st<strong>and</strong>ard.PKCSPASS—The PKCS-password can be up to 255 characters, is case sensitive,<strong>and</strong> can contain blanks.1–64 Cookbook
Digital Certificate SupportImportant! The password associated with PKCS#12 certificates are notviewable. It is the <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> administrator's responsibility to keep track ofthe PKCS#12 password that is assigned to the digital certificate.Exporting Certificates to Data SetsYou can export a certificate from a <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> security file to a newdata set using the TSS EXPORT comm<strong>and</strong>. The certificate to be exported can beidentified by its DIGICERT name or by its label. You cannot export a digitalcertificate with ICSF.Use the following syntax <strong>for</strong> TSS EXPORT:TSS EXPORT(acid|CERTAUTH|CERTSITE){DIGICERT(name) {LABLCERT{up to 32 characters)}{DCDSN(output-data set name) FORMAT(<strong>for</strong>mat type)}{PKCSPASS(PKCS#12 password)}ACID—A user acid or you can specify:CERTAUTH—Is an acid in which your installation can maintain certificates thatwere generated by a third party certificate authority (<strong>CA</strong>). This acid ispre-defined in <strong>Top</strong> <strong>Secret</strong> or you can specify. You cannot add a KEYRING to thisACID.CERTSITE—Is an acid in which your installation can maintain site-generatedcertificates. This acid is pre-defined in <strong>Top</strong> <strong>Secret</strong>. You cannot add a KEYRING tothis ACID.DIGICERT—Specifies a one- to eight-character ID that identifies the certificatewith the user acid. The DIGICERT must be entered as part of all GENCERTcomm<strong>and</strong>s since this keyword indicates the name to be used in the digitalcertificate.DCDSN(output-data-set-name)—The data set will be allocated <strong>and</strong> cataloged,<strong>and</strong> will contain the output from the exported digital certificate. The data setname will con<strong>for</strong>m to the MVS st<strong>and</strong>ards, up to a maximum of 26 characters.FORMAT—The following oper<strong>and</strong>s can be used with the FORMAT keyword:■■■■CERTB64—Indicates Base64 encoded certificates (default).CERTDER—Indicates DER encoded X.509 certificates.PKCS12B64—Indicates DER encoded (then Base64 encoded) PKCS#12package.PKCS12DER—Indicates DER encoded PKCS#12 package.An example <strong>for</strong> the FORMAT comm<strong>and</strong> follows:TSS EXPORT(USER01) DIGICERT(DIGI0001) DCDSN(USER3.CERT.DATA) FORMAT(CERTDER)Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–65
Digital Certificate SupportLABLCERT—Specifies an optional <strong>and</strong> case-sensitive label to be associated withthe certificate being added to the user. Up to 32 characters can be specified <strong>for</strong>the label name. Spaces are allowed if you use single quotes. This label is used asa h<strong>and</strong>le instead of the serial number <strong>and</strong> issuer’s distinguished name, <strong>and</strong> mustbe unique <strong>for</strong> the individual user. If a label is not specified, the label field willdefault to the value specified within the DIGICERT keyword.PKCSPASS—The PKCS-password can be up to 255 characters, is case sensitive,<strong>and</strong> can contain blanks.Important!■■The password associated with PKCS#12 certificates are not viewable. It is the<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> administrator’s responsibility to keep track of thePKCS#12 password that is assigned to the digital certificate.If the certificate’s private key resides in an ICSF storage facility <strong>and</strong> the<strong>for</strong>mat of PKCS12DER or PKCS12B64 is specified in the TSS EXPORTcomm<strong>and</strong>, the comm<strong>and</strong> is rejected. A TSS0533E message is issued. Youcannot export a digital certificate with ICSF.Sharing Certificates on Key RingsA key ring is a collection of digital certificates <strong>for</strong> an individual user. Key ringsprovide an installation-wide method to share digital certificates across multipleservers. A user can have more than one key ring.Creating a Key RingUse the following syntax to add a key ring to a user's acid record:TSS ADD(acid) KEYRING(8-byte key ring name) [LABLRING(237-byte ring name)]KEYRING—Specifies the key ring being added to the user's acid. An individualacid can be a member of more than one key ring.LABLRING—Specifies the label to be associated with the keyring being added tothe user. Up to 237 characters can be specified <strong>for</strong> the lablring name. This label isused as an identifier of the digital certificate code <strong>and</strong> must be unique <strong>for</strong> the keyring.You can add digital certificates that were issued by a certificate authority to oneuser to another user's key ring. This allows the administrator to further definethe access that a user has to certain resources. Be<strong>for</strong>e a digital certificate can beadded to a key ring, it must have been added to the owner's acid record throughthe TSS ADD DIGICERT comm<strong>and</strong>.Note: You cannot add a KEYRING to predefined ACIDS (CERTAUTH orCERTSITE).1–66 Cookbook
Digital Certificate SupportAdding a Certificate to a Key RingThe following syntax shows how to add a digital certificate to a key ring:TSS ADD(acid) KEYRING(8-byte key ring name)[LABLRING(237-byte ring name)]{RINGDATA(acid,digicert)}{RINGDATA(CERTAUTH,digicert)}{RINGDATA(CERTSITE,digicert)}[DEFAULT][USAGE(PERSONAL|CERTAUTH|CERTSITE)]The sub keywords of the KEYRING function specify more detailed in<strong>for</strong>mationthat can be added along with KEYRING.KEYRING – The ring name is unique within the user, the name you specify inKEYRING will identify the key ring <strong>for</strong> a user.LABLRING – Provides the ability to add a 237-character label name to the keyring; can be used as a key to locate a certificate key ring. If not specified, the8-byte KEYRING name is automatically added to the LABLRING.RINGDATA—Specifies the acid <strong>and</strong> certificate label name (as specified byDIGICERT) of the certificate being added to the user.DEFAULT—Specifies that the certificate is the default certificate <strong>for</strong> the key ring.This parameter is optional. Only one certificate within the key ring can be thedefault. If a default already exists, its DEFAULT status is removed, <strong>and</strong> thespecified certificate becomes the default certificate.USAGE—Specifies how this certificate is used with the specified key ring. Thedefault usage is the same as the certificate that is being connected.■■■PERSONAL—Demotes a certificate to ensure that it is not used as acertificate authority in this key ring.CERTAUTH—Promotes an ordinary user certificate to that of a certificateauthority within this key ring.CERTSITE—Promotes an ordinary user certificate to that of a site certificate.Removing a Key ring from an acidTo remove a key ring, use the TSS REMOVE comm<strong>and</strong> with the followingsyntax:TSS REMOVE(acid) {KEYRING(8-byte name)|LABLRING(237-byte ring name)}This comm<strong>and</strong> also removes all key ring cross references from all acids that havecertificates that were attached to the key ring that is being removed.Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–67
Digital Certificate SupportExtracting Certificates from Key RingsAuthorized applications, such as servers HTTP, TN3270, CICS, or LDAP, invokethe R_Datalib callable service (IRRSDL00) in order to retrieve certificates <strong>and</strong>private keys from a Key ring, <strong>and</strong> manage serial numbers <strong>for</strong> certain certificates.<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> supports the R_Datalib functions using its Keyringsupport. You must authorize these accesses to IRRSDL00 functions byadministering IBM resource class (IBMFAC) facility permissions <strong>for</strong> theIRR.DIGTCERT.function. Where function could be LISTRING, LIST, orGENCERT.For example, to extract a user certificate from a key ring, the user would requireaccess to IBMFAC function LISTRING:TSS ADD(dept) IBMFAC(IRR.DIGTCERT)TSS PER(acid) IBMFAC(IRR.DIGTCERT.LISTRING) ACCESS(UPDATE)TSS PER(acid) IBMFAC(IRR.DIGTCERT.LIST) ACCESS(UPDATE)TSS PER(acid) IBMFAC(IRR.DIGTCERT.GENCERT) ACCESS(UPDATE)Note: If the certificate user ID is the same as the user ID issuing the R-Datalibcall, the required authority is ACCESS (READ). If the user Id is not the same,then the required authority is ACCESS (UPDATE) or ACCESS (CONTROL).Extracting Private KeysAn application can extract the private key from a user certificate if the followingconditions are met:■■■■■The caller’s user ID is the user ID associated with the certificateThe certificate is connection to its key ring with the PERSONAL usageoption.An application can extract the private key from a CERTAUTH or CERTSITEcertificate if the following conditions are met:The caller’s user ID has at least CONTROL access to the IBMFAC resourceIRR.DIGTCERT.GENCERT.The certificate is connection to its key ring with the PERSONAL usageoption.1–68 Cookbook
Digital Certificate SupportReconnecting Private KeysWhen generating self-signed certificates using GENCERT, a public/private keypair is built <strong>and</strong> stored within the certificate. The private key always remainswith the certificate unless it is sent to a third-party as a certificate request. Whena GENREQ certificate request is sent to a third-party, the returned certificate willnot contain the private key. This happens because private keys are not shippedas part of a certificate request.To use a third-party certificate, the private key must be re-connected to thecertificate. This is accomplished automatically when a TSS ADD comm<strong>and</strong> isissued to re-connect the third-party certificate to the same user id that has the(model) certificate. The original, self-signed certificate private key, is connectedto the new certificate.As long as the user id is the same <strong>and</strong> the public key within the third-partycertificate matches the original certificate, the private key is connected.Listing Key Ring In<strong>for</strong>mationYou can list all the acids <strong>and</strong> their keyrings associated with them by executingthe following comm<strong>and</strong>:TSS LIST(SDT) KEYRING(ALL)You can also list the associated KeyRing <strong>and</strong> LABLRING <strong>for</strong> a specific acid byexecuting the following comm<strong>and</strong>. The comm<strong>and</strong> must contain the name of theKeyRing or LABLRING already associated with the acid.TSS LIST(USER01) KEYRING(RING0001) orTSS LIST(USER01) LABLRING(LABELRING0002)Managing Certificate Serial NumbersAn application can invoke the R_Datalib callable service to manage serialnumbers <strong>for</strong> certificates.An application can increment the “last serial number issued” <strong>for</strong> a personal(user) certificate if the following conditions are met:■■The caller’s user ID is the user ID associated with the certificateThe caller’s user ID has at least READ authority to the IBMFAC resourceIRR.DIGTCERT.GENCERT.TSS PER(acid) IBMFAC(IRR.DIGTCERT.GENCERT) ACCESS(READ)Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–69
Digital Certificate SupportAn application can increment the “last serial number issued” <strong>for</strong> a CERTAUTHor CERTSITE certificate if the following conditions are met:■■The caller’s user ID is the user ID associated with the certificateThe caller’s user ID has at least CONTROL authority to the IBMFACresource IRR.DIGTCERT.GENCERTTSS PER(acid) IBMFAC(IRR.DIGTCERT.GENCERT) ACCESS(CONTROL)CERTADMThe following is a copy of the <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> supplied comm<strong>and</strong> list,CERTADM. This list contains sample Digital Certificate comm<strong>and</strong>s that presentthe various Digital Certificate supported functional keywords./*=====================================================================*//*Basic Self-signed Digital Certificate *//*=====================================================================*/TSS CREATE(GENCDIV) TYPE(DIV) NAME('GENCERT DIVISION')TSS CREATE(GENCDEPT) TYPE(DEPT) DIV(GENCDIV)TSS CREATE(MARY001) NAME('GENCERT USER MARY') TYPE(USER) -PASSWORD(123,0) DEPT(GENCDEPT)TSS GENCERT(MARY001) DIGICERT(MARYCERT)TSS LIST(MARY001) DATA(ALL,PASSWORD)TSS REPLACE(MARY001) DIGICERT(MARYCERT) -LABLCERT('SELF-SIGNED PRIVATE KEY FOR MARY')TSS LIST(MARY001) LABLCERT('SELF-SIGNED PRIVATE KEY FOR MARY')TSS LIST(SDT) DIGICERT(ALL)TSS LIST(MARY001) SEGMENT(CERTDATA)/*=====================================================================*//*Create 5 Digital Certificates & add to the same user acid) *//*=====================================================================*/TSS CREATE(GENCDIV) TYPE(DIV) NAME('GENCERT DIVISION')TSS CREATE(GENCDEPT) TYPE(DEPT) DIV(GENCDIV) -NAME('GENCERT DEPARTMENT')TSS CREATE(JAMES01) NAME('GENCERT USER JAMES') TYPE(USER) -PASSWORD(123,0) DEPT(GENCDEPT)TSS LIST(JAMES01) DATA(ALL,PASSWORD)TSS GENCERT(JAMES01) DIGICERT(JIM01) LABLCERT('1ST D.CERT FOR JIM') -KEYSIZE(512) KEYUSAGE(HANDSHAKE) ALTNAME('IP=203.9.102.100')TSS LIST(JAMES01) DATA(ALL,PASSWORD)TSS LIST(SDT) DIGICERT(ALL)TSS GENCERT(JAMES01) DIGICERT(JIM02) LABLCERT('2ND D.CERT FOR JIM') -NBDATE(10/01/02) NBTIME(08:00:00) -NADATE(10/01/03) NATIME(09:00:00) -KEYUSAGE(DATAENCRYPT) KEYSIZE(768) ALTNAME(DOMAIN=<strong>CA</strong>.COM) -SUBJECTN('CN="JAMES SECOND DIGICERT"')TSS LIST(JAMES01) DIGICERT(JIM02)TSS LIST(SDT) DIGICERT(ALL)TSS GENCERT(JAMES01) DIGICERT(JIM03) -NBDATE(10/01/02) NBTIME(08:00:00) -NADATE(10/31/03) NATIME(09:00:00) -KEYSIZE(1024) -LABLCERT('3RD D.CERT FOR JIM') -KEYUSAGE(DOCSIGN) -ALTNAME('IP=201.100.10.9 EMAIL=JAMES03@TEST.NET') -SUBJECTN('T="THIRD BOOK OF JAMES" OU=PAYROLL')1–70 Cookbook
Digital Certificate SupportTSS LIST(JAMES01) DIGICERT(JIM03)TSS LIST(SDT) DIGICERT(ALL)TSS GENCERT(JAMES01) DIGICERT(JIM04) -SUBJECTN('CN="JIM DOUGLAS" O=<strong>CA</strong> ST="NEW JERSEY" C=US -T="TEST GENCERT" L="NO. BRUNSWICK"') -KEYSIZE(1024) -LABLCERT('4TH D.CERT FOR JIM') -KEYUSAGE(CERTSIGN) -ALTNAME(URI=WWW.<strong>CA</strong>.COM)TSS LIST(JAMES01) DIGICERT(JIM04)TSS LIST(SDT) DIGICERT(ALL)TSS GENCERT(JAMES01) DIGICERT(JIM05) -SUBJECTN('CN=JIM05 O=<strong>CA</strong> ST=NJ C=US') -NBDATE(10/01/02) NADATE(10/30/03) -NBTIME(08:00:00) NATIME(09:00:00) -KEYSIZE(1024) -LABLCERT('5TH DIGICERT FOR JIM') -ICSF -KEYUSAGE(CERTSIGN) -ALTNAME('IP=201.100.10.9 EMAIL=JAMES05@TEST.NET DOMAIN=<strong>CA</strong>.COM -URI=WWW.<strong>CA</strong>.COM')TSS LIST(JAMES01) DIGICERT(JIM05)TSS LIST(JAMES01) DATA(ALL,PASSWORD)TSS LIST(SDT) DIGICERT(ALL)/*=====================================================================*//*To Generate a Digital Certificate with keyword SIGNWITH & Remove *//* Digicert *//*=====================================================================*/TSS CREATE(GENCDIV) TYPE(DIV) NAME('GENCERT DIVISION')TSS CREATE(GENCDEPT) TYPE(DEPT) DIV(GENCDIV) -NAME('GENCERT DEPARTMENT')TSS CREATE(MARY001) NAME('GENCERT USER MARY') TYPE(USER) -PASSWORD(123,0) DEPT(GENCDEPT)TSS GENCERT(MARY001) DIGICERT(MARYCERT) –LABLCERT('SELF-SIGNED PRIVATE KEY FOR MARY')TSS LIST(MARY001) DATA(ALL,PASSWORD)TSS CREATE(TEDD001) NAME('GENCERT USER TEDD') TYPE(USER) -PASSWORD(123,0) DEPT(GENCDEPT)TSS LIST(TEDD001) DATA(ALL,PASSWORD)TSS GENCERT(TEDD001) DIGICERT(TEDCERT1) -SIGNWITH(MARY001,MARYCERT)TSS LIST(TEDD001) DATA(ALL,PASSWORD)TSS LIST(TEDD001) DIGICERT(TEDCERT1)TSS LIST(SDT) DIGICERT(ALL)TSS REMOVE(TEDD001) DIGICERT(TEDCERT1)/*=====================================================================*//*To Generate a Digital Certificate Request <strong>and</strong> write it to a data set.*//* (GENREQ) *//*=====================================================================*/TSS CREATE(GENCDIV) TYPE(DIV) NAME('GENCERT DIVISION')TSS CREATE(GENCDEPT) TYPE(DEPT) DIV(GENCDIV) -NAME('GENCERT DEPARTMENT')TSS CREATE(MARY001) NAME('GENCERT USER MARY') TYPE(USER) -PASSWORD(123,0) DEPT(GENCDEPT)TSS GENCERT(MARY001) DIGICERT(MARYCERT) –LABLCERT('SELF-SIGNED PRIVATE KEY FOR MARY')TSS LIST(MARY001) DATA(ALL,PASSWORD)TSS GENREQ(MARY001) DIGICERT(MARYCERT) -DCDSN(QAPRN.GENREQ.MARYCERT) -Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–71
Digital Certificate SupportLABLCERT('SELF-SIGNED PRIVATE KEY FOR MARY')TSS LIST(MARY001) LABLCERT('SELF-SIGNED PRIVATE KEY FOR MARY')/*=====================================================================*//*To Generate a Digital Certificate <strong>for</strong> a new acid, using the output *//* (DCDSN) from the GENREQ Statement above *//*=====================================================================*/TSS CREATE(GENCDIV) TYPE(DIV) NAME('GENCERT DIVISION')TSS CREATE(GENCDEPT) TYPE(DEPT) DIV(GENCDIV) -NAME('GENCERT DEPARTMENT')TSS CREATE(PAUL001) NAME('GENCERT USER PAUL') TYPE(USER) -PASSWORD(123,0) DEPT(GENCDEPT)TSS LIST(PAUL001) DATA(ALL,PASSWORD)TSS GENCERT(PAUL001) DIGICERT(PAULCERT) -DCDSN(QAPRN.GENREQ.MARYCERT) -LABLCERT('LABEL FOR PAUL001 W/MARY"S DCDSN') -SIGNWITH(MARY001,MARYCERT)TSS LIST(PAUL001) LABLCERT('LABEL FOR PAUL001 W/MARY"S DCDSN')TSS LIST(PAUL001) DIGICERT(PAULCERT)TSS LIST(PAUL001) SEGMENT(CERTDATA)/*========================================================================*//*To Generate a Digital Certificate <strong>for</strong> a user along with keyword SUBJECTN*//* And list the acid with different variations. *//*========================================================================*/TSS GENCERT(PAUL001) DIGICERT(PAULCT02) -SUBJECTN('CN=PAUL O=<strong>CA</strong> OU="RESEARCH AND DEVELOPMENT"')TSS LIST(PAUL001) -SERIAL(00) ISSUERDN('.CN=PAUL.OU=RESEARCH AND DEVELOPMENT.O=<strong>CA</strong>')TSS LIST(PAUL001) DIGICERT(PAULCT02)TSS LIST(PAUL001) SEGMENT(CERTDATA)TSS LIST(SDT) DIGICERT(ALL)/*=====================================================================*//*To EXPORT a Digital Certificate to an output data set NOT defined, *//* then do a CHKCERT comm<strong>and</strong> on the output DCDSN to verify that it *//* was EXPORTED. *//*=====================================================================*/TSS LIST(MARY001) DIGICERT(MARYCERT)TSS EXPORT(MARY001) DIGICERT(MARYCERT) -DCDSN(QAPRN.OUTPUT.MARYCERT)TSS CHKCERT DCDSN(QAPRN.OUTPUT.MARYCERT)TSS LIST(JAMES01) DIGICERT(JIM01)TSS EXPORT(JAMES01) DIGICERT(JIM01) -DCDSN(QAPRN.OUTPUT.JIM01) FORMAT(CERTDER)TSS CHKCERT DCDSN(QAPRN.OUTPUT.JIM01)TSS LIST(JAMES01) DIGICERT(JIM02)TSS EXPORT(JAMES01) DIGICERT(JIM02) -DCDSN(QAPRN.OUTPUT.JIM02) FORMAT(PKCS12B64) PKCSPASS(PSWDJIM2)TSS CHKCERT DCDSN(QAPRN.OUTPUT.JIM02) PKCSPASS(PSWDJIM2)TSS LIST(PAUL001) DIGICERT(PAULCT02)TSS EXPORT(PAUL001) DIGICERT(PAULCT02) -DCDSN(QAPRN.OUTPUT.PAULCT02) FORMAT(PKCS12DER) PKCSPASS(PSWDPAUL)TSS CHKCERT DCDSN(QAPRN.OUTPUT.PAULCT02) PKCSPASS(PSWDPAUL)/*=====================================================================*//* Create Digital Certificate KEYRINGS <strong>and</strong> different variations of *//* the LIST comm<strong>and</strong>. *//*=====================================================================*/TSS CREATE(GENCDEPT) TYPE(DEPT) DIV(GENCDIV) -NAME('GENCERT DEPARTMENT')TSS CREATE(MARY001) NAME('GENCERT USER MARY') TYPE(USER) -PASSWORD(123,0) DEPT(GENCDEPT)TSS GENCERT(MARY001) DIGICERT(MARYCERT) –LABLCERT('SELF-SIGNED PRIVATE KEY FOR MARY')1–72 Cookbook
Certificate Name Filtering SupportTSS LIST(MARY001) DATA(ALL,PASSWORD)TSS ADD(MARY001) KEYRING(ACCOUNTG) LABLRING(‘ACCOUNTING-DEBT’) -RINGDATA(PAUL001, PAULCT02) DEFAULT USAGE(PERSONAL)TSS ADD(MARY001) KEYRING(ACCOUNTG) LABLRING(‘ACCOUNTING-DEBT’) –RINGDATA(JAMES01, JIM02) USAGE(CERTSITE)TSS ADD(MARY001) KEYRING(PERSONEL) LABLRING(‘PERSONEL-NEW HIRES’) –RINGDATA(TEDD01, TEDCERT1) USAGE(CERTAUTH)TSS LIST(MARY001) KEYRING(ACCOUNTG)TSS LIST(MARY001) SEGMENT(ALL)TSS LIST(MARY001) DATA(ALL)TSS LIST(MARY001) SEGMENT(CERTDATA)TSS LIST(MARY001) SEGMENT(RINGDATA)TSS LIST(SDT) KEYRING(ALL)TSS LIST(SDT) DIGICERT(ALL)TSS LIST(SDT) LABLRING(‘ACCOUNTING-DEBT’)Certificate Name Filtering SupportPrior to this support level, digital certificates had to be individually defined to<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> to be associated with an acid. Certificate name filtering(CNF) support allows certificates to be associated with users without having toadd each certificate to the <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> security file. This decreases theamount of storage <strong>and</strong> the administration needed to support a large number ofcertificates.Certificate name filtering allows profiles based on the certificate subject/issuerdistinguished name to be used to select the acid to assign <strong>for</strong> a particularcertificate. Many certificates can be associated with a single acid. This supportprovides more granular access control <strong>and</strong> accountability.When a certificate name filter is defined, the in<strong>for</strong>mation is stored in aCERTMAP record in the SDT on the security file. The filter definition specifiesthe significant portion of the issuer's or subject’s distinguished name that is usedto associate an acid with a certificate. Also, additional criteria can be specified toidentify the acid to be used. <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> supports two system variables(system id <strong>and</strong> application id) that can be used to select the acid. Sites can alsodefine their own variables to be used as selection criteria. Criteria data is storedin a CRITMAP record in the SDT. CERTMAP <strong>and</strong> CRITMAP records are createdwith the TSS ADD comm<strong>and</strong>.Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–73
Certificate Name Filtering SupportTo underst<strong>and</strong> how certificate name filtering works, it is important to know afew directory concepts <strong>and</strong> to underst<strong>and</strong> the models described by the X.500st<strong>and</strong>ard. The subject’s <strong>and</strong> issuer’s distinguished names on a certificate identifythe subject’s or issuer’s location in an X.500 directory in<strong>for</strong>mation tree. Let’s lookat an example of a directory tree to help clarify this.In this X.500 directory in<strong>for</strong>mation tree, Amy’s path name would be:/O=ABC Co/OU=Sales/OU=NY/OU=Dept3/CN=AmyOr, written in the address <strong>for</strong>m used by <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>:O=ABC Co.OU=Sales.OU=NY.OU=Dept3.CN=AmyThe nodes in this tree structure show that Amy works in department Dept3 inNew York in the Sales division of the ABC Co company. A user’s location in thehierarchy determines the access to resources that they have.<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> supports this tree structure. Acids can be assigned to eachlevel at which you want to group users or they can be assigned at just one level.For example, node OU=Dept2 could be assigned to acid NYDEPT2 <strong>and</strong>OU=Dept3 could be assigned to NYDEPT3. When a user enters the system bypresenting a certificate, <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> determines which acid to assign bymatching the subject’s distinguished name to a node name.1–74 Cookbook
Certificate Name Filtering SupportIf Amy entered the system with a certificate with a subject distinguished name:O=ABC Co.OU=Sales.OU=NY.OU=Dept3.CN=Amyshe would be assigned acid NYDEPT3. If acid AMYUSR was assigned to nodeCN=Amy, she would be assigned acid AMYUSR since that is a more specificmatch. Mapping is also done using the issuer name since two different certificateauthorities can issue a certificate with the same subject name. Acid assignmentcan be based on a combination of subject name <strong>and</strong> issuer name, only a subjectname or only an issuer name. Both full path names <strong>and</strong> partial path names can bedefined. Additional criteria (such as application id or system id) can be used toselect the acid to be assigned to a certificate.Managing Certificate Name FiltersThe TSS ADD|REM|REPL|LIST comm<strong>and</strong>s are used to manage certificatename filters. The acid specified on the comm<strong>and</strong>s will identify the user to beassigned if the filter is matched. A special acid of MULTIID is used to indicatethat additional criteria is used to select the acid. The syntax of the comm<strong>and</strong>follows:TSS ADD(userid) CERTMAP(recid)SDNFILTR(subject-dist-name-filter)IDNFILTR(issuer-dist-name-filter)CRITERIA(criteria-name-template)LABLCMAP(32 byte label)DCDSN(data set name)TRUST|NOTRUSTCERTMAP—Specifies a unique 8-byte record identifier.SDNFILTR—Specifies the significant portion of the subject’s distinguished namethat is to be used as a filter when associating an acid with a certificate. The valuespecified <strong>for</strong> SDNFILTR must begin with a prefix found in the following list,followed by an equal sign (X'7E'). Each component should be separated by aperiod (X'4B'). The case, blanks, <strong>and</strong> punctuation displayed when the digitalcertificate in<strong>for</strong>mation is listed must be maintained in the SDNFILTR. Sincedigital certificates only contain characters available in the ASCII character set, thesame characters should be used <strong>for</strong> the SDNFILTR value.For example: SDNFILTR('OU=BobsAcc')Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–75
Certificate Name Filtering SupportValid prefixes <strong>for</strong> SDNFILTR <strong>and</strong> IDNFILTR are:ValuesCOUNTRY C=STATE/PROVINCELO<strong>CA</strong>LITY L=Specified asST=ORGANIZATION O=ORGANIZATIONAL UNITTITLE T=COMMON NAMEDOMAIN COMPONENTP<strong>OS</strong>TAL CODEEMAIL E=STREET NAMEUSERIDOU=CN=DC=PC=STREET=UID=IDNFILTR—Specifies the significant portion of the issuer’s distinguished namethat is to be used as a filter when associating an acid with a certificate. The valuespecified <strong>for</strong> IDNFILTR should begin with a prefix found in the list above <strong>and</strong>must be followed by an equal sign (X'7E'). Each component should be separatedby a period (X'4B'). The case, blanks, <strong>and</strong> punctuation displayed when the digitalcertificate in<strong>for</strong>mation is listed must be maintained in the IDNFILTR. Sincedigital certificates only contain characters available in the ASCII character set, thesame characters should be used <strong>for</strong> the IDNFILTR value.For example: IDNFILTR('OU=Class 1 Certificate.0=BobsCertAuth')CRITERIA—Is specified with the MULTIID acid to identify variable data inaddition to SDNFILTR <strong>and</strong> IDNFILTR. Criteria defined by <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>are CNFAPP <strong>and</strong> SYSID. Users can also define their own variables.LABLCMAP—Specifies the label to be associated with the certificate name filter.Up to 32 characters can be specified. It can contain embedded blanks <strong>and</strong>mixed-case characters, <strong>and</strong> is stripped of leading <strong>and</strong> trailing blanks. If a singlequotation is intended to be part of the label-name, you must use two singlequotation marks together <strong>for</strong> each single quotation mark within the string, <strong>and</strong>the entire string must then be enclosed within single quotation marks.1–76 Cookbook
Certificate Name Filtering SupportDCDSN—Specifies the name of a data set that contains a digital certificate. TheSDNFILTR or IDNFILTR data must match a portion of the subject/issuer’sdistinguished name extracted from the certificate. The distinguished name fromthe point of the match to the end of the name is used as the filter data.TRUST/NOTRUST—When specified it indicates whether this mapping can beused to associate a userid to a certificate presented by a user accessing thesystem. If neither TRUST nor NOTRUST is specified, the default is NOTRUST.Managing Criteria MapsWhen the acid is MULTIID <strong>and</strong> the CRITERIA keyword was specified on the TSS ADDCERTMAP comm<strong>and</strong>, criteria data must be defined in CRITMAP records to identify theacid to be associated with a certificate. The acid name on the CRITMAP record identifiesthe user when the filter that matched the certificate was <strong>for</strong> acid MULTIID. The TSSADD|REM|REPL|LIST comm<strong>and</strong>s is used to manage criteria maps. The syntax of theADD comm<strong>and</strong> follows:TSS ADD(userid) CRITMAP(recid){SYSID(system identifier)}{CNFAPP(application name)}{CNFUVAR(site variable list)}Userid—Name of the acid to be associated with this filter.CRITMAP—Unique 8-byte record identifier.SYSID—The system identifier. A maximum of 4 characters can be specified <strong>and</strong>the value can contain an asterisk (*) <strong>for</strong> masking.CNFAPP—The application variable. A maximum of 8 characters can be specified<strong>and</strong> the value can contain an asterisk (*) <strong>for</strong> masking.CNFUVAR—A list of application-defined variables that are defined asCRITERIA keyword data. This field can contain up to 255 uppercase characters.Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–77
Certificate Name Filtering SupportCreating Certificate Name Filter ScenariosExample 1Example 2Example 3The following <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> comm<strong>and</strong> examples are based on theprevious tree directory structure.Users who enter the system with a certificate subject that starts with:OU=NJ.OU=Sales.O=ABC Cowill be assigned acid NJDEPT1 if the certificate was issued by the VeriSigncertificate authority. If the subject matched but the certificate was issued byanother certificate authority then the user would be assigned acid NJDFLT.TSS ADD(NJDEPT1) CERTMAP(NJMAP1) LABLCMAP(‘NJ Dept 1 Map’) TRUSTIDNFILTR(‘OU=VeriSign Class 1 Individual Subscriber.O=VeriSign,Inc.L=Internet’) SDNFILTR(‘OU=NJ.OU=Sales.O=ABC Co’)TSS ADD(NJDFLT) CERTMAP(NJDFLT) LABLCMAP(‘NJ Default user’) TRUSTSDNFILTR(‘OU=NJ.OU=Sales.O=ABC Co’)Users who enter the system with a certificate subject that starts with:OU=Dept3.OU=NY.OU=Sales.O=ABC Cowill be assigned acid NYDEPT3.TSS ADD(NYDEPT3) CERTMAP(NYMAP3) LABLCMAP(‘NY Dept 3 Map’) TRUSTSDNFILTR(‘OU=Dept3.OU=NY.OU=Sales.O=ABC Co’)In this example we use additional criteria (in this case application id) to decidewhich acid to assign. Users in NY sales department Dept2 that h<strong>and</strong>le corporateaccounts (they use application BUSINESS to access the system) is assigned acidNYDEPT2B <strong>and</strong> users that h<strong>and</strong>le retail accounts (they use application RETAILto access the system) is assigned acid NYDEPT2R.The special acid name of MULTIID along with the CRITERIA parameter tells<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> that if the subject <strong>and</strong>/or the issuer name in<strong>for</strong>mationmatches, then search the CRITMAP records <strong>for</strong> a match on application namebe<strong>for</strong>e assigning an acid to the user.TSS ADD(MULTIID) CERTMAP(NYMAP2) LABLCMAP(‘NY Dept 2 Map’) TRUSTSDNFILTR(‘OU=Dept2.OU=NY.OU=Sales.O=ABC Co’) CRITERIA(CNFAPP=&CNFAPP)TSS ADD(NYDEPT2B) CRITMAP(NYCRIT2B) CNFAPP(BUSINESS)TSS ADD(NYDEPT2R) CRITMAP(NYCRIT2R) CNFAPP(RETAIL)1–78 Cookbook
Certificate Name Filtering SupportListing Filtering In<strong>for</strong>mationYou can list all the acids <strong>and</strong> their CERTMAPS associated with them byexecuting the following comm<strong>and</strong>:TSS LIST(SDT) CERTMAP(ALL)You can also list all the acids <strong>and</strong> their CRITMAP by executing the followingcomm<strong>and</strong>:TSS LIST(SDT) CRITMAP(ALL)You can also list the associated CERTMAP <strong>for</strong> a specific acid by executing thefollowing comm<strong>and</strong>. The comm<strong>and</strong> must contain the name of the CERTMAPalready associated with the acid.TSS LIST(USER01) CERTMAP(MAP0001)You can also list the associated SEGMENT in<strong>for</strong>mation <strong>for</strong> a specific acid byexecuting the following comm<strong>and</strong>.TSS LIST(USER01) SEGMENT(CMAPDATA)TSS LIST(USER01) SEGMENT(CRITDATA)TSS LIST(USER01) SEGMENT(ALL)You can also list the associated DIGTCERT <strong>for</strong> a specific ACID by executing thefollowing comm<strong>and</strong>. The comm<strong>and</strong> must contain the name of the DIGTCERTalready associated with the ACID.TSS LIST(USER01) DIGTCERT(CERT001)TSS LIST(USER01) KEYRING(ACCTRING)Init ACEE Changes <strong>for</strong> Search SequenceInitACEE has been changed to search through the CERTMAP records if anindividual DIGICERT record doesn’t match the incoming certificate. The firstcheck is <strong>for</strong> a match on full issuer name <strong>and</strong> a full subject name. If the first testdoes not find a match, we will take off the most specific piece of the SDN <strong>and</strong> testthe entry again. We will continue to take off pieces of the SDN until we find amatch or until we hit the end of the entry. If no match is found we will try againusing the next entry with both IDNFILTR <strong>and</strong> SDNFILTR. If no more recordsexist with both fields or there are no more matches on the IDNFILTR, we willsearch through the records with only SDNFILTR. Again, we start with the fullSDN <strong>and</strong> continue to take pieces off until we have a match or until we hit the endof the SDN. If there is no match on any of the records containing onlySDNFILTR, we look through the entries containing only IDNFILTRs. If no recordmatches the search criteria, an error code is returned. If we find a match, wemust determine what acid name should be returned. If MULTIID <strong>and</strong> CRITERIAwere not specified, then the acid name in the table is returned. If CRITERIA isavailable, we must find the CRITMAP record that matches the CRITERIAspecified.Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–79
Certificate Name Filtering SupportSearch Sequence ScenarioAssume the following records exist <strong>and</strong> all are trusted. They are listed in the order inwhich they are grouped in the search table.CERTMAP(MAP001) ACID(NJDEPT1)IDNFILTR(OU=Verisign Class 1 Individual Subscriber.O=Verisign,Inc.L=Internet)SDNFILTR(OU=DEPT1.OU=NJ.OU=Sales.O=ABC Co)CERTMAP(MAP002) ACID(NJDEPTX)IDNFILTR(O=Verisign,Inc.L=Internet) SDNFILTR(OU=Sales.O=ABC Co)CERTMAP(MAP003) ACID(NYDEPT2)SDNFILTR(OU=DEPT2.OU=NY,OU=Sales.O=ABC Co)CERTMAP(MAP004) ACID(NYDEPT3)SDNFILTR(OU=DEPT3.OU=NY,OU=Sales.O=ABC Co)CERTMAP(MAP005) ACID(ABCDEPT)SDNFILTR(OU=Sales.O=ABC Co)CERTMAP(MAP006) ACID(ABCTECH)SDNFILTR(OU=R&D.O=ABC Co)CERTMAP(MAP007) ACID(MULTIID)IDNFILTR(O=Verisign,Inc.L=Internet) CRITERIA(CNFAPP=&CNFAPP)CRITMAP(CRT001) ACID(ABCCUST)CNFAPP(ABCINET)CRITMAP(CRT002) ACID(ABCDFLT)CNFAPP(*)Assume a certificate is being presented by a user whose distinguished name is:CN=Bill,OU=Dept4,OU=PA,OU=Sales,O=ABC Co. The issuer’s distinguishedname contains in<strong>for</strong>mation about That we not VeriSign. How would we processthe search <strong>for</strong> this certificate?The first two entries don’t match, so we get to the section without an IDNF. Weloop through the SDNFs checking <strong>for</strong> a match. Then, we take off the CN from thecertificate distinguished name <strong>and</strong> compare the rest of the certificatedistinguished name against the SDNF. The sections starting with OU=Dept4 <strong>and</strong>OU=PA will not match. However, the section starting with OU=Sales willprovide a match <strong>and</strong> the ABCDEPT acid is assigned.Assume a user presents a certificate issued by VeriSign but not <strong>for</strong> ABC Co. Wewould get a match on CERTMAP MAP007, based on the IDNF in<strong>for</strong>mation. Thenwe would search the CRITMAP records <strong>for</strong> a matching CNFAPP. If the CNFAPPwas ABCINET, then acid ABCCUST would be assigned. All other applicationswould be assigned the default acid ABCDFLT.1–80 Cookbook
KerberosKerberosetrust <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> can be configured to implement Unix Systems ServicesNetwork Authentication <strong>and</strong> Privacy Service, known as Kerberos. New recordsin the SDT are defined to provide REALM definitions to describe the local <strong>and</strong><strong>for</strong>eign environments, which the local server is expected to recognize. LocalACIDs are equipped with an additional KERB segment, containing Kerberosin<strong>for</strong>mation, <strong>and</strong> are mapped <strong>for</strong> fast access in the SDT. Foreign ACIDs arelinked to local ACIDs through additional SDT definitions.In this chapter, the resource HFSSEC is used <strong>for</strong> UNIX file security. Forgenerality, if the client does not wish to employ <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> HFSSEC,the IBMFAC(SUPERUSER.) resource may be substituted in the examples below.Local Server ConfigurationInstructions <strong>for</strong> installing the Kerberos Server are provided in the z/<strong>OS</strong> NetworkAuthentication Service Administration Guide. In order to implement the KerberosServer SKRBKDC, you will need to define a region ACID <strong>for</strong> this procedure. Usethe following comm<strong>and</strong>s:TSS CREATE(SKRBKDC) NAME(‘kerb server acid’) PASS(NOPW,0)DEPT(sysdept) FACILITY(BATCH,STC,OPENMVS) SOURCE(INTRDR)The ACID will need to have a number of permissions <strong>and</strong> keywords established.Use the following comm<strong>and</strong>s:TSS ADD(SKRBKDC) UID(0) HOME(/etc/skrb/home/kdc) OMVSPGM(/bin/sh) GROUP(omvsgrp)DFLTGRP(omvsgrp)TSS PER(SKRBKDC) HFSSEC(/BIN.SH) ACC(READ,EXEC)TSS PER(SKRBDDC) HFSSEC(/ETC.SKRB) ACC(READ)Additional permissions will be needed, depending on the settings of variables inthe configuration file, /var/skrb/home/kdc/envar. Use the followingcomm<strong>and</strong>s:TSS PER(SKRBKDC) HFSSEC(nlspath) ACC(READ,EXEC)TSS PER(SKRBKDC) HFSSEC(nlslocale) ACC(READ,EXEC)The installation defaults are:nlspath: /USR.LPP.SKRB.LIB.NLS.MSG.EN_US$IBM$1047.SKRnlslocale: /USR.LIB.NLS.LO<strong>CA</strong>LE.EN_USThis will differ if you apply a different language path (NLSPATH) in theconfiguration environment.Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–81
KerberosYou will also want to be able to write to the STDOUT <strong>and</strong> STDERR files specifiedin your file. In the Kerberos configuration file, the variablesEUV_SVC_STDOUT_FILENAMEEUV_SVC_STDERR_FILENAMEwill contain the file names required. The following permissions will allow allaccess to the STDERR <strong>and</strong> STDOUT files suppled by default:TSS PER(SKRBKDC) HFSSEC(/VAR.SKRB.LOGS.) ACC(ALL)To allow the server to read <strong>and</strong> write credentials, use the following comm<strong>and</strong>s:TSS PER(SKRBKDC) HFSSEC(/VAR.SKRB.CREDS) ACC(ALL)After you have defined the ACID <strong>and</strong> provided proper access, you may add theprocedure to the STC using the following comm<strong>and</strong>:TSS ADD(STC) PROCNAME(SKRBKDC) ACID(SKRBKDC)Customizing your Local EnvironmentThe default_realm specification is also known as the “local” realm. The otherrealms defined in the configuration are known as “<strong>for</strong>eign” realms. Realms aredefined in the SDT.Users defined to Kerberos are not defined in the configuration file, but must bedefined entirely through the <strong>Security</strong> File. Users defined in the local realm areknown as “local” principals. Only local principals are allowed to initiateKerberos comm<strong>and</strong>s from the local Unix Systems Services. Users defined in a<strong>for</strong>eign realm are mapped in the SDT with a surrogate user in the local realm.We will see how the security environment must be customized to interact withKerberos.Defining Your Local RealmYou must define to the <strong>Security</strong> File the REALMs defined to your Kerberosconfiguration file./etc/skrb/krb5.confThe local realm is specified in your default_realm parameter. The local REALMis always named KERBDFLT <strong>and</strong> must be defined be<strong>for</strong>e the local principals aredefined.1–82 Cookbook
KerberosThe comm<strong>and</strong> syntax <strong>for</strong> this definition is given by:TSS ADDTO(SDT) REALM(KERBDFLT) REALMNAME(default_realm) KERBPASS(Kerberos-password)REALM—KERBDFLT (required)REALMNAME—Must be identical to configuration file default_realm.etrust <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> has simplified the REALMNAME specification. This isinternally exp<strong>and</strong>ed to the following when used <strong>for</strong> run-time security checks:/…/default_realm/krbtgt/default_realmThe REALMNAME is generally specified in the <strong>for</strong>m of a first orderweb-address. It can be a maximum of 117 characters, but cannot include spaces(x’40’) or the at-sign (x’7F’).Note: Because the relationship between the REALMNAME <strong>and</strong> generatingKerberos tickets <strong>for</strong> principal users is based, in part, on the local REALMNAME,care must be taken when choosing a REALMNAME. Renaming the REALMshould be avoided at all costs during Kerberos operations, since trust relations inflight will cause unpredictable effects.MINTKTLF—Specifies the maximum ticket life in seconds, <strong>and</strong> is representedby a numeric value between 1 <strong>and</strong> 2 147 483 647. Note that 0 is not a valid value.This keyword is only applicable when defining the KERBDFLT realm record. IfMAXTKTLF is specified, DEFTKTLF <strong>and</strong> MINTKTLF must also be specified.DEFTKTLF—Specifies the time intervals (in seconds) that a Kerberos generatedticket will remain active in the realm. If any of these intervals is specified, allmust be specified. If no intervals are specified, tickets are not limited. Validvalues <strong>for</strong> these parameters lie in the range 1 through 2**31-1 (2147483647). Asyou would expect, MAXTKTLF >= DEFTKTLF >= MINTKTLF is en<strong>for</strong>ced.KERBPASS—Specifies a 1-8 character password (alphanumeric) <strong>for</strong> the localrealm. When the same realm name is used as a <strong>for</strong>eign realm in a <strong>for</strong>eignKerberos system, the passwords must be identical. Passwords are case-sensitive<strong>and</strong> are maintained in the case in which they are entered. The KERBPASS bearsno relationship to the password of the SKRBKDC region ACID.Example:TSS ADDTO(SDT) REALM(KERBDFLT) REALMNAME(local.ca.com) MINTKTLF(30)MAXTKTLF(86400) DEFTKTLF(36000) KERBPASS(children)In the above example, the realm name is KERBDFLT, which identifies this recordas the default realm record. The Kerberos realm name is local.ca.com. Thiscorresponds to a the following fully qualified Kerberos security name which<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> will <strong>for</strong>mat automatically./…/local.ca.com/kerbtgt/local.ca.comImplementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–83
KerberosThe Kerberos password of this realm is children. The default ticket life is 10hours, a minimum ticket life of 30 seconds, <strong>and</strong> a maximum ticket life of 24hours.Defining Local PrincipalsLocal principals in Kerberos are user acids capable of activity on Unix SystemsServices, who are able to initiate Kerberos comm<strong>and</strong>s in the systemcorresponding to the local realm. Kerberos local principals clearly must possessat least the following with sufficient authority to allow access to the OMVS orISHELL shells.■■■■■UIDGROUPDFLTGRPHOMEOMVSPGMWhen a local principal is defined, the affected ACID receives a KERB segment tohold relevant in<strong>for</strong>mation, some of which will not be available <strong>for</strong> display. Acorresponding KERBSEGM record will also be defined to the SDT. The label <strong>for</strong>the KERBSEGM record is the ACID to which the new segment has been added.The administrator defines Kerberos in<strong>for</strong>mation <strong>for</strong> the user as follows:TSS ADD(acid) KERBNAME(principal_name) acid —Specifies the security ACID to be defined with Kerberos in<strong>for</strong>mation.principal_name—Specifies the Kerberos Principal Name associated with thisuser. This in<strong>for</strong>mation is added to the KERB segment of the user’s securityrecord. It is also added to the SDT KERBNAME record <strong>for</strong> high-speedcross-reference indexing. The KERBNAME specified must be unique <strong>for</strong> eachuser in the local realm. KERBNAME cannot be added to a PROFILE or GROUPACID, nor can it be added to a hierarchy ACID. The fully qualified Kerberosprincipal name is <strong>for</strong>matted from the KERBDFLT REALMNAME <strong>and</strong> theKERBNAME principal_name. The combined length cannot exceed 240characters. The principal name cannot include spaces (x’40’) or the “at” sign(x’7F’)./…/local_realm/principal_nameinterval—Specifies the maximum ticket life associated with tickets <strong>for</strong> this user.The range of available values is 1 – (2**31 – 1). Sensible values <strong>for</strong> this parametershould not exceed MAXTKTLF <strong>for</strong> the REALM, <strong>and</strong> should not be exceeded bythe REALM DEFTKTLF.1–84 Cookbook
KerberosThe following comm<strong>and</strong> creates a KERBNAME field “boris_baddenof” within anew KERB segment on “useracid” Notice that no MAXTKTLF oper<strong>and</strong> has beensupplied in this comm<strong>and</strong>.TSS ADD(useracid) KERBNAME(boris_baddenof)The KERB segment may be displayed by using the following LIST comm<strong>and</strong>:TSS LIST(useracid) SEGMENT(KERB)The corresponding KERBSEGM SDT record can be viewed with the followingcomm<strong>and</strong>:TSS LIST(SDT) KERBSEGM(useracid)Password Change Server ACIDKerberos requires the creation of a Password Change Server ACID with areserved local principal name. There is no requirement on the characteristics ofthe ACID other than that the user have local principal name kadmin/changepw.During testing we defined a USS capable user as follows:TSS CREATE(KRBCHG) DEPT(sysdept) NAME(‘KERBER<strong>OS</strong> PSWD/CHG’) PASS(pswd,0)FAC(STC,BATCH)TSS ADD(KRBCHG) UID(…)TSS ADD(KRBCHG) GROUP(OMVSGRP) DFLTGRP(OMVSGRP)TSS ADD(KRBCHG) HOME(/u/krbchg) OMVSPGM(/bin/sh)TSS PER(KRBCHG) HFSSEC(/u.krbchg) ACC(READ,UPDATE,EXEC)TSS PER(KRBCHG) HFSSEC(/BIN.SH) ACC(READ,EXEC)TSS ADD(KRBCHNG) KERBNAME(kadmin/changepw)Preparing Local Principal ACIDs <strong>for</strong> KerberosSYSEXEC changesThe following data set needs to be added to the TSO SYSEXEC DD statement ofthe Kerberos user’s TSO procedure:EUVF.SEUVFEXC.profile changesChanges are required <strong>for</strong> Kerberos user’s .profile file in their home directory.These changes may optionally be added to the /etc/.profile file. The followingdirectory must be placed as the first directory in the PATH variable, so that itoverrides DCE./usr/lpp/skrb/binImplementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–85
KerberosIt must be placed earlier in the path than the following to avoid DCE/Kerberosfrom overriding more recent Kerberos software./binAny /bin DCE subdirectoryAny Kerberos session variables which the user wishes to set differently than thevalues in the Kerberos environment file should be set in the user’s .profile file.Consult IBM SecureWay <strong>Security</strong> Server Network Authentication ServiceAdministration <strong>for</strong> complete details. If any file names are specified, theadministrator must provide appropriate HFSSEC permissions in order to accessthem.DCE IncompatibilityDCE comm<strong>and</strong>s conflict with Kerberos comm<strong>and</strong>s. Clients wishing to make useof these separate features should make changes to their environments as outlinedin IBM SecureWay <strong>Security</strong> Server Network Authentication ServiceAdministration.<strong>Security</strong> ConsiderationsA number of attributes must be present on an ACID in order to assure thecapability <strong>for</strong> the Kerberos kinit function. The assumption <strong>for</strong> examples here isthat HFSSEC(ON) has been set:■■■■■■The ACID must be given st<strong>and</strong>ard OMVS attributes:TSS ADD(local) UID(uid_number) GROUP(omvsgrp) DFLTGRP(omvsgrp)HOME(home_directory) OMVSPGM(program_directory)The ACID must be given permission to change the mode of their own files:TSS PERMIT(local) IBMFAC(BPX.<strong>CA</strong>HFS.FILE.MODE)The ACID must be able to create, alter, execute <strong>and</strong> read files in the homedirectory. Kerberos credentials will be created in this directory.TSS PERMIT(local) HFSSEC(home_directory) ACC(ALL)The ACID must be able to READ <strong>and</strong> EXECUTE files in the programdirectory.TSS PERMIT(local) HFSSEC(program_directory) ACC(READ,EXEC)To access Kerberos comm<strong>and</strong> files at run-time, the user will need thefollowing:TSS PER(useracid) HFSSEC(/usr.lpp.skrb.bin)To access Kerberos EXEC files enter the following comm<strong>and</strong>s:TSS PER(useracid) DATASET(EUVF.SEUVFEXC) ACC(READ)1–86 Cookbook
Mapping of Foreign EnvironmentsMapping of Foreign EnvironmentsCorresponding to the local (default) realm <strong>and</strong> local principal users in the localsystem are the concepts of <strong>for</strong>eign realm <strong>and</strong> <strong>for</strong>eign principal user. These<strong>for</strong>eign realm is mapped into a web address, which the Kerberos server willcontact <strong>for</strong> tickets. Foreign realms must be defined to the Kerberos configurationfile. The corresponding SDT definition defines a trust relationship between thelocal web-address <strong>and</strong> the <strong>for</strong>eign web-address. The <strong>for</strong>eign principal definitiondefines a mapping from a user <strong>and</strong> a web-address into a local ACID. Foreignprincipals are not defined in the Kerberos configuration file.Mapping Foreign RealmsYou must define any <strong>for</strong>eign REALMs to your Kerberos configuration file withthe following comm<strong>and</strong>s:/etc/skrb/krb5.confForeign realm definitions are placed after the first realm section entry (whichdefines the Kerberos local realm). While the SDT REALM <strong>for</strong> the local realm isfixed as KERBDFLT, the administrator must select an 8-character label <strong>for</strong> theREALM which identifies it to <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>. Foreign REALMNAME is alsospecified differently than <strong>for</strong> local realms, as this oper<strong>and</strong> represents a Kerberostrust relationship:/…/local_realm/krbtgt/<strong>for</strong>eign_realm/…/<strong>for</strong>eign_realm/krbtgt/local_realmNotice that the ellipsis characters (…) in this case do not represent missing data:they are part of the actual Kerberos naming syntax. Notice also that two entriesare necessary <strong>for</strong> the trust relationship, <strong>and</strong> that each entry has a differentpassword. A pair of comm<strong>and</strong>s is required to define each direction of theKerberos trust relationship at each local copy of <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>. Thefollowing is the comm<strong>and</strong> syntax:TSS ADD(SDT) REALM(realm) REALMNAME(‘/…/local_realm/krbtgt/<strong>for</strong>eign_realm’)KERBPASS(password1)TSS ADD(SDT) REALM(realm) REALMNAME(‘/…/<strong>for</strong>eign_realm/krbtgt/local_realm’)KERBPASS(password2)REALM—a realm label (1-8 characters) to identify the SDT REALM record <strong>for</strong><strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>.Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–87
Mapping of Foreign EnvironmentsREALMNAME—a fully qualified Kerberos trust relationship of the following<strong>for</strong>m:/…/local_realm/krbtgt/<strong>for</strong>eign_realm/…/<strong>for</strong>eign_realm/krbtgt/local_realmwhere the values:local_realm—represents the web-address of the local default realm in theKerberos configuration file<strong>for</strong>eign_realm—represents the web-address of the <strong>for</strong>eign realm in the Kerberosconfiguration file.KERBPASS—a password used to validate the trust relationship.Let us suppose that we wish to establish a trust relationship betweenTRUSTWORTHY.<strong>CA</strong>.COM with MAJESTERIAL.CLIENT.COM <strong>for</strong> which wewill employ the label MAJESTY in the SDT. Locally, we would define thefollowing:TSS ADD(SDT) REALM(majesty)REALMNAME(‘/…/trustworthy.ca.com/krbtgt/majesterial.client.com’)PASSWORD(xylofone)<strong>and</strong>,TSS ADD(SDT) REALM(trustyca)REALMNAME(‘/…/majesterial.client.com/krbtgt/trustworthy.ca.com’)PASSWORD(marimba)In the <strong>for</strong>eign system, a set of parallel definitions is required so that eachconnection in the conversation maintains identical passwords:TSS ADD(SDT) REALM(kingart)REALMNAME(‘/…/trustworthy.ca.com/krbtgt/majesterial.client.com’)PASSWORD(xylofone)<strong>and</strong>,TSS ADD(SDT) REALM(troubador)REALMNAME(‘/…/majesterial.client.com/krbtgt/trustworthy.ca.com’)PASSWORD(marimba)Notice that the REALM oper<strong>and</strong>s are merely labels of convenience, <strong>and</strong> do nothave to match between the two systems. However, the password <strong>for</strong> each trustrelationship must be identical <strong>for</strong> identical REALMNAME specifications.1–88 Cookbook
Mapping of Foreign EnvironmentsMapping Foreign Principal NamesForeign principal names are defined on <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> to indicate the realm fromwhich the <strong>for</strong>eign user will be mapped into a local ACID. The following <strong>for</strong>mat isused <strong>for</strong> this fully qualified reference./…/<strong>for</strong>eign_realm/<strong>for</strong>eign_principal_nameThe <strong>for</strong>eign_principal_name should be defined in the <strong>for</strong>eign_realm as a localprincipal in that system. The <strong>for</strong>eign_principal_name need not be identical withits associated ACID in the <strong>for</strong>eign system.The local ACID need not be defined as a Kerberos local principal. It serves as asurrogate <strong>for</strong> security activities by the <strong>for</strong>eign principal in the local environment.The KERBLINK label provides a convenient reference in the SDT to identify therelationship. The comm<strong>and</strong> to link these entities is given below:TSS ADD(SDT) KERBLINK(kerblink)LINKNAME(‘/…/<strong>for</strong>eign_realm/<strong>for</strong>eign_principal_name’) KERBUSER(surrogat)KERBLINK—1-8 character label <strong>for</strong> the SDT record identifying the <strong>for</strong>eignprincipal relationshipLINKNAME—a fully qualified <strong>for</strong>eign principal name. The<strong>for</strong>eign_principal_name must be defined as a local_principal_name in the <strong>for</strong>eignsystem.KERBUSER—a local ACID defined to <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>. This ACID need not existat the time that the SDT record is defined. When the <strong>for</strong>eign principal attempts toinitiate a session with the local realm, however, the ACID must be defined or anerror will result.Suppose that two <strong>for</strong>eign realms have been defined,MAJESTERIAL.CLIENT.COM <strong>and</strong> COLL<strong>OS</strong>SAL.SUCCESS.COM <strong>and</strong> we wish toestablish trust relationships locally <strong>for</strong> Kerberos principals king5 in the firstrealm, using the following comm<strong>and</strong>:TSS ADD(lscess1) KERBNAME(king5)major_major_majorIn the second realm, using the following comm<strong>and</strong>:TSS ADD(lclint1) KERBNAME(major_major_major).On the second realm, where king5 is <strong>for</strong>eign defines a <strong>for</strong>eign principal “king5”from the originating <strong>for</strong>eign realm MAJESTERIAL.CLIENT.COM <strong>and</strong> associatesthat principal locally with ACID “client1” in the local TSS.TSS ADD(SDT) KERBLINK(kclint1) LINKNAME(‘/…/majesterial.client.com/king5’)KERBUSER(client1)Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–89
DCE SupportSimilarly, on the first realm where major_major_major is <strong>for</strong>eign, defines a<strong>for</strong>eign principal “major_major_major” originating fromCOLL<strong>OS</strong>SAL.SUCCESS.COM, <strong>and</strong> associates that principal locally with ACID“succes1” in the local TSS.TSS ADD(SDT) KERBLINK(kscess1)LINKNAME(‘/…/collossal.success.com/major_major_major’)KERBUSER(succes1)DCE SupportSee the <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> User Guide <strong>for</strong> in<strong>for</strong>mation concerning DCEsupport.Distributed File Service (DFS)The Distributed File Service (DFS) allows users to access <strong>and</strong> share files stored ona file server anywhere on the network without knowing the physical location ofthe file. Files are part of a single namespace. There<strong>for</strong>e, no matter where in thenetwork a user is, the file can be found using the same name. <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong><strong>Secret</strong> definitions are required <strong>for</strong> the DFS Server (DFS) <strong>and</strong> the DFS Client(DFSCM). Execute the following <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> comm<strong>and</strong>s.TSS CREATE(DFSGRP) TYPE(GROUP) NAME('DFS GROUP') DEPT(dept)TSS CREATE(DFS) TYPE(USER) PASS(PASSWORD,0) NAME('DFS region acid') DEPT(dept)TSS ADD(DFSGRP) GID(2)TSS ADD(DFS) UID(0) HOME(/opt/dfslocal/home/dfscntl) DFLTGRP(DFSGRP)GROUP(DFSGRP)TSS ADD(STC) PROCN(DFS) ACID(DFS)TSS ADD(STC) PROCN(DFSCM) ACID(DFS1–90 Cookbook
Distributed File Server SMB SUPPORTDistributed File Server SMB SUPPORTDistributed File Server (DFS) SMB support provides a server that makes the HFSfile available to SMB clients. Server Message Block (SMB) is a protocol <strong>for</strong> remotefile/print access used by Windows <strong>and</strong> <strong>OS</strong>/2 clients. The following steps mustbe taken to use this support:1. Define a facility <strong>for</strong> DFS in the TSS control file. Add the definition byrenaming a USERxx facility entry:FAC(USERXX=NAME=DFS)FAC(DFS=PGM=DFSCNTL)FAC(DFS=NOTSOC,RES,NOIJU,AUTHINIT)2. Create the region acid <strong>for</strong> DFS:TSS CRE(DFS) NAME(‘DFS REGION ACID’) FAC(BATCH,STC) PASS(XXXXXXXX)DEPT(XXXX) MASTFAC(DFS) NORESCHK NODSNCHK3. Define the DFS procedure to <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>:TSS ADD(STC) PROCN(DFS procname) ACID(DFS)4. Define the DFSKERN procedure to <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>:TSS ADD(STC) PROCN(DFS kern procname) ACID(DFS)SMB ENCRYPTED PASSWORD SUPPORTWith z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390, to have the SMB server use the encrypted passwordprocessing, you must add the entry DCE.PASSWORD.KEY to the SDTKEYSMSTR record. The syntax of the comm<strong>and</strong> is as follows:TSS ADD(SDT) KEYSMSTR(DCE.PASSWORD.KEY) DCENCRY(KKKKKKKK)KEYMASK | KEYNCRYKEYSMSTR—this attribute has only one value, which is DCE.PASSWORD.KEY,which must be entered in uppercase characters.DCENCRY—this value is a 16-character hexadecimal encryption keyKEYMASK—this value indicates that the DCENCRY key is used to mask theuser’s DCE password when it is stored in the DCEKEY field of the user’s acidrecord. KEYMASK is the defaultKEYENCRY—this value indicates that the DCENCRY key is used to encrypt theuser’s DCE password when it is stored in the user’s acid recordNote: Only the MS<strong>CA</strong> can specify the KEYSMSTR keyword.Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–91
NFS (Network File System)Define the string c1c2c3c4c5c6c7cc8 as the encryption key value <strong>for</strong> SMBpassword support:TSS ADD(SDT) KEYSMSTR(DCE.PASSWORD.KEY) DCENCRY(C1C2C3C4C5C6C7C8)To delete the KEYSMSTR record <strong>for</strong> the SDT:TSS DEL(SDT) KEYSMSTR(DCE.PASSWORD.KEY)To replace the encryption key <strong>and</strong> use the DES encryption to mask:TSS REP(SDT) KEYSMSTR(DCE.PASSWORD.KEY) DCENCRY(0123456701234567)To list the current encryption value:TSS LIST(SDT) KEYSMSTR(DCE.PASSWORD.KEY)Important: To use the DFS SMB support <strong>and</strong> the SMB Encrypted Password Supportyou must be running <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> 5.1, genlevel SP04 or <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>5.2, genlevel SP01 with maintenance as required.NFS (Network File System)z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 NFS enables remote access to z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 data sets <strong>and</strong>UNIX System Services HFS files <strong>and</strong> directories. NFS provides the ability toprotect file systems on MVS through four protection schemes. This setting isdefined within the NFS 'Site Attributes' attribute '<strong>Security</strong>'.Four possible SECURITY settings include:NONE Do restrict access No MVS userID requiredEXPORTS Restrict access by client IP address No SAF checkSAFSAFEXPUse SAF to control access to datasetsUse SAF <strong>and</strong> EXPORTS to controlaccessSAF check executedSAF check (most secure)Both SAF <strong>and</strong> SAFEXP require the user to use the 'mvslogin' process to validateaccess through a SAF call. For this reason we recommend a minimum of security(SAF). Users who attempt to access HFS data must have a valid OMVS segmentassigned to their MVS acid. Access to HFS files will then be done by validatingthe client's UID <strong>and</strong> group against the file UNIX permission bits. Under normalcircumstances access to MVS data sets requires both the z/<strong>OS</strong> or <strong>OS</strong>/390 NFSserver <strong>and</strong> client user to pass a security check <strong>for</strong> the resource. The exception tothis is when 'DataCaching' is enabled. DataCaching causes data to be stored onthe z/<strong>OS</strong> or <strong>OS</strong>/390 NFS client system.1–92 Cookbook
NFS (Network File System)The first user attempting to access an MVS data set must pass a SAF securitycheck. This SAF call is issued by the z/<strong>OS</strong> or <strong>OS</strong>/390 NFS Server. Once passed,the data set is stored in the z/<strong>OS</strong> or <strong>OS</strong>/390 NFS Client server. Subsequentrequests will allow all users access to the cached data without furtherrestrictions. Data caching by default is enabled. <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>recommends 'DataCaching' be disabled. With DataCaching(N) no client datacaching takes place, there<strong>for</strong>e each user must pass the z/<strong>OS</strong> or <strong>OS</strong>/390 NFS<strong>Security</strong> server check prior to being granted access to data. z/<strong>OS</strong> or <strong>OS</strong>/390 NFSServer 'Site Attribute' 'checklist' lists the files <strong>and</strong> or directories <strong>for</strong> which SAFsecurity is bypassed even when SAF or SAFEXP is specified. For this reasonproper care must be taken to secure this data set. The checklist data set is definedby the CHKLIST DD in the MVSNFS procedure.<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> Support <strong>for</strong> z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 NFSTo define a facility enter the following syntax:FAC(USERxx=NAME=NFS)To create acids <strong>for</strong> started task, create an acid <strong>for</strong> each of the four proceduresused by:NFS (MVSNFS, MVSNFSC, MVSSTATD, MVSLOCKD).These acids require an OMVS segment having UID(0). The NFS Server <strong>and</strong>Client acids require access to data sets to which the remote user accesses. Thiscan be accomplished by explicitly permitting the desired data sets or by addingthe NODSNCHK bypass attribute.z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 NFS ServerTSS CREATE(MVSNFS) NAME('NFS SERVER') DEPT(dept)TYPE(USER) PASS(password,0) FAC(STC)TSS ADD(MVSNFS) UID(0) GROUP(OMVSGRP) DFLTGRP(OMVSGRP)TSS ADD(MVSNFS) NODSNCHK **or per all required data sets**TSS ADD(MVSNFS) MASTFAC(NFS)TSS ADD(MVSNFS) SOURCE(INTRDR)z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 NFS ClientTSS CREATE(MVSNFSC) NAME('NFS CLIENT') DEPT(dept)TYPE(USER) PASS(password,0) FAC(STC)TSS ADD(MVSNFSC) UID(0) GROUP(OMVSGRP) DFLTGRP(OMVSGRP)TSS ADD(MVSNFSC) NODSNCHK **or per all required data sets**TSS ADD(MVSNFSC) MASTFAC(NFS)TSS ADD(MVSNFSC) SOURCE(INTRDR)z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 NFS NLM (Network Lock Manager)TSS CREATE(MVSNLM) NAME('NFS NLM') DEPT(dept)TYPE(USER) PASS(password,0) FAC(STC)TSS ADD(MVSNLM) NODSNCHK **or per all required data sets**TSS ADD(MVSNLM) UID(0) GROUP(OMVSGRP) DFLTGRP(OMVSGRP)TSS PER(MVSNLM) DSN( per all required data sets )TSS ADD(MVSNLM) SOURCE(INTRDR)Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–93
WLM (Workload Management)<strong>OS</strong>/390 NFS NSM (Network Status Monitor)TSS CREATE(MVSNSM) NAME('NFS NSM') DEPT(dept)TYPE(USER) PASS(password,0) FAC(STC)TSS ADD(MVSNSM) NODSNCHK **or per all required data sets**TSS ADD(MVSNSM) UID(0) GROUP(OMVSGRP) DFLTGRP(OMVSGRP)TSS PER(MVSNSM) DSN( per all required data sets )TSS ADD(MVSNSM) SOURCE(INTRDR)Add Procedures to STC acidTSS ADD(STC) PROCN(MVSNFS) ACID(MVSNFS)TSS ADD(STC) PROCN(MVSLOCKD) ACID(MVSNLM)TSS ADD(STC) PROCN(MVSSTATD) ACID(MVSNSM)TSS ADD(STC) PROCN(MVSNFSC) ACID(MVSNFSC)WLM (Workload Management)The WLM ISPF application is protected by a SAF call. Access to the WLM ISPFapplication is controlled through the definition of a facility class in <strong>eTrust</strong><strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>. READ or UPDATE access to the entire WLM service definition isthe only option available through the <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> facility accessauthorization. READ access allows users access to all functions except installing<strong>and</strong> activating a service definition or policy.Specify an access of NONE <strong>for</strong> the facility resource. Also, limit the number ofusers authorized to read <strong>and</strong> update the WLM application to those who maintainthe WLM policy, to per<strong>for</strong>mance personnel, or to both. Review the requirement<strong>for</strong> operations to have access to install a service definition versus activating anexisting policy.To authorize the facility <strong>for</strong> WLM, execute the following <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>comm<strong>and</strong>s:TSS ADD(deptacid) IBMFAC(MVSADMIN)—Skip this comm<strong>and</strong> if already ownedTSS PER(aicd) IBMFAC(MVSADMIN.WLM.POLICY) ACC(READ)orTSS PER(acid) IBMFAC(MVSADMIN.WLM.POLICY) ACC(UPDATE)z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 <strong>Security</strong> Server SupportIBM markets the <strong>Security</strong> Server as a separate offering, along with z/<strong>OS</strong> <strong>and</strong><strong>OS</strong>/390. This offering is a bundling of RACF with a number of other products.All of these products per<strong>for</strong>m some security (SAF) function. Those that interfacewith RACF, do so through st<strong>and</strong>ard security calls, supported by <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong><strong>Secret</strong>. None are truly dependent on RACF to function. The followingcomponents make up the <strong>Security</strong> Server.1–94 Cookbook
z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 <strong>Security</strong> Server SupportRACFAlthough delivered as part of the <strong>Security</strong> Server, RACF must be independentlyactivated, <strong>and</strong> is not required to run the other <strong>Security</strong> Server components. RACFis IBM’s SAF compliant security system. It is mainly concerned with system entryvalidation <strong>and</strong> resource permission. It provides no subsystem specific extensionsto secure such things as partitioned data sets, CICS <strong>and</strong> IMS. Typically, in RACFphilosophy, these sorts of extensions are available as user maintained exit points.Its reporting <strong>and</strong> administration capabilities are limited, typically these functionsmust be supplemented by buying additional third party products.To disable RACF, update the appropriate IFAPRDxx member <strong>and</strong> change the STATEfield to:STATE(DISABLED)Then re-IPL the system to make the change take effect.For example, if you ordered RACF as part of the security server <strong>for</strong> z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390,<strong>and</strong> you want to disable the security server, update the IFAPRDxx entry to look like this:PRODUCT OWNER('IBM CORP')NAME('z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390')FEATURENAME('<strong>Security</strong> Server')ID(5647-A01)VERSION(*)RELEASE(*)MOD(*)STATE(DISABLED)If you ordered RACF as part of the security server <strong>for</strong> z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390, <strong>and</strong> want todisable the RACF component of the security server but continue to use the DCEcomponent of the security server, update the IFAPRDxx entries to look like this:PRODUCT OWNER('IBM CORP')NAME('z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390')FEATURENAME('<strong>Security</strong> Server')ID(5647-A01)VERSION(*)RELEASE(*)MOD(*)STATE(ENABLED)PRODUCT OWNER('IBM CORP')NAME('z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390')FEATURENAME('RACF')ID(5647-A01)VERSION(*)RELEASE(*)MOD(*)STATE(DISABLED)Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–95
z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 <strong>Security</strong> Server SupportDCE <strong>Security</strong> ServerThe DCE <strong>Security</strong> Server is a separate security product that providesauthentication services <strong>for</strong> users <strong>and</strong> servers running DCE applications.In a DCE environment, one DCE <strong>Security</strong> Server must exist. A DCE securityserver provides a central hub <strong>for</strong> system entry validation <strong>and</strong> single-sign onauthentication <strong>for</strong> all DCE plat<strong>for</strong>ms within a connected DCE environment. Akey concept of a DCE security server is that it provides an independent orso-called third-party plat<strong>for</strong>m in which to validate <strong>and</strong> authenticate securityrequests. This concept provides obvious security advantages.For example, when a user passes from one DCE plat<strong>for</strong>m to another, the targetplat<strong>for</strong>m passes in<strong>for</strong>mation about the user (so-called user credentials) alongwith other in<strong>for</strong>mation to the DCE security server <strong>for</strong> authentication <strong>and</strong>authorization. The DCE security server authenticates such requests by checkingthe supplied user credentials against those stored in the DCE security server'ssecurity repository <strong>and</strong>/or security registry. In per<strong>for</strong>ming this authentication,the DCE security server follows an authentication algorithm, which involves notonly the user credentials but also involves encryption keys known <strong>for</strong> eachplat<strong>for</strong>m. The algorithm is st<strong>and</strong>ards-based <strong>and</strong> is plat<strong>for</strong>m independent. As aresult, multiple vendors <strong>and</strong> plat<strong>for</strong>ms offer a DCE security server.IBM's z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 OE/DCE <strong>Security</strong> Server product allows an IBMmainframe to per<strong>for</strong>m these functions.With z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 O/E DCE security server, <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> isutilized mainly to act as a repository <strong>for</strong> in<strong>for</strong>mation needed to support the DCEauthentication process. In particular, the <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> is used to holdDCE-specific userid in<strong>for</strong>mation <strong>and</strong> encryption keys. Most notably, a 'DCEsegment' can now be defined <strong>for</strong> any userid. The DCE userid segment allows sixDCE-specific fields to be maintained <strong>for</strong> any userid. For example, one fieldnamed DCEKEY identifies each user's DCE password. During authentication, theDCE security server retrieves this <strong>and</strong> other in<strong>for</strong>mation from <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong><strong>Secret</strong> following <strong>for</strong>mal SAF interfaces. This in<strong>for</strong>mation is then used separatelyto authenticate <strong>and</strong> authorize the DCE security server request. As stated, <strong>eTrust</strong><strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> acts mainly as a repository <strong>for</strong> DCE in<strong>for</strong>mation.<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> provides <strong>for</strong> the following functions:■■■■support <strong>for</strong> the DCE segment <strong>for</strong> any userid;support <strong>for</strong> the KEYSMSTR resource class used to hold keys <strong>for</strong> DCEpassword encryption;support <strong>for</strong> the DCEUUIDS resclass used to track the correspondencebetween z/<strong>OS</strong> or <strong>OS</strong>/390 userids <strong>and</strong> DCE UIDs;support <strong>for</strong> four new callable services used to exchange in<strong>for</strong>mation betweenthe ESM <strong>and</strong> the DCE security server.1–96 Cookbook
z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 <strong>Security</strong> Server SupportThe following steps must be taken into consideration when protecting the DCEsecurity server under <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>:1. A DCE segment, allowing specification of six DCE-related fields, can beadded to any <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> defined user. An example of the use ofthese new fields follows:TSS ADD(acid) DCENAME(jordanm) DCEFLAGS(AUTOLOGIN)UUID(00000075-71db-21cf-b500-08005a470ba1)HOMEUUID(abbc323c-5ce2-11cf-a61e-08005a470ba1)HOMECELL(/.../cis_test1.cis.dog.com)2. <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> further extends this support by installing anISPFEDIT-macro named TSSDCE which can be used to re<strong>for</strong>mat the outputof the IBM DCE export utility, MVSEXPT, to TSS <strong>for</strong>mat. To per<strong>for</strong>m thisre<strong>for</strong>mat, edit the MVSEXPT output data set using ISPF edit <strong>and</strong> enter theTSO comm<strong>and</strong> %TSSDCE. This will immediately re<strong>for</strong>mat the MVSEXPToutput data set being edited into TSS comm<strong>and</strong> <strong>for</strong>mat.3. Consult IBM DCE documentation <strong>for</strong> the <strong>OS</strong>390 OE/DCE security server <strong>for</strong>more in<strong>for</strong>mation about the use <strong>and</strong> settings of these fields.Firewall Technologiesz/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 provides the ability to run a firewall under UNIX SystemServices. Support is distributed in part with the Communication Server <strong>and</strong> inpart with the <strong>Security</strong> Server. The z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 Firewall Technologies canonly reduce, but does not necessarily eliminate the need <strong>for</strong> a non-z/<strong>OS</strong> <strong>and</strong><strong>OS</strong>/390 plat<strong>for</strong>m firewall. The firewall itself is not configured using <strong>eTrust</strong><strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>. Administration is per<strong>for</strong>med through configuration files.Setting up the z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 Firewall Technologies with <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong><strong>Secret</strong> involves the following steps:1. Create a group definition <strong>for</strong> use with the firewall:TSS CREATE (FWGRP) TYPE(GROUP) NAME(‘Firewall Group’) DEPT(OMVSDEPT)TSS ADD(FWGRP) GID(nn)Any unused GID number is allowed.2. Define the Firewall startup address space ID:TSS CREATE(FWKERN) TYPE(USER) NAME(‘Firewall Startup ID’)DEPT(OMVSDEPT) FACILITY(STC,BATCH) PASS(password,0)TSS ADD(FWKERN) GROUP(FWGRP) DFLTGRP(FWGRP)HOME(/usr/lpp/fw/home/fwkern/) OMVSPGM(/bin/sh) UID(0)TSS ADD(STC) PROCNAME(FWKERN) ACID(FWKERN)TSS MODIFY(OMVSTABS)3. Allow FWKERN to issue start comm<strong>and</strong>s:TSS ADD(anydept) IBMFAC(FWKERN.)TSS PERMIT(FWKERN) IBMFAC(FWKERN.START.REQUEST) ACCESS(UPDATE)Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–97
z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 <strong>Security</strong> Server Support4. Define additional started tasks used by the firewall daemons:TSS ADD(STC) PROCNAME(I<strong>CA</strong>PSLOG) ACID(FWKERN)TSS ADD(STC) PROCNAME(I<strong>CA</strong>PSOCK) ACID(FWKERN)TSS ADD(STC) PROCNAME(I<strong>CA</strong>PPFTP) ACID(FWKERN)TSS ADD(STC) PROCNAME(I<strong>CA</strong>PFLOG) ACID(FWKERN)TSS ADD(STC) PROCNAME(I<strong>CA</strong>PTNAT) ACID(FWKERN)5. Permit FWKERN access to READ the TCP/IP data sets:TSS PERMIT(FWKERN) DSN(TCPIP.*) ACCESS(READ)The high level qualifier of these data sets might have been renamed from“TCPIP” when installed on your system.6. Permit the FWKERN acid to the SMF logging facility:TSS PERMIT(FWKERN) IBMFAC(BPX.SMF) ACCESS(READ)7. Permit the PFTP server to the BPX.DAEMON facility:TSS PERMIT(FWKERN) IBMFAC(BPX.DAEMON) ACCESS(READ)8. Adding Firewall Administrators to FWGRP:Firewall administrators must be members of the group FWGRP or havesuperuser authority. The following comm<strong>and</strong> gives an administrator thefirewall group:TSS ADD(administrator) GROUP(FWGRP)9. Firewall Technologies has the ability to invoke z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 IntegratedCryptographic facilities to per<strong>for</strong>m internal security functions. These servicesare protected using the resource class CSFSERV. Users must be permitted tothe individual services necessary. This is accomplished using the followingcomm<strong>and</strong>s:TSS ADD(dept) CSFSERV(service-name)TSS PERMIT(acid) CSFSERV(service-name) ACCESS(READ)The individual service-names are documented in the appropriate IBMFirewall manuals <strong>and</strong> the ICSF/MVS Administrators Guide.LDAP ServerIBM provides a Lightweight Directory Access Protocol (LDAP) Server with z/<strong>OS</strong><strong>and</strong> <strong>OS</strong>/390 releases 2.5 <strong>and</strong> above. This server can be used to store directoryin<strong>for</strong>mation, such as email accounts. The LDAP server uses a DB2-based file tostore directory in<strong>for</strong>mation.1–98 Cookbook
z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 <strong>Security</strong> Server SupportSetting up the z/<strong>OS</strong> or <strong>OS</strong>/390 LDAP Server with <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> involvesthe following steps:1. Create a group definition <strong>for</strong> use with the LDAP Server:TSS CREATE (LDAPGRP) TYPE(GROUP) NAME(‘LDAP Group’) DEPT(OMVSDEPT)TSS ADD(LDAPGRP) GID(nn)Any unused GID number is allowed.2. Define the LDAP Server startup address space identifier:TSS CREATE(LDAPSRV) TYPE(USER) NAME(‘LDAP Startup ID’)DEPT(OMVSDEPT) FACILITY(STC,BATCH) PASS(password,0)TSS ADD(LDAPSRV) GROUP(LDAPGRP) DFLTGRP(LDAPGRP)HOME(/) OMVSPGM(/bin/sh) UID(0)TSS ADD(STC) PROCNAME(LDAPSRV) ACID(LDAPSRV)TSS MODIFY(OMVSTABS)3. The acid <strong>for</strong> the LDAP server started task requires access to the followingIBMFAC resources:TSS ADD(anydept) IBMFAC(BPX.)TSS PERMIT(LDAPSRV) IBMFAC(BPX.DAEMON)TSS PERMIT(LDAPSRV) IBMFAC(BPX.SERVER)ACCESS(READ)ACCESS(UPDATE)DB2 <strong>Security</strong> ExitIn response to the fact that native DB2 only provides internal security, thesecurity server now provides sample code <strong>for</strong> a DB2 security exit. <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong><strong>Secret</strong> has offered <strong>for</strong> a number of years the ability to secure DB2 using <strong>eTrust</strong><strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> <strong>for</strong> DB2. See the <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> <strong>for</strong> DB2 ImplementationGuide <strong>for</strong> additional in<strong>for</strong>mation.Integrated Cryptographic ServicesIBM has delivered as a hardware offering, a high powered cryptographiccoprocessor which allows z/<strong>OS</strong> or <strong>OS</strong>/390 applications to exploit cryptography.The z/<strong>OS</strong> or <strong>OS</strong>/390 <strong>Security</strong> Server provides API’s to invoke thesecryptographic services (ICSF) rather than use software algorithms to per<strong>for</strong>m thesame functions. In addition, various functions involved with the management ofkeys are provided in this service. These services combine to provide a site withthe ability to manage public keys.<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> provides the following resource classes to allow ICSF to besecured <strong>and</strong> audited.CSFKEYS—This class is used to secure encryption keys. The value, which isowned <strong>and</strong> permitted, is the key label. The key label is in the CKDS or PKDSwhen a key is defined.Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–99
z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 <strong>Security</strong> Server SupportIf CFSKEYS is defined to support masking <strong>and</strong> you want to allow ALL access,CFSKEYS(**) must be used. This allows the correct entity to be picked up. If thisis not done <strong>and</strong> an audit record is cut the resource name will be blank.CSFSERV—This class is used to secure the various cryptographic services,needed to encrypt data <strong>and</strong> manage keys. The services are listed in the <strong>OS</strong>/390Integrated Cryptographic Service Facility: Administrator’s Guide.Note: If the certificate’s private key resides in an ICSF storage facility <strong>and</strong> the<strong>for</strong>mat of PKCS12DER or PKCS12B64 is specified in the TSS EXPORT comm<strong>and</strong>,the comm<strong>and</strong> is rejected. A TSS0533E message is issued.Also, in order to use ICSF, you must have cyptrographic hardware installed <strong>and</strong>enabled on your system. ICSF is the interface to the Cryptographic hardware onz/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390.1–100 Cookbook
Chapter2Controlling Access to theHierarchical File SystemThere are two methods a site can use to secure the Hierarchical File System(HFS).■■The first process is internal to UNIX System Services <strong>and</strong> is based on theUNIX model of security.The second process is external security <strong>and</strong> uses st<strong>and</strong>ard <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong><strong>Secret</strong> security authorizations to secure HFS.Note: These methods are mutually exclusive, you must select one.Controlling HFS Using the Native UNIX <strong>Security</strong> ModelThe Hierarchical File System (HFS) is a tree-structured file system consisting ofdirectories <strong>and</strong> files. It resembles the D<strong>OS</strong> file system, although the slash (/) isused instead of the backslash (\).Each file <strong>and</strong> directory is assigned an owning UID <strong>and</strong> an owning GID. Theassignment is defined <strong>and</strong> saved in the file system, not in the external securityproduct.Three categories of users can access each directory <strong>and</strong> file in the HFS:■■■File ownerGroup that owns the fileAll other users defined to UNIX System ServicesDifferent access levels can be set <strong>for</strong> any of these three categories. For example,permissions can be defined so that the file owner gets READ <strong>and</strong> WRITE access,a member of the file's group gets only READ access, <strong>and</strong> all other users haveneither READ nor WRITE access to the file.Controlling Access to the Hierarchical File System 2–1
Controlling HFS Using the Native UNIX <strong>Security</strong> ModelWhen group access checks are per<strong>for</strong>med, <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> compares theGID of the file to the GID of the default group defined in DFLTGRP. If thesedon’t match, <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> then compares the file's GID to the GIDs of allof the groups defined to the acid in the GROUP field. GIDs are added to theGROUP by issuing the following <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> comm<strong>and</strong>:TSS ADD('acidname') GROUP('group name')If a match is found, <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> uses group permissions to determinethe user's access to the file.Obtaining security in<strong>for</strong>mation <strong>for</strong> a File within OpenEdition can be achieved byone of the following:■■■Use the OpenMVS ISPF ShellEnter the ls -l or ls -E shell comm<strong>and</strong>Run a stat( ) or fstat( ) function in a programIn response, the system will display the TSO/E user ID <strong>and</strong> the <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong><strong>Secret</strong> group name that correspond to the file’s UID <strong>and</strong> GID permission bits.The system displays the UID <strong>and</strong> GID only if it cannot find the correspondingTSO/E user ID <strong>and</strong> <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> group name. The in<strong>for</strong>mationreturned will include:■■■■Type of file or directoryOwner permission bitsGroup permission bitsOther permission bitsShell comm<strong>and</strong>s exist that change file/directory authorizations within the openedition arena. These shell comm<strong>and</strong>s include:CHMOD—Change permission bits <strong>for</strong> a file/directory.CHOWN—Change the owner or group <strong>for</strong> a file or directory.CHGRP—Change the group of a file.For more in<strong>for</strong>mation about the Hierarchical File System <strong>and</strong> setting filepermissions, see these IBM documents: <strong>OS</strong>/390 OpenEdition User's Guide <strong>and</strong><strong>OS</strong>/390 OpenEdition Planning.2–2 Cookbook
Controlling HFS Using the Native UNIX <strong>Security</strong> ModelProcesses that Affect HFS <strong>Security</strong>When using the UNIX security model, various options can affect the filevalidation process. The processes <strong>and</strong> their effect on file security or validationare described in this section.HFS FASTPATH CheckingAs of <strong>OS</strong>/390 V2R7, OMVS issues a SAF call at initialization. This SAF callchecks to see if access is authorized <strong>for</strong> OMVS to the FACILITY class resourceBPX.SAFFASTPATH. If access is allowed, OMVS per<strong>for</strong>ms permission bitchecking internally instead of calling the external security manager bypassingany audit trail of violations. This is referred to as FASTAUTH processing.Issue the following <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> comm<strong>and</strong>s to eliminate this bypass:TSS ADDTO(anydept) IBMFAC(BPX.SAFF)TSS PERMIT(ALL) IBMFAC(BPX.SAFF) ACCESS(NONE)Also, do not give the STC acid associated with the OMVS started task theNORESCHK attribute.MOUNT N<strong>OS</strong>ECURITYWith <strong>OS</strong>/390 V2R7, you now have the option to MOUNT a file system or part ofa file system with or without SECURITY. The use of the MOUNT comm<strong>and</strong>requires superuser authority. If the file system is mounted with theN<strong>OS</strong>ECURITY option, USS makes access checks against system credentials (i.e.,superuser) rather that against user credentials. Access is allowed.Program Control in the UNIX EnvironmentWhen the BPX.DAEMON <strong>and</strong> BPX.SERVER facilities are active, processingauthorized functions, such as SETUID, requires that programs or executables beloaded from an authorized library. In a <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> environment,these authorized data sets are any library in the LPA list, the APF list, orLINKLIST. If a program is loaded from the HFS or an MVS data set not on theapproved lists, the TCBNCTL flag, referred to as the “dirty bit,” is set. Thisresults in authorized functions failing if attempted in the “dirty” environment.When an executable or program is requested in an OMVS environment, OMVSfinds the executable in the HFS <strong>and</strong> loads from there unless the programcontrolled extended attribute, or “sticky bit,” is set. If this sticky bit is set on theexecutable file, OMVS uses normal MVS load processing. To avoid the dirty bitbeing set requires that the executables in the HFS have the sticky bit turned onusing the chmod comm<strong>and</strong>.Controlling Access to the Hierarchical File System 2–3
Controlling HFS Using <strong>CA</strong> SAF HFS <strong>Security</strong>Controlling HFS Using <strong>CA</strong> SAF HFS <strong>Security</strong><strong>OS</strong>/390 brings the MVS <strong>and</strong> UNIX operating systems together onto onehardware plat<strong>for</strong>m. Although some interoperability between MVS <strong>and</strong> UNIXexist, each environment retains its own distinct data structures <strong>and</strong> methods ofaccess control.UNIX data is kept in a Hierarchical File System (HFS). From the UNIXperspective, the HFS contains many discrete data files. From the MVSperspective, the HFS is one data set <strong>and</strong> can only be controlled as one data set. Inother words, MVS can control access to the entire file system, but not to theindividual files within the HFS.HFS files are protected by file permission bit settings. These are set when the fileowner creates the file. A superuser, a user privilege that grants much moreauthority than just security administration, can only per<strong>for</strong>m centralizedadministration. MVS resources are protected by resource access that can be setup in advance by scoped security administrators.<strong>CA</strong> SAF HFS security overcomes the shortcomings of native UNIX security byproviding single-point security access control, administration, <strong>and</strong> reporting <strong>for</strong>both MVS <strong>and</strong> UNIX resources. <strong>CA</strong>IENF services present access events to <strong>eTrust</strong><strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> <strong>for</strong> validation. Administrators use familiar comm<strong>and</strong>s <strong>and</strong> rulesto protect UNIX files <strong>and</strong> functions, restricting access based on the <strong>eTrust</strong><strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> acid permissions instead of the UNIX UID or GID numbers. HFSaccess loggings <strong>and</strong> violations are reported in the st<strong>and</strong>ard <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>reports.The following sections explain:■■■HFS file access security using resource authorizationsSecuring HFS system <strong>and</strong> file functionsImplementing <strong>CA</strong> SAF HFS security<strong>CA</strong> SAF File Access <strong>Security</strong>When using <strong>CA</strong> SAF HFS security, native file permission bit security is bypassed.File access is validated by <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> security through use of resourcepermissions. All the benefits of resource permissions can be utilized, includingmasking, profiles, scoping, <strong>and</strong> reporting.2–4 Cookbook
Controlling HFS Using <strong>CA</strong> SAF HFS <strong>Security</strong>Path Name TranslationA path name can be up to 1023 characters in length, except when used in the JCLPATH= keyword where the limit is 255 characters. The path name is also casesensitive <strong>and</strong> can contain special characters. In order to allow external securityto validate HFS files, <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> validation of HFS files requires pathname manipulation.Be<strong>for</strong>e validation, all path names are converted to upper case <strong>and</strong>, if necessary,truncated at 255 characters. An exit point is provided <strong>for</strong> cases when file namesreside in paths that are greater than 255 characters. The installation can use theexit to provide a meaningful name.<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> resource authorization processing considers the periodcharacter as a delimiter. This delimiter is used when permitting maskedresources, such as, when providing security <strong>for</strong> data sets. Path names, however,use the slash character as a delimiter. Be<strong>for</strong>e a file is validated, the path namewill have all slash characters, with the exception of the first, translated into aperiod delimiter. Other special characters is translated into the dollar sign ($).These include characters that are used as masking characters in resourcepermissions. If not translated, these characters could create undesired results.The special characters include the period, asterisk, dash, plus, blank, <strong>and</strong> quote.An exit point is provided which can further modify any character to meet specialneeds, with the exception of the slash character which will always be translatedto a period delimiter.Some examples of path name translation follow:Original pathnameTranslated path nameSample resourceauthorizations<strong>Security</strong>action/bin/su /BIN.SU TSS PER(USER01) HFSSEC(/BIN.SU)ACCESS(NONE)/u/user01/proj1/file1.txt/U.USER01.PROJ1.FILE1$TXTTSS PERMIT(USER01)HFSSEC(/U.%.PROJ1.FILE1$TXT)ACCESS(ALL)/usr/sbin/mknod /USR.SBIN.MKNOD TSS PER(SYSPROG)HFSSEC(/USR.SBIN.MKNOD)ACCESS(ALL)No access toswitch usercomm<strong>and</strong>All accessallowedAllow systemprogrammersto createspecialcharacters.Controlling Access to the Hierarchical File System 2–5
Controlling HFS Using <strong>CA</strong> SAF HFS <strong>Security</strong>HFSSEC Resource Class<strong>CA</strong> SAF HFS security introduces a new pre-defined resource class calledHFSSEC. This new RESCLASS is used when defining file <strong>and</strong> directory levelaccess in <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>.Permission ConsiderationsThis section describes special considerations to be taken into account whenadministering permits <strong>for</strong> HFS resources.In addition to access to HFS files, users can also need access to directories. Auser requires READ access to a directory in order to list the contents of thatdirectory. When writing a permission, you distinguish a directory permit from afile permit by not using a trailing period in the HFSSEC authorization. Forexample, the permits used to allow users to read the /BIN directory, but onlyallow EXECUTE access to the files contained within the directory is:TSS PER(ALL) HFSSEC(/BIN) ACCESS(READ)TSS PER(ALL) HFSSEC(/BIN.) ACCESS(EXEC)The root directory is defined by the single character (/). With <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong><strong>Secret</strong> the root directory must be owned using the special name ROOT. Filescontained in the root directory (/) must be specified as the slash (/) followed bythe file name. There<strong>for</strong>e, the only valid permit <strong>for</strong> the ROOT directory (/) is thatwhich allows read access to the directory itself. The following shows the permitrequired <strong>for</strong> the root directory <strong>and</strong> a permit that allows read <strong>and</strong> write access tofile rootfile:TSS PER(ALL) HFSSEC(ROOT) ACCESS(READ)TSS PER(ALL) HFSSEC(/ROOTFILE) ACCESS(UPDATE)Permits administered to secure HFS file resources should specify the ACCESSkeyword to identify the type of access to the file. If the access keyword is notused, READ access is implied. The access keywords <strong>and</strong> their meanings follow:KeywordEXECUTEREADUPDATEALTERDescriptionAllows execute access to a file, usually a program file.Allows read access to a file.Allows write access to a file.Allows create <strong>and</strong> delete access to a file.2–6 Cookbook
Securing HFS FunctionsKeywordALLCONTROLDescriptionAllows all of the above.A special access not used <strong>for</strong> normal file accessvalidation. This is used with HFS function security toallow a user to change file attributes. Morein<strong>for</strong>mation can be found in the following section.ReportingAudit records created by HFS file access checks, (i.e., violations, <strong>and</strong> auditevents) are written to the Audit Tracking File <strong>and</strong> accessed by the TSSUTILreport utility. TSSUTIL integrates these events among other events according tothe report generation criteria.Securing HFS FunctionsIn addition to file access security, HFS functions can also be secured. Thesefunctions can be a system action, such as setting a ptrace or a job’s priority, orthey can be file-related, such as changing the file mode or audit settings.A system function is secured by a rule in the IBMFAC class, while a file-relatedfunction is secured by a combination of an IBMFAC class rule <strong>and</strong> a HFS fileresource rule. By following this approach, changes to file attributes can bepermitted at a global basis, or restricted to a particular file.The resource name <strong>for</strong>mat <strong>for</strong> HFS IBMFAC rules is: BPX.<strong>CA</strong>HFS.function. Anexample of a permission would be:TSS PER(USER01) IBMFAC(BPX.<strong>CA</strong>HFS.function) ACCESS(READ)System FunctionsIn order to per<strong>for</strong>m a system function, the user requires READ access to thecorresponding IBMFAC.Controlling Access to the Hierarchical File System 2–7
Securing HFS FunctionsSystem Functions (IBMFAC ATTRIBUTE)BPX.<strong>CA</strong>HFS.CHANGE.PRIORITY—Allows a user to change the schedulingpriority of a process, process group, or user.BPX.<strong>CA</strong>HFS.SET.PRIORITY—Allows a user to set the scheduling priority of aprocess, process group, or user.BPX.<strong>CA</strong>HFS.SET.RLIMIT—Allows a user to set the resource limit <strong>for</strong> the callingprocess.BPX.<strong>CA</strong>HFS.MOUNT—Allows a user to mount file systems.BPX.<strong>CA</strong>HFS.UNMOUNT—Allows a user to remove a virtual file system.BPX.<strong>CA</strong>HFS.PTRACE—Allows a user to control <strong>and</strong> debug another process.Although the user need not be defined as a superuser to use this function, accessto this resource does not give the user any more authority than a superuserwould have. Access to the function is denied if the user attempts to debug aprogram running with SETUID or SETGID, that is, a program that switches useridentification.BPX.<strong>CA</strong>HFS.CREATE.LINK—Allows a user to create a hard link to an existingfile. A hard link is essentially another name <strong>for</strong> the same file data. If the originalfile is removed, the hard link still points to the file data. The data is not deleteduntil the last link is removed. The user requires a permission withACCESS(ALTER) to the HFS file resource <strong>for</strong> both the original file <strong>and</strong> the linkfile. It is important to note that when data associated with a hard link isaccessed, the <strong>CA</strong>-ENF/USS service requests the file name from <strong>OS</strong>/390 UNIXServices. The file name returned might be the hard link name or the original filename regardless of the actual path accessed. It is unpredictable which name isreturned. There<strong>for</strong>e, when a hard link exists, you must maintain permissions <strong>for</strong>both the link name <strong>and</strong> the original name.BPX.<strong>CA</strong>HFS.CREATE.EXTERNAL.LINK—Allows a user to create an externallink to an object outside of the file system, such as an MVS data set. An externallink is a file that contains the name of an external object. If the external object isremoved, the external link still contains the name of the non-existent object.BPX.<strong>CA</strong>HFS.CREATE.SYMBOLIC.LINK—Allows a user to create a symboliclink to an existing file. A symbolic link is a file that contains the name of anotherfile. If the original file is removed, the file data is deleted but the symbolic linkstill contains a pointer to the non-existent file. Symbolic link names are validatedwhen the link is created <strong>and</strong> deleted. All other accesses are validated with theoriginal file name. In addition to this resource, the user also requires a PERMITwith ACCESS(ALTER) to the HFS file resource <strong>for</strong> both the original file <strong>and</strong> thelink file.2–8 Cookbook
Securing HFS FunctionsFile FunctionsFile-related functions can be secured to various levels of granularity. This isaccomplished by determining a user’s highest level of access to an IBMFACresource. The ACCESS keyword of the IBMFAC resource authorization is used<strong>for</strong> this purpose. The following actions are taken based upon the ACCESS value:ALL—The user is allowed to per<strong>for</strong>m the function against all files.CONTROL—The user is allowed to per<strong>for</strong>m the function if the user also hasACCESS(CONTROL) access to the HFS file resource. The access level ofCONTROL is not used in normal file access. It is utilized here to provideadditional controls <strong>for</strong> file functions.UPDATE—Processing is the same as <strong>for</strong> CONTROL.READ—The user is allowed to per<strong>for</strong>m the function if the user also hasACCESS(CONTROL) access to the HFS file resource, or if the user is consideredthe owner of the file. This is ownership as defined by <strong>CA</strong> SAF HFS security, notUNIX file UID.NONE—If the user has no access to the IBM FACILITY resource, the function isdenied.Because the absence of the ACCESS keyword in a permission implies READaccess, be sure to specify ACCESS in all of the file function IBMFAC permissionsso that you do not inadvertently allow greater access to functions than youintended.HFS file permission settings <strong>and</strong> UID/GID ownership are not used <strong>for</strong> validationpurposes when <strong>CA</strong> SAF HFS security is active. However, the followingresources restrict changes to these settings <strong>for</strong> those cases in which they must bemaintained.File Functions (IBMFAC)The following are the file functions authorized via the IBMFAC ATTRIBUTE:BPX.<strong>CA</strong>HFS.CHANGE.FILE.ATTRIBUTES—Allows a user to change extendedfile attributes, such as APF authorization <strong>and</strong> program control. Native <strong>OS</strong>/390UNIX services will issue an IBMFAC resource call to determine authorization toset the specific attribute, but not to specific files. Use of this file function resourceprovides additional control down to the file level.BPX.<strong>CA</strong>HFS.CHANGE.FILE.AUDIT.FLAGS—HFS files contain two sets ofaudit flags, one that can be set by a normal user <strong>and</strong> the other that can only be setby an auditor. This resource allows a user to change user-audit flags in a file.BPX.<strong>CA</strong>HFS.CHANGE.FILE.FORMAT—Allows a user to change the <strong>for</strong>mat ofa file. Changes include defining text data delimiters or binary file <strong>for</strong>mat.Controlling Access to the Hierarchical File System 2–9
Securing HFS FunctionsBPX.<strong>CA</strong>HFS.CHANGE.FILE.MODE—Allows a user to change any file modein<strong>for</strong>mation. This includes changes to file permission settings, setting theexecution UID or GID indicators, <strong>and</strong> setting the "sticky" bit. Native <strong>OS</strong>/390UNIX permission settings are used <strong>for</strong> validation purposes only when <strong>CA</strong> SAFHFS security is inactive.BPX.<strong>CA</strong>HFS.CHANGE.FILE.MODE.STICKY—Allows a user to set the "sticky"bit in the file mode in<strong>for</strong>mation. The "sticky" bit causes a program to be loadedfrom MVS libraries instead of the HFS.BPX.<strong>CA</strong>HFS.CHANGE.FILE.MODE.EUID—Allows a user to set theexecution-UID indicator in the file mode in<strong>for</strong>mation. When this indicator is set,the program runs under the UNIX UID of the file owner instead of the UID of theuser running the program.BPX.<strong>CA</strong>HFS.CHANGE.FILE.MODE.EGID—Allows a user to set theexecution-GID indicator in the file mode in<strong>for</strong>mation. When this indicator is set,the program runs under the UNIX GID of the file owner instead of the GID of theuser running the program.BPX.<strong>CA</strong>HFS. CHANGE.FILE.OWNER—Allows a user to change file owner UIDsetting. Native <strong>OS</strong>/390 UNIX ownership settings are used <strong>for</strong> validationpurposes only when <strong>CA</strong> SAF HFS security is inactive.BPX.<strong>CA</strong>HFS. CHANGE.FILE.GROUP—Allows a user to change file owner GIDsetting. Native <strong>OS</strong>/390 UNIX ownership settings are used <strong>for</strong> validationpurposes only when <strong>CA</strong> SAF HFS security is inactive.BPX.<strong>CA</strong>HFS. CHANGE.FILE.TIME—Allows a user to change the last access ormodification time to the current time or a user-specified time. If the current timeis to be set <strong>and</strong> the user has write access to the file, the function is allowed. If theuser does not have write access or a user-specified time is to be set, access mustbe allowed to this IBMFAC resource.Sample PermissionsThe following example shows TSS PERMITS that allow Thelma to change the filemode <strong>and</strong> owner <strong>for</strong> all files. Louise is allowed to change the file mode <strong>for</strong> onlythose files that reside in a certain directory, but is not allowed to change the fileowner in any file:TSS PER(THELMA) IBMFAC(BPX.<strong>CA</strong>HFS.CHANGE.FILE.MODE) ACCESS(ALL)TSS PER(LOUISE) IBMFAC(BPX.<strong>CA</strong>HFS.CHANGE.FILE.MODE) ACCESS(CONTROL)TSS PER(THELMA) IBMFAC(BPX.<strong>CA</strong>HFS.CHANGE.FILE.OWNER) ACCESS(ALL)TSS PER(LOUISE) HFSSEC(/certain.directory.) ACCESS(ALL)2–10 Cookbook
Implementing <strong>CA</strong> SAF HFS <strong>Security</strong>Implementing <strong>CA</strong> SAF HFS <strong>Security</strong><strong>CA</strong> SAF HFS security is an application of <strong>CA</strong>IENF/USS (UNIX System Services).This security application is activated when the appropriate DCM modules arelinked into the ENF database. The following describes the implementation steps:1. <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> <strong>for</strong> <strong>OS</strong>/390 5.1 SP2 or higher is required to implement<strong>CA</strong> SAF HFS <strong>Security</strong>.2. Determine if exit processing is required <strong>for</strong> path name translation, user pathdefinition or to enable file ownership. See below <strong>for</strong> specifics regarding exitprocessing. If using the exit, assemble <strong>and</strong> link the exit code using thesample SMPE usermod found in OPMAT member UD00001.3. Define HFS file <strong>and</strong> function resource authorizations. It is recommended thatall the function resources described in the previous sections be defined. Autility is provided to assist in creating these resource rules. See section <strong>CA</strong>SAF HFS ADD/PERMIT Generation Utility <strong>for</strong> details.4. If you utilize the user file ownership feature of <strong>CA</strong> SAF HFS security(described in Exit Processing section), also define authorizations <strong>for</strong> users.5. Verify that the proper level of <strong>CA</strong>IENF is available to support ENF/USS. <strong>CA</strong>Common Services <strong>for</strong> z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 with the following APARs providesthis support: LO89578 through LO89581, LO89584, LO92642, <strong>and</strong> LO94652,<strong>and</strong> LO94657.6. The ENF started task must be a valid OMVS user. Message <strong>CA</strong>RR014E isissued if this is not done. Ensure the ENF acid specifies a group. Install thefollowing DCM modules into the ENF database using the ENFDB utilityprogram: <strong>CA</strong>RRDCM0 (Framework) <strong>and</strong> J163DCM0(<strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>).7. Defining a VLF class <strong>for</strong> use as a cache can enhance per<strong>for</strong>mance ofENF/USS. The cache size is determined by the MAXVIRT specification. Thenumber of cache entries is approximated by dividing the defined amount ofVLF storage by the average size of your path names. Add the following toyour current COFVLFxx member in SYS1.PARMLIB:CLASS NAME(<strong>CA</strong>ENFU) /* ENF/USS pathname cache */EMAJ(PATH<strong>CA</strong>CHE) /* Major name */MAXVIRT(256) /* 1 megabyte */8. Adding the NODSNCHK attribute to the BPXOINIT logonid during initialtesting will allow OMVS to successfully initialize without violations. Onceappropriate authorizations are in place, the NODSNCHK attribute should beremoved.9. The following message is issued by <strong>CA</strong>IENF/USS at ENF startup when <strong>CA</strong>SAF HFS security is successfully initialized:<strong>CA</strong>RR036I - SAFHFINT / J163 Now InitializedControlling Access to the Hierarchical File System 2–11
HFSSEC Control Option10. Set the <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> Control Option HFSSEC to ON: HFSSEC(ON)11. Run TSSUTIL during the implementation phase. Review violations <strong>and</strong>loggings <strong>for</strong> HFSSEC <strong>and</strong> IBMFAC resource types <strong>and</strong> create appropriateauthorizations.HFSSEC Control OptionA new <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> Control Option exists to turn HFS security ON <strong>and</strong>OFF. This control option is set in the TSS PARMS startup member or can bedynamically set via a TSS MODIFY comm<strong>and</strong>. To determine the current activesetting of HFSSEC, issue: TSS MODIFY STATUS(BASE)HFSSEC(ON)—Enables <strong>CA</strong> SAF HFS security. When enabled, normal <strong>OS</strong>/390UNIX security access validation is bypassed. This includes checking of filepermission bits, superuser status <strong>and</strong> normal <strong>OS</strong>/390 UNIX security services.HFSSEC(OFF)—Disables <strong>CA</strong> SAF HFS security. When disabled, normal <strong>OS</strong>/390UNIX security access validation is enabled. This includes checking of filepermission bits, superuser status <strong>and</strong> normal <strong>OS</strong>/390 UNIX security services.Exit ProcessingAn exit point is provided <strong>for</strong> installation-specific processing. This exit is called<strong>for</strong> both an initialization function, where options involving pathname translation<strong>and</strong> user path processing can be selected, <strong>and</strong> a pathname translation function,where final modification to the pathname can be made be<strong>for</strong>e validation isper<strong>for</strong>med.The exit must be reentrant <strong>and</strong> capable of running AMODE(31) <strong>and</strong>RMODE(ANY). The exit name is SAFHFUSR <strong>and</strong> must be linked together withload module SAFHFSEC. A sample SMPE usermod to per<strong>for</strong>m this can be foundin OPMAT member UD00001.Upon entry to the exit, register R1 points to a list of addresses. The end of the listis indicated by the high order bit in the last full word.For an initialization function, the exit is passed the following parameteraddresses:+0—The address of a single byte containing the character ‘I’ indicating that this isan initialization function.+4—The address of a 512-byte work area <strong>for</strong> the use of the exit program.+8—The address of a 255-byte field in which the user can return the path locationwhere user directories are located. Upon input, this field contains hex zeros.2–12 Cookbook
HFSSEC Control Option+12—The address of a single byte which, when set to ‘Y’ by the exit, indicatesthat user ownership of files is in effect.+16—The address of a 256-byte translation table, which is used to translatecertain special characters in a path name.When the exit returns a user directory path location, <strong>CA</strong> SAF HFS processinguses that path name to determine if the path name to be validated should betranslated to a <strong>for</strong>m such that the user ID of the owner of the path becomes thehigh-level qualifier of the path name. This will allow HFS file rules to be writtenat the user level. The default is that no translation takes place <strong>for</strong> userdirectories.An example: if the exit returns the value /u/ as the user directory path namelocation, <strong>and</strong> the file accessed is /u/user01/xfile, then the resource namevalidated is $$USER01.XFILE. A rule to allow access to this file could be:TSS PER(USER01) HFSSEC($$%) ACCESS(UPDATE)When the exit returns the character ‘Y’ indicating that user ownership of fileswithin one’s own directory is in effect, no validation is per<strong>for</strong>med when thecurrent user’s logonid matches that in the user directory. In the above example,validation would be bypassed when USER01 accesses file /u/user01/xfile. Thisoption is meaningless if a user directory path location is not also returned.The supplied translate table is in a <strong>for</strong>mat acceptable as input to the assemblerTR instruction. The default translate table will translate all slash characters in apath name, with the exception of the leading slash, to a period character. Otherspecial characters is translated into the dollar sign ($). These include charactersthat are used as masking characters in resource rules. If not translated, thesecharacters could create undesired results. The special characters include theperiod, asterisk, dash, plus, blank, <strong>and</strong> quote. An exit point is provided whichcan further modify any character in the table to meet special needs, with theexception of the slash character which will always be translated to a perioddelimiter.For a path name translation function, the exit is passed the following parameteraddresses:+0—The address of a single byte containing the character ‘P’ indicating that thisis a path name translation function.+4—The address of a 512-byte work area <strong>for</strong> the use of the exit program.+8—The address of a 255-byte field containing the resource name as modified by<strong>CA</strong> SAF HFS processing. This is the name that is used <strong>for</strong> validation. The exitcan return a modified path name in this same field.+12—The address of a 1023-byte field containing the original unmodified pathname.Controlling Access to the Hierarchical File System 2–13
HFSSEC Control OptionThe exit can use this exit function to make any specific modifications to the pathname beyond that already per<strong>for</strong>med by <strong>CA</strong> SAF HFS security processing.TroubleshootingThe following section discusses troubleshooting solutions.ReportingReporting is done through the existing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> resource report,TSSUTIL. When the AUDIT attribute is on the user’s acid or specificpermissions, audit records can also appear on the report if they are requested inthe report criteria. The report will show the translated name of the HFS file used<strong>for</strong> validation. TSSUTIL should be reviewed when researching validationproblems.In addition, the online real-time monitor TSSTRACK can also be used to monitorHFS file security related events.OPTIONS(32)Control option, OPTIONS(32), provides support <strong>for</strong> USS event logging to the AuditTracking File.To take advantage of this feature, the LONG option must be specified inTSSUTIL. This will ensure that the full 256-character resource name can bedisplayed. Logging will only take place <strong>for</strong> the acids that have the AUDIT orTRACE attributes assigned.A new RDT class called USSLOG is introduced with this new USSLOG feature.This will allow TSSUTIL to select USSLOG records with the RESCLASS(USSLOG) option <strong>and</strong> to report the access level <strong>for</strong> the USS event. All of therecords are displayed as a resource type of USSLOG.The resource name field will display the USS function, i.e., INIT_USP <strong>and</strong> <strong>for</strong>some types of USS events, i.e., CHECK_ACCESS, the path name <strong>and</strong> file namebeing assessed. (In the example of the TSSUTIL report below, you can see howthe records are displayed)The TSSOERPT can still be used to get additional detailed in<strong>for</strong>mation about theUSS event, such as UID, GID or group name. Otherwise TSSUTIL will nowcontain the event in<strong>for</strong>mation such as: User ID’s, Modes, Function, Path Names,File Names, Return Code, Facility, etc. (See the example below to see how thetypical record are displayed). As part of <strong>CA</strong>SAF, USS events are being logged toSMF as well.2–14 Cookbook
HFSSEC Control OptionDiagnosticsThe <strong>CA</strong> SAF HFS security interface can be traced by using the SECTRACEcomm<strong>and</strong>. A trace of internal functions of <strong>CA</strong> SAF HFS security is enabledthrough use of the SECTRACE TYPE=HFS keyword. The trace output can berequested by technical support. The syntax is:SecTrace SET,TYPE=HFSThe following keywords are meaningful when TYPE=HFS is specified:ID=JOBname=USERid=ENable|DISableACTION=MATCHLIM=DEST=CONSOLE|JOBLOG|SYSLOGCONSid=MSGid|NOMSGidOther keywords are ignored. If DEST is not specified, the default isDEST=SYSLOG.The SAF validation calls invoked by <strong>CA</strong> SAF HFS security can also be traced.These SAF calls are the file <strong>and</strong> function validations that are passed to <strong>eTrust</strong><strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>. Enable this tracing by first issuing the SECTRACE SETcomm<strong>and</strong> detailed below, followed by a reply to the prompt:ST SET,ID=id,TYPE=SAFP,DEST=dest,ENDR nn,REQSTOR=SAFHFSEC,ENDTSSUTIL/SAF Reference TablesAt <strong>OS</strong>/390 Release 2.8 <strong>and</strong> above, results from running a TSSUTIL <strong>and</strong> a SAFSECTRACE are different when the HFSSEC control option is set to ON or OFF.The tables should be used as a reference when you are evaluating the results ofthese utilities.Controlling Access to the Hierarchical File System 2–15
HFSSEC Control OptionTSSSUTIL EQUIVILENCY TABLEUNIX CMDCHAUDITHFSSEC(ON)CHAUDITHFSSEC(OFF)CHAUDITHFSSEC(OFF)CHATTRHFSSEC(ON)CHATTRHFSSEC(OFF)CHMOD (UID)HFSSEC(ON)CHMOD (UID)HFSSEC(OFF)TSSUTIL Sample OutputDATE TIME SYSID ACCESSOR JOBNAME FACILITY MODE VCPROG01/17/00 13:03:49 XE14 OMVSPT1 OMVSPT1 TSO WARNRESOURCE TYPE:USSLOGRES=R_CHECK_AUDIT /u/omvspt1/_DATE TIME SYSID ACCESSOR JOBNAME FACILITY MODE VCPROG02/01/00 10:12:08 XE14 OMVSPT1 OMVSPT1 TSO WARNRESOURCE TYPE & NAME : UNIXPRIV SUPERUSER.FILESYS.FILE02/01/00 10:12:08 XE14 OMVSPT1 OMVSPT1 TSO WARN SEARRESOURCE TYPE:USSLOGRES=CHECK_ACCESS /u/omvspt1/altertestbDATE TIME SYSID ACCESSOR JOBNAME FACILITY MODE VCPROG02/01/00 10:12:08 XE14 OMVSPT1 OMVSPT1 TSO WARNRESOURCE TYPE & NAME : UNIXPRIV SUPERUSER.FILESYS.FILE02/01/00 10:12:08 XE14 OMVSPT1 OMVSPT1 TSO WARN SEARRESOURCE TYPE:USSLOGRES=CHECK_ACCESS /u/omvspt1/altertestbDATE TIME SYSID ACCESSOR JOBNAME FACILITY MODE VCPROG01/17/00 13:51:05 XE14 OMVSPT1 OMVSPT1 TSO WARNRESOURCE TYPE:USSLOGRES=CHECK_FILE_OWNER /u/omvspt1/altertestDATE TIME SYSID ACCESSOR JOBNAME FACILITY MODE VCPROG2/01/00 10:15:32 XE14 OMVSPT1 OMVSPT1 TSO WARNRESOURCE TYPE & NAME : UNIXPRIVSUPERUSER.FILESYS.FILE02/01/00 10:15:32 XE14 OMVSPT1 OMVSPT1 TSO WARNRESOURCE TYPE:USSLOGRES=CHECK_ACCESS /u/omvspt1/altertestbDATE TIME SYSID ACCESSOR JOBNAME FACILITY MODE VCPROG01/17/00 13:54:27 XE14 OMVSPT1 OMVSPT1 TSO WARNRESOURCE TYPE:USSLOGRES=R_CHECK_MODE /u/omvspt1/altertestDATE TIME SYSID ACCESSOR JOBNAME FACILITY MODE VCPROG02/01/00 10:18:47 XE14 OMVSPT1 OMVSPT1 TSO WARNRESOURCE TYPE & NAME : UNIXPRIV SUPERUSER.FILESYS.FILE02/01/00 10:18:47 XE14 OMVSPT1 OMVSPT1 TSO WARNRESOURCE TYPE:USSLOGRES=CHECK_ACCESS /u/omvspt1/altertestb2–16 Cookbook
HFSSEC Control OptionUNIX CMDCHMOD(STICKY BIT)HFSSEC(ON)CHMOD(STICKY BIT)HFSSEC(OFF)CHMOD (GID)HFSSEC(ON)CHMOD (GID)HFSSEC(OFF)CHOWNHFSSEC(ON)CHOWNHFSSEC(OFF)EDITHFSSEC(ON)EDITHFSSEC(OFF)TSSUTIL Sample OutputDATE TIME SYSID ACCESSOR JOBNAME FACILITY MODE VCPROG01/17/00 13:54:27 XE14 OMVSPT1 OMVSPT1 TSO WARNRESOURCE TYPE:USSLOGRES=R_CHECK_MODE /u/omvspt1/altertestDATE TIME SYSID ACCESSOR JOBNAME FACILITY MODE VCPROG02/01/00 10:20:35 XE14 OMVSPT1 OMVSPT1 TSO WARNRESOURCE TYPE & NAME : UNIXPRIV SUPERUSER.FILESYS.FILE02/01/00 10:20:35 XE14 OMVSPT1 OMVSPT1 TSO WARNRESOURCE TYPE:USSLOGRES=CHECK_ACCESS /u/omvspt1/altertestbDATE TIME SYSID ACCESSOR JOBNAME FACILITY MODE VCPROG01/17/00 13:54:27 XE14 OMVSPT1 OMVSPT1 TSO WARNRESOURCE TYPE:USSLOGRES=R_CHECK_MODE /u/omvspt1/altertestDATE TIME SYSID ACCESSOR JOBNAME FACILITY MODE VCPROG02/01/00 10:22:15 XE14 OMVSPT1 OMVSPT1 TSO WARN EXECRESOURCE TYPE & NAME : UNIXPRIV SUPERUSER.FILESYS.FILE02/01/00 10:22:15 XE14 OMVSPT1 OMVSPT1 TSO WARN SEARRESOURCE TYPE:USSLOGRES=CHECK_ACCESS /u/omvspt1/altertestbDATE TIME SYSID ACCESSOR JOBNAME FACILITY MODE VCPROG01/18/00 08:33:03 XE14 OMVSPT1 OMVSPT1 TSO WARNRESOURCE TYPE:USSLOGRES=R_CHECK_OWN /u/omvspt1/altertest2DATE TIME SYSID ACCESSOR JOBNAME FACILITY MODE VCPROG02/01/00 10:37:50 XE14 OMVSPT1 OMVSPT1 TSO WARN 30 EXEC READRESOURCE TYPE & NAME : UNIXPRIV SUPERUSER.FILESYS.CHOWN02/01/00 10:37:50 XE14 OMVSPT1 OMVSPT1 TSO WARNRESOURCE TYPE:USSLOGDATE TIME SYSID ACCESSOR JOBNAME FACILITY MODE VCPROGDATE TIME SYSID ACCESSOR JOBNAME FACILITY MODE VCPROG02/01/00 11:04:03 XE14 OMVSPT1 OMVSPT1 TSO WARNRESOURCE TYPE & NAME : UNIXPRIV SUPERUSER.FILESYS.FILE02/01/00 11:04:03 XE14 OMVSPT1 OMVSPT1 TSO WARNRESOURCE TYPE:USSLOGRES=CHECK_ACCESS /u/omvspt1/tssrulesControlling Access to the Hierarchical File System 2–17
HFSSEC Control OptionUNIX CMDEXTERNALLINKHFSSEC(ON)EXTERNALLINKHFSSEC(OFF)SYMBOLICLINKHFSSEC(ON)SYMBOLICLINKHFSSEC(OFF)SWITCH USER(SU)HFSSEC(ON)SWITCH USER(SU)HFSSEC(OFF)TSSUTIL Sample OutputDATE TIME SYSID ACCESSOR JOBNAME FACILITY MODE VCPROG01/18/00 10:11:32 XE14 OMVSPT1 OMVSPT1 TSO WARNRESOURCE TYPE & NAME : IBMFAC BPX.<strong>CA</strong>HFS.CREATE. EXTERNAL.LINK01/18/00 10:11:32 XE14 OMVSPT1 OMVSPT1 TSO WARNRESOURCE TYPE & NAME : HFSSEC /U.OMVSPT1.ALTERTEST3DATE TIME SYSID ACCESSOR JOBNAME FACILITY MODE VCPROG02/01/00 11:31:28 XE14 OMVSPT1 OMVSPT1 TSO WARNRESOURCE TYPE & NAME : UNIXPRIV SUPERUSER.FILESYS.FILE02/01/00 11:31:28 XE14 OMVSPT1 OMVSPT1 TSO WARNRESOURCE TYPE:USSLOGRES=CHECK_ACCESS /u/omvspt1/linktestDATE TIME SYSID ACCESSOR JOBNAME FACILITY MODE VCPROG01/18/00 12:12:20 XE14 OMVSPT1 OMVSPT1 TSO WARNRESOURCE TYPE & NAME : IBMFAC BPX.<strong>CA</strong>HFS.CREATE.SYMBOLIC.LINKDATE TIME SYSID ACCESSOR JOBNAME FACILITY MODE VCPROG02/01/00 11:47:36 XE14 OMVSPT1 OMVSPT1 TSO WARNRESOURCE TYPE & NAME : UNIXPRIV SUPERUSER.FILESYS.FILE02/01/00 11:47:36 XE14 OMVSPT1 OMVSPT1 TSO WARNRESOURCE TYPE:USSLOGRES=CHECK_ACCESS /u/omvspt1/linktestDATE TIME SYSID ACCESSOR JOBNAME FACILITY MODE VCPROG02/03/00 11:06:05 XE14 OMVSPT1 OMVSPT1 TSO WARNRESOURCE TYPE & NAME : IBMFAC BPX.SUPERUSER02/03/00 11:06:05 XE14 OMVSPT1 OMVSPT1 TSO WARNRESOURCE TYPE & NAME : USSLOG R_SET_EUIDDATE TIME SYSID ACCESSOR JOBNAME FACILITY MODE VCPROG02/03/00 11:06:05 XE14 OMVSPT1 OMVSPT1 TSO WARNRESOURCE TYPE & NAME : IBMFAC BPX.SUPERUSER02/03/00 11:06:05 XE14 OMVSPT1 OMVSPT1 TSO WARNRESOURCE TYPE & NAME : USSLOG R_SET_EUID2–18 Cookbook
HFSSEC Control OptionTSSSUTIL EQUIVILENCY TABLEUNIX CMDKILLHFSSEC(ON)KILLHFSSEC(OFF)EXTATTR(CHG. ATTR.)HFSSEC(ON)EXTATTR(CHG. ATTR.)HFSSEC(OFF)EXTATTR(PROG. CNTL.ATTR.)HFSSEC(ON)EXTATTR(PROG. CNTL.ATTR.)HFSSEC(OFF)TSSOERPT Sample OutputOMVS LOGGING REPORTSERVICE USERID GROUP UID GID SAF RC RSN DATETIME JOBNAME SOURCE SYSID CPUFunction: Purge Attribute flags: 00000000 Userid: Applid:Password: NO Certificate: NO ACEE Addr: NOINIT_USP OMVSPT1 OMVSGRP1 777 777 0 0 002/02/00 00.033 09:59:16 OMVSPT1 XE14 XE14OMVS LOGGING REPORTSERVICE USERID GROUP UID GID SAF RC RSN DATETIME JOBNAME SOURCE SYSID CPUDELETE_USP OMVSPT1 OMVSGRP1 0 0 0 0 002/02/00 00.033 10:53:15 OMVSPT1 XE14 XE14INIT_ACEE OMVSPT1 OMVSGRP1 0 0 0 0 002/02/00 00.033 10:53:15 OMVSPT1 XE14 XE14Function: Purge Attribute flags: 00000000Userid:Applid:Password: NO Certificate: NO ACEE Addr: NOOMVS LOGGING REPORTSERVICE USERID GROUP UID GID SAF RC RSN DATETIME JOBNAME SOURCE SYSID CPU GET_GMAP OMVSPT1 OMVSGRP1 777777 0 0 002/02/00 00.033 09:41:41 OMVSPT1 XE14 XE14OMVS LOGGING REPORTSERVICE USERID GROUP UID GID SAF RC RSN DATETIME JOBNAME SOURCE SYSID CPURequested Access: WriteFunction: chattrUser Type: <strong>Security</strong> Defined Local UserPathname: u/omvspt1/altertest1Filename: altertest1Volume : SMS001 Owner: rwx Group: r-- Other: ---File Identifier: 00010B00000FA40000Owning UID: 777 Owning GID: 777User Audit Options : Read Success Write Success Exec/Search FailureAuditor Audit Options: Read None Write None Exec/Search NoneOMVS LOGGING REPORTSERVICE USERID GROUP UID GID SAF RC RSN DATETIME JOBNAME SOURCE SYSID CPUGET_GMAP OMVSPT1 OMVSGRP1 777 777 0 0 002/02/00 00.033 09:46:11 OMVSPT1 XE14 XE14OMVS LOGGING REPORTSERVICE USERID GROUP UID GID SAF RC RSN DATETIME JOBNAME SOURCE SYSID CPURequested Access: WriteFunction: chattrUser Type: <strong>Security</strong> Defined Local UserPathname: u/omvspt1/altertest1Filename: altertest1Volume : SMS001 Owner: rwx Group: r-- Other: ---File Identifier: 00010B00000FA40000Owning UID: 777 Owning GID: 777User Audit Options : Read Success Write Success Exec/Search FailureAuditor Audit Options: Read None Write None Exec/Search NoneControlling Access to the Hierarchical File System 2–19
HFSSEC Control Option<strong>CA</strong> SAF HFS EQUIVILENCY TABLEHFSSEC(OFF) vs. HFSSEC(ON)<strong>OS</strong>/390 2.8 <strong>and</strong> aboveUNIX CMDS ACCESS GIVEN HPFSEC(ON) HPFSEC(OFF)CHAUDITAllow a user tochange user auditflagsBPX.<strong>CA</strong>HFS.CHANGE.FILE.AUDITFLAGSCHANGE_AUDIT_OPTAllow a user tochange a <strong>for</strong>matof a fileBPX.<strong>CA</strong>HFS.CHANGE.FILE.FORMATCHECK_FILE_OWNERCHMOD(UID)Allows a user tochange UID filepermission bitBPX.<strong>CA</strong>HFS.CHANGE.FI.LE.MODEBPX.<strong>CA</strong>HFS.CHANGE.FILE.MODE.EUIDCHANGE_FILE_MODECHMOD(STICKYBIT)Allows a user tochange Sticky bitfile permissionBPX.<strong>CA</strong>HFS.CHANGE.FILE.MODEBPX.<strong>CA</strong>HFS.CHANGE.FILE.MODE.EUIDCHANGE_FILE_MODEBPX.<strong>CA</strong>HFS.CHANGE.FILE.MODE.STICKYCHMOD(GID)Allows a user tochange GID bitBPX.<strong>CA</strong>HFS.CHANGE.FILE.MODECHANGE_FILE_MODEBPX.<strong>CA</strong>HFS.CHANGE.FILE.MODE.EUIDBPX.<strong>CA</strong>HFS.CHANGE.FILE.MODE.EGIDEXTATTR(ChangeAttributes)Allow a user toturn on APFattribute <strong>for</strong> anyHFS fileBPX.<strong>CA</strong>HFS.CHANGE.FILE.ATTRIBUTESSUPERUSER.FILESYS.FILEEXTATTR(ProgramControlled Attribute)Allow users toturn on theprogramcontrolledattributeBPX.<strong>CA</strong>HFS.CHANGE.FILE.OWNERSUPERUSER.FILESYS.FILECHOWNAllows a user tochangeownership offilesBPX.<strong>CA</strong>HFS.CHANGE.FILE.OWNERCHANGE_OWNER_GROUP2–20 Cookbook
HFSSEC Control OptionUNIX CMDS ACCESS GIVEN HPFSEC(ON) HPFSEC(OFF)MOUNTAllows a user tomount filesystemsBPX.<strong>CA</strong>HFS.MOUNTSUPERUSER.FILE.MOUNTUNMOUNTAllows a user toUnmount filesystemsBPX.<strong>CA</strong>HFS.UNMOUNTSUPERUSER.FILE.MOUNTLINKAllows a user tocreate a link toany HFSdirectoryBPX.<strong>CA</strong>HFS.CREATE.LINKSUPERUSER.FILESYS.FILERENAMEAllows a user torename an HFSdirectoryNO BPX <strong>CA</strong>LL. HFS TRACESHOWS ONE EVENT.RENAMESUPERUSER.FILESYS.FILEEDIT(OPEN)Allows a user towrite to any HFSfileNO BPX <strong>CA</strong>LL. HFS TRACESHOWS TWO EVENTS:OPEN AND RENAMESUPERUSER.FILESYS.FILEEXTERNAL(LINK)Allows a user tocreate an externallink to any HFSdirectoryBPX.<strong>CA</strong>HFS.CREATE.EXTERNAL.LINKSUPERUSER.FILESYS.FILESYMBOLIC(LINK)Allows a user tocreate a symboliclink to any HFSdirectoryBPX.<strong>CA</strong>HFS.CREATE.SYMBOLIC.LINKSUPERUSER.FILESYS.FILECHGRPAllows a user tochange groupsetting <strong>for</strong> a fileBPX.<strong>CA</strong>HFS.CHANGE.FILE.GROUPCHANGE_OWNER_GROUPKILLAllows a user tosend signals to aprocessSUPERUSER.PROCESS.GETPSENTSUPERUSER.PROCESS.KILLSU(SWITCH USER)Allows a user toswitch to superuser statusBPX.SUPERUSERSET_EFFECTIVE_UIDControlling Access to the Hierarchical File System 2–21
HFSSEC Control Option<strong>CA</strong> SAF HFS ADD/PERMIT Generation UtilityA set of utility programs is provided to generate <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>comm<strong>and</strong>s to be used as a starter set of resource definitions <strong>and</strong> authorizations<strong>for</strong> new implementations. The HFS resource authorizations that are created giveaccess based upon the file permission bits defined <strong>for</strong> groups <strong>and</strong> 'other' users.In other words, the rules will give users the same default access to files as theyhave when not running <strong>CA</strong> SAF HFS security. The generated authorizationsmust be modified to allow appropriate users greater access to the directoryresources than that granted to the general user community. Because of thenumber of files that can be contained in the HFS the utility only covers thedirectories. File permissions can be added be<strong>for</strong>e running the REXX exec in step5.The HFS File System contains directories <strong>and</strong> files in a tree structure. In order toquickly add <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> security a set of procedures <strong>and</strong> utilities areprovided. Following are the steps <strong>and</strong> utilities you will run to create <strong>and</strong> executethe <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> comm<strong>and</strong>s to protect your current file system.Step 1—Run the OMVS "ls -lRA" comm<strong>and</strong> in a batch TMP. Direct the output toa st<strong>and</strong>ard DASD file. This file must be allocated with RECFM=VB.Issue the ls comm<strong>and</strong> from the OMVS shell, directing the output to a HFS file.The options -lRA must be specified (the character following the dash is a lowercase letter 'L', not the number one). The file can then be copied into a MVS dataset using the OGET comm<strong>and</strong>. An example of these comm<strong>and</strong>s follows:ls -lRA / >>directory_in<strong>for</strong>mation_fileOGET '/directory_in<strong>for</strong>mation_file' 'mvs.input.file'The resulting file data should look similar to this:/:total 232drwx------ 3 USER OPENMVS 0 Jun 3 1998 JavaS390drwxr-xr-x 4 USER 0 May 7 1998 bindrwx--x--x 2 USER OPENMVS 0 Oct 1 1997 devdrwxr-xr-x 8 USER OPENMVS 0 Nov 4 17:05 etcdrwxr-xr-x 2 USER 0 Jan 20 1998 libdrwxrwxrwx 2 USER 0 Jan 19 11:51 tmpdrwxr-xr-x 8 USER OPENMVS 0 Jan 15 15:47 udrwxr-xr-x 11 USER0 Jan 20 1998 usr/JavaS390:total 16drwxrwxrwx 7 USER ZEROGRP 0 Sep 25 1997 J1.1.1Step 2—Run HFSPASS1. This is a two step job. It will read the file from step 1create <strong>and</strong> intermediate data set <strong>and</strong> then sort that data creating a file <strong>for</strong> step 3.See example 1.2–22 Cookbook
HFSSEC Control OptionExample 1// JOB//STEP1 EXEC PGM=HFSUTIL1,REGION=0M//SYSABEND DD SYSOUT=*//SYSUDUMP DD SYSOUT=*//HFSINPUT DD DSN=????.????.????,DISP=SHR//EXTRACT DD DSN= SORT.INPUT,UNIT=3390,// DISP=(NEW,<strong>CA</strong>TLG,DELETE),SPACE=(TRK,(15,1),RLSE),// DCB=(RECFM=FB,LRECL=300,BLKSIZE=6000)/*//STEP2 EXEC PGM=SORT,REGION=0M//SYSOUT DD SYSOUT=*//SORTWK01 DD UNIT=3390,SPACE=(CYL,5)//SORTWK02 DD UNIT=3390,SPACE=(CYL,5)//SORTWK03 DD UNIT=3390,SPACE=(CYL,5)//SORTWK04 DD UNIT=3390,SPACE=(CYL,5)//SORTIN DD DSN=SORT.INPUT,DISP=(OLD,DELETE,KEEP)//SORTOUT DD DSN=SORT.OUTPUT,UNIT=3390,// DISP=(NEW,<strong>CA</strong>TLG,DELETE),SPACE=(TRK,(15,1),RLSE),// DCB=(RECFM=FB,LRECL=300,BLKSIZE=6000),VOL=SER=S<strong>CA</strong>C16//SYSIN DD *SORT FIELDS=(1,264,CH,A)/*Alternatively, the input file <strong>for</strong> step1 can point directly to the directoryin<strong>for</strong>mation file created from the ls comm<strong>and</strong>. If using this <strong>for</strong>mat, the LRECLvalue 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 greater than the LRECL. ThePATH name must be the full path name of the file containing the directoryin<strong>for</strong>mation. A sample statement follows://HFSINPUT DD PATH='/directory_in<strong>for</strong>mation_file',// PATHOPTS=(ORDONLY),FILEDATA=TEXT,// RECFM=VB,LRECL=nnn,BLKSIZE=nnnStep 3—Edit the file created in step 2. Following are the instructions <strong>for</strong> thatprocess. See example 1.1 <strong>for</strong> data to be edited.At the beginning of the data set are records to build a /group profilecross-reference table. The <strong>for</strong>mats of those records are:AAAAAAAA - xxxxxxxx“AAAAAAAA” is the name of an OMVS group. The “xxxxxxxx” should bechanged to a profile to be used <strong>for</strong> any permissions needed by this group. In ourexample OPENMVS is the group <strong>and</strong> you must assign a profile name to“xxxxxxxx”.It should be noted that this is not a complete list of all groups, only those acidsthat needs a specific permission given.After those records are several TSS ADD or TSS ADDTO comm<strong>and</strong>s. These areall of the ownership's that are required <strong>for</strong> the conversion to meet with success.In these statements the xxxxxxxx (acid name) needs to be modified to whateveracid the client wants to own the specified resources.Controlling Access to the Hierarchical File System 2–23
HFSSEC Control OptionExample 1.1OPENMVS - xxxxxxxxTSS ADD(xxxxxxxx) HFSSEC(ROOT)TSS ADD(xxxxxxxx) IBMFAC(BPX.<strong>CA</strong>HF)TSS ADDTO(xxxxxxxx) HFSSEC(/bin)TSS ADDTO(xxxxxxxx) HFSSEC(/dev)TSS ADDTO(xxxxxxxx) HFSSEC(/etc)TSS ADDTO(xxxxxxxx) HFSSEC(/lib)TSS ADDTO(xxxxxxxx) HFSSEC(/opt)TSS ADDTO(xxxxxxxx) HFSSEC(/samples)TSS ADDTO(xxxxxxxx) HFSSEC(/tmp)TSS ADDTO(xxxxxxxx) HFSSEC(/u)TSS ADDTO(xxxxxxxx) HFSSEC(/usr)TSS ADDTO(xxxxxxxx) HFSSEC(/JavaS390)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.CHANGE.FILE.ATTRIBUTES)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.CHANGE.FILE.AUDIT.FLAGS)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.CHANGE.FILE.FORMAT)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.CHANGE.FILE.GROUP)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.CHANGE.FILE.MODE.EGID)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.CHANGE.FILE.MODE.EUID)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.CHANGE.FILE.MODE.STICKY)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.CHANGE.FILE.MODE)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.CHANGE.FILE.OWNER)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.CHANGE.FILE.TIME)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.CHANGE.PRIORITY)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.CREATE.EXTERNAL.LINK)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.CREATE.LINK)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.CREATE.SYMBOLIC.LINK)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.MOUNT)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.PTRACE)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.SET.PRIORITRY)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.SET.RLIMIT)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.UNMOUNT)TSS PERM(ALL) HFSSEC(ROOT) ACCESS(READ)ALL //binALL //devALL //etcALL //libALL //optStep 4—Run HFSPASS2. It will read the edited data set <strong>and</strong> produce a data setcontaining all the TSS comm<strong>and</strong>s to be executed. See example 2.2–24 Cookbook
HFSSEC Control OptionExample 2// JOB//STEP3 EXEC PGM=HFSUTIL2,REGION=0M//SYSABEND DD SYSOUT=*//SYSUDUMP DD SYSOUT=*//EXTRACT DD DSN=SORT.OUTPUT,DISP=SHR//PRMOUT DD DSN=TSS.CMDS,UNIT=3390,VOL=SER=S<strong>CA</strong>C16,// DISP=(NEW,<strong>CA</strong>TLG,DELETE),SPACE=(TRK,(15,1),RLSE),// DCB=(RECFM=FB,LRECL=300,BLKSIZE=6000)Example 2.1 Output from the HFSUTIL2TSS ADD(xxxxxxxx) HFSSEC(ROOT)TSS ADD(xxxxxxxx) IBMFAC(BPX.<strong>CA</strong>HF)TSS ADDTO(xxxxxxxx) HFSSEC(/bin)TSS ADDTO(xxxxxxxx) HFSSEC(/dev)TSS ADDTO(xxxxxxxx) HFSSEC(/etc)TSS ADDTO(xxxxxxxx) HFSSEC(/lib)TSS ADDTO(xxxxxxxx) HFSSEC(/opt)TSS ADDTO(xxxxxxxx) HFSSEC(/samples)TSS ADDTO(xxxxxxxx) HFSSEC(/tmp)TSS ADDTO(xxxxxxxx) HFSSEC(/u)TSS ADDTO(xxxxxxxx) HFSSEC(/usr)TSS ADDTO(xxxxxxxx) HFSSEC(/JavaS390)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.CHANGE.FILE.ATTRIBUTES)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.CHANGE.FILE.AUDIT.FLAGS)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.CHANGE.FILE.FORMAT)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.CHANGE.FILE.GROUP)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.CHANGE.FILE.MODE.EGID)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.CHANGE.FILE.MODE.EUID)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.CHANGE.FILE.MODE.STICKY)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.CHANGE.FILE.MODE)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.CHANGE.FILE.OWNER)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.CHANGE.FILE.TIME)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.CHANGE.PRIORITY)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.CREATE.EXTERNAL.LINK)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.CREATE.LINK)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.CREATE.SYMBOLIC.LINK)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.MOUNT)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.PTRACE)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.SET.PRIORITRY)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.SET.RLIMIT)TSS PERM(ALL) FOR(14) IBMFAC(BPX.<strong>CA</strong>HFS.UNMOUNT)TSS PERM(ALL) HFSSEC(ROOT) ACCESS(READ)TSS PERMIT(ALL) HFSSEC(/bin) ACCESS(READ,EXEC)TSS PERMIT(ALL) HFSSEC(/dev) ACCESS(EXEC)TSS PERMIT(ALL) HFSSEC(/etc) ACCESS(READ,EXEC)TSS PERMIT(ALL) HFSSEC(/lib) ACCESS(READ,EXEC)TSS PERMIT(ALL) HFSSEC(/opt) ACCESS(READ,EXEC)TSS PERMIT(ALL) HFSSEC(/samples) ACCESS(READ,EXEC)Controlling Access to the Hierarchical File System 2–25
HFSSEC Control OptionStep 5—Run REXX exec to execute the comm<strong>and</strong>s in the data set.Example 3/* REXX *//*This EXEC will have as input a dataset name <strong>and</strong> will readthat dataset <strong>and</strong> issue the TSS comm<strong>and</strong>s in it.*/arg dsn . /* get data set name */if dsn = '' then dsn = '????.?????.????''ALLOC FI(PERMIN) DS('''dsn''') SHR REUSE VOL(??????)'eof = 'no'do while eof = 'no''execio 1 diskr PERMIN'if rc = 2then doeof = 'yes'endelse dopull recordsay 'Record is: ' recordrecordendend'execio 1 diskr permin ( finis''FREE FI(PERMIN)'exit 02–26 Cookbook
MessagesMessages<strong>CA</strong>S2301EEVENT PROCESSING ROUTINE COULD NOT BE LOADEDReason:The initialization process could not locate the event processing routine,SAFHFSEC.Action:Ensure that module SAFHFSEC is available in a link list library <strong>and</strong> that moduleSAFRTRLD contains the proper maintenance <strong>for</strong> <strong>CA</strong> SAF HFS security support.Module:SAFHFINT<strong>CA</strong>S2302EENF/USS GLOBAL WORKAREA NOT PRESENTReason:The ENF/USS initialization driver did not provide a required global workarea tothe security initialization routine.Action:Contact technical support.Module:SAFHFINTControlling Access to the Hierarchical File System 2–27
Messages<strong>CA</strong>S2303EENF/USS EVENT STRUCTURE ARRAY NOT PRESENTReason:The ENF/USS initialization driver did not provide a required list of events to thesecurity initialization routine.Action:Contact technical support.Module:SAFHFINT<strong>CA</strong>S2304E<strong>CA</strong> SAF IVT CONTROL BLOCK COULD NOT BE FOUNDReason:A critical <strong>CA</strong> SAF control block could not be located. An improper installation ofthe security product or corruption of common storage can cause this.Action:Contact technical support.Modules:SAFHFINT, SAFHFMOD<strong>CA</strong>S2305EEVENT PROCESSING TABLE COULD NOT BE FOUNDReason:The table containing a list of security-related events could not be located or wascorrupted.Action:Ensure that the module SAFHFSEC is properly link edited <strong>and</strong> has not beencorrupted.Module:SAFHFINT2–28 Cookbook
Messages<strong>CA</strong>S2306Wxxxxxxxxxxxxxxx EVENT COULD NOT BE FOUNDReason:An expected security event was not found in the list of events presented tosecurity initialization by ENF/USS. The event can be obsolete or <strong>OS</strong>/390release-dependent. Processing continues without security processing <strong>for</strong> theevent.Action:Ensure that ENF/USS <strong>and</strong> the security product are at compatible maintenancelevels. Contact technical support providing the event name causing the error.Module:SAFHFINT<strong>CA</strong>S2310EPARAMETER ERROR DETECTEDReason:The ENF/USS event driver did not pass a required parameter to the securityevent processing routine.Action:Contact technical support.Module:SAFHFSECControlling Access to the Hierarchical File System 2–29
Messages<strong>CA</strong>S2311WERROR DETECTED IN USER EXIT SAFHFUSR; EXIT PROCESSING BYPASSEDReason:The installation has provided user exit code to modify the HFS path <strong>and</strong> filename in<strong>for</strong>mation. The exit has provided an invalid path name or writtenbeyond the path name field provided. Changes made by the user exit areignored. The user exit is contained in CSECT SAFHFUSR in load moduleSAFHFSEC. This message is issued only when HFS tracing is enabled.Action:Ensure that the exit logic is correct. One way to do this is to set aninstruction-fetch SLIP trap at the point where the user exit routine returns to thecaller. The modified path name in<strong>for</strong>mation should appear in the dump output.Contact technical support <strong>for</strong> further assistance.Module:SAFHFSEC<strong>CA</strong>S2312Euserid - access ACCESS DENIEDReason:<strong>Security</strong> processing has denied access to the HFS file or function. The messageidentifies the ID of the user attempting the access <strong>and</strong> the type of access. Thetype of access is reported in SAF terminology <strong>and</strong> can be EXECUTE, READ,UPDATE, CONTROL <strong>and</strong> ALTER. These accesses correspond to resource ruleSERVICE of EXECUTE, READ, UPDATE, DELETE <strong>and</strong> ADD. EXECUTE accessindicates that a program file is being accessed, READ that a file is opened <strong>for</strong>input, <strong>and</strong> UPDATE that a file is opened <strong>for</strong> output. CONTROL access indicatesthat some type of file function is being per<strong>for</strong>med, such as changing fileattributes. ALTER access indicates that a file is being created or deleted.Action:For more in<strong>for</strong>mation, run the resource violation report. The report will detailthe violation with the original HFS path name, the modified name, <strong>and</strong> thereason <strong>for</strong> access being denied.Module:SAFHFSEC2–30 Cookbook
Messages<strong>CA</strong>S2319ITRACEID=aaaaaaaa USER=bbbbbbbb JOBNAME=ccccccccReason:Output in response to a SECTRACE TYPE=HFS comm<strong>and</strong>. The first line of thetrace output contains the trace ID, the current user ID, <strong>and</strong> the current job name.Subsequent lines contain other in<strong>for</strong>mation specific to the request beingprocessed. This in<strong>for</strong>mation can include the event being processed, the HFS filename being accessed, return code values, <strong>and</strong> specific reasons <strong>for</strong> access beingallowed or denied.Action:This in<strong>for</strong>mation can be requested by technical support to assist in problemresolution.Module:SAFHFTRCControlling Access to the Hierarchical File System 2–31
Chapter3Using the Sysplex Coupling Facility<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> takes advantage of two functions that the Coupling Facilityoffers:■■XES Data Sharing Function<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> uses this feature to provide the ability to share <strong>Security</strong>File records <strong>for</strong> all <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> systems throughout the sysplex.XCF Function<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> uses this feature as a message router that allows thecommunication of <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> security in<strong>for</strong>mation betweensystems in the sysplex environment. It allows the propagation of comm<strong>and</strong>sissued on one system to all the other connected systems. XCF can be activewhen XES is not.The SYSPLEX XES FunctionThe XES data sharing feature lets you define structures in the sysplex thatmultiple systems can use. These structures contain data (a <strong>Security</strong> File <strong>for</strong> <strong>eTrust</strong><strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>) to be shared among the systems in the sysplex. Once the data hasbeen placed in a structure it is valid to be read, updated, or deleted by anysystem connected to that structure. It is the responsibility of the systemsprogrammer to define the structure-name to the Coupling Facility. Thisstructure-name is then defined to <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> as the repository of theshared <strong>Security</strong> File.Note: A second structure can be defined <strong>for</strong> recovery purposes. This alternatestructure is used in case the primary structure has faltered <strong>for</strong> any reason. Thisalternate structure is not m<strong>and</strong>atory, but can be used if desired <strong>and</strong> is alsodefined to <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>.Using the Sysplex Coupling Facility 3–1
The SYSPLEX XES FunctionThere are three types of structures that can be defined to the Coupling Facility,these include the List, Cache, <strong>and</strong> Lock structures. <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> uses theList structure to "hold" the <strong>Security</strong> File. With a List structure, numerousfunctions can be per<strong>for</strong>med against the <strong>Security</strong> File. For example, reads, writes,deletes, or multiple deletes can be per<strong>for</strong>med. A connection between eachsystem in the sysplex <strong>and</strong> the structure in the Coupling Facility must be createdto establish communication. This connection must be established prior to anyother function <strong>and</strong> indicates to the Coupling Facility which structure is to containthe data <strong>for</strong> future processing. When <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> is donecommunicating with the structure in the Coupling Facility, a disconnect must beper<strong>for</strong>med. A List structure can be redefined while systems are connected to it.A redefining of the structure can take place if, <strong>for</strong> example, it becomes full <strong>and</strong> itis necessary to increase its size.A List structure is made up of headers <strong>and</strong> data elements. Each header can beused to break up different types of in<strong>for</strong>mation in the structure. There is amaximum of sixteen headers that any one structure can have. With each header,data elements contain the data that is stored in the structure. The number ofheaders <strong>and</strong> the size of each data element are defined to the Coupling Facilitywhen <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> "connects" to the structure. <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>only requires the use of one header. Multiple data elements can exist under thatone header.The total size of the structure is dependent on how the structure is defined to theCoupling Facility. The required size of the Coupling Facility structure can bedetermined using the TSSFAR utility. This is done when the systemsprogrammer defines the name of the structure. Next, the amount of data isdependent on how the structure is defined at connection time. The first systemto connect to a structure supplies in<strong>for</strong>mation on how the structure is set up. Forexample, the number of headers <strong>and</strong> the maximum data element size, are two ofmany factors determining the amount of data that can be placed in a structure.These factors are supplied at connection time <strong>and</strong> are used in a calculation that isdone during the connection.Once a List structure is full, no more data can be added to it. However, thesystem programmer can increase the size of the Coupling Facility structure withno disruption to the system, or rebuilt the structure characteristics with minimaldisruption to the system.The Coupling Facility design h<strong>and</strong>les any failure in it or its connections bydisconnecting <strong>and</strong> reverting to normal I/O processing. After the problem isresolved, the user must reactivate the Coupling Facility by reactivating thesysplex connection.3–2 Cookbook
The SYSPLEX XCF FunctionThe SYSPLEX XCF FunctionThe XCF function within a sysplex environment allows communication betweenall systems in the sysplex. The main function is the message routing capability.Any system within the sysplex can "join" a group <strong>and</strong> send <strong>and</strong> receive messagesfrom each of the other members within the same group. For example, if systemA wanted to send a message to all other systems in the group it can do so byissuing a send message to the Coupling Facility. The Coupling Facility is thenresponsible <strong>for</strong> posting or notifying all other "joined" systems within the groupthat a message is waiting <strong>for</strong> them. Each notified system is then responsible <strong>for</strong>receiving the message that was sent. The actions per<strong>for</strong>med by the receivingsystem depend on the content of the message.<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> <strong>and</strong> the SYSPLEX XES FunctionThe XES data-sharing feature lets you define a primary <strong>and</strong> an alternate Liststructure in the Coupling Facility.If this feature is enabled, <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> attempts to obtain the requesteddata from the Coupling Facility be<strong>for</strong>e any physical I/O is per<strong>for</strong>med. If therequested data is obtained from the Coupling Facility no I/O is per<strong>for</strong>med. Thussaving the time from having to do the actual I/O to the database. If you areusing the <strong>CA</strong>CHE facility with <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>, the cache call is per<strong>for</strong>medprior to any call to the Coupling Facility. If the data is found in the <strong>CA</strong>CHE, nocalls to the Coupling Facility or the I/O to the database are per<strong>for</strong>med.Whenever direct physical I/O is requested to the <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> database,a number of decisions must be made. It is important that any updating of anyrecord is reflected on the database prior to the Coupling Facility. Most importantis the need to obtain the data from the Coupling Facility when a direct READ of arecord is requested. If any record is being updated, a lock to the CouplingFacility is issued to prevent the same record from being updated in the CouplingFacility by another <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> system. The <strong>Security</strong> File ENQ recordshows which system is currently holding the lock <strong>and</strong> a time stamp indicates thetime the lock was placed.A List structure allows <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> to optimally control what is placedin the Coupling Facility <strong>and</strong> the maintenance of the data once it is there. Theprimary List structure, defined by the systems programmer, is used to hold allthe data <strong>for</strong> the <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> database. The optional alternate Liststructure is used in the case that something happens to the primary list structure.If no alternate is defined, <strong>and</strong> the primary is unavailable, <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>defaults to its current I/O processing.Using the Sysplex Coupling Facility 3–3
<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> <strong>and</strong> the SYSPLEX XES FunctionHow does this all work? You must first define the list structure to the CouplingFacility. Then <strong>for</strong> each system enter a TSS MODIFY (SYSPLEX) comm<strong>and</strong> todefine the connect-name, structure-names, <strong>and</strong> group-name, <strong>and</strong> toautomatically connect each system to the Coupling Facility.The <strong>Security</strong> File ENQ record, the first physical record in the <strong>Security</strong> File, isused to keep control in<strong>for</strong>mation about the <strong>Security</strong> file, including file lockingstatus. The ENQ record includes the Coupling Facility structure name, <strong>and</strong> theCoupling Facility validity record includes the volume serial number (VOLSER)of the <strong>Security</strong> File. This in<strong>for</strong>mation is stored by the first system that connects tothe Coupling Facility structure, <strong>and</strong> is used by systems that connect subsequentlyto ensure that a unique <strong>Security</strong> File data set <strong>and</strong> structure name combination isused among all connected systems. When a local system attempts to lock the<strong>Security</strong> File, the structure name in the <strong>Security</strong> File ENQ record is compared tothe local system's currently defined structure.Whenever the <strong>Security</strong> File is locked by a non-Coupling Facility connectedsystem, the structure name found within the ENQ record is validated to beactive, <strong>and</strong> the local system connects to the same structure, be<strong>for</strong>e proceedingwith any update activity against the file.While the current system is active in the Coupling Facility, if the <strong>Security</strong> FileENQ record is altered by another system <strong>and</strong> it no longer contains the structurename, all systems are <strong>for</strong>ced to disconnect from the Coupling Facility.When a Coupling Facility connected system manually disconnects from thestructure, all other connected systems are <strong>for</strong>ced to disconnect as well, to ensurethat no residual data is left in the Coupling Facility while one of the systems isrunning without an XES connection. An XES sysplex connection without an XCFconnection is allowed.After a system is <strong>for</strong>ced to disconnect from a structure, as a result of a manualdisconnect comm<strong>and</strong>, all other connected systems are <strong>for</strong>ced to disconnect. Nore-connect is attempted until a new structure is allocated in the Coupling Facilityby a manual connect comm<strong>and</strong>, or by a new system starting up. To determine ifa structure was reallocated, use the TSS MODIFY(STATUS(SYSPLEX))comm<strong>and</strong>, or the D XCF,STR <strong>OS</strong>/390 operator comm<strong>and</strong>. Compare the currentversion number to the version number of the previous connection.3–4 Cookbook
<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> <strong>and</strong> the SYSPLEX XCF Function<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> <strong>and</strong> the SYSPLEX XCF FunctionXCF message routing allows <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> operator comm<strong>and</strong>s to besent to all other <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> systems in the sysplex that are defined tothe same group. This allows one <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> system to update securitycontrol in<strong>for</strong>mation <strong>and</strong> automatically send the in<strong>for</strong>mation to the other <strong>eTrust</strong><strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> systems in the sysplex. This provides critical datasynchronization on all systems without operator intervention.The group-name, defined by the SYSPLEX control option, defines the group thata <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> system "joins" when the sysplex is started. If there areany other <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> systems that have joined the same group <strong>and</strong> the"send" comm<strong>and</strong> has been specified, the TSS comm<strong>and</strong> is sent to those systems.The TSS comm<strong>and</strong> is then processed on the remote <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>systems as if it was entered locally.Note: In addition to being defined to the same group, the user must haveCONSOLE authority on all other systems in the sysplex so that the TSScomm<strong>and</strong>s can be properly processed.XCF(*) Control OptionXCF(*) is the <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> "send" comm<strong>and</strong> <strong>for</strong> routing in<strong>for</strong>mation toremote systems in the sysplex. The syntax is XCF(*) <strong>and</strong> must be entered as thelast parameter on the TSS MODIFY comm<strong>and</strong>:TSS MODIFY (VTHRESH(10,NOT),XCF(*))This comm<strong>and</strong> illustrates how XCF(*) is used on a TSS MODIFY comm<strong>and</strong> toupdate the violation threshold on all systems in a group on a sysplex with theVTHRESH control option. If the comm<strong>and</strong> is successful, the following message isdisplayed at the sending system.TSS9718I MODIFY COMMAND SENT VIA XCF TO ALL CONNECTEDSYSTEMS IN THIS SYSPLEXFor more details, see the Control Options Guide.Controlling Access to XCF PoliciesIBM provides an administrative utility, IXCMIAPU, to modify, add or deletepolicy data from the ARM, CFRM, LOGR or SFM data sets. Use of this utility iscontrolled by the FACILITY class resource MVSADMIN. <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>implementation of the FACILITY class is done using the IBMFAC resource class.Using the Sysplex Coupling Facility 3–5
Defining the Sysplex to <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>To secure access to the IXCMIAPU utility using <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> you mustestablish ownership of the resource <strong>and</strong> permit the required access to a policy asshown next.Establish ownership of the resource:TSS ADDTO(dept) IBMFAC(MVSADMIN)Permit required access to a policy:TSS PERMIT(user) IBMFAC(MVSADMIN.XCF.ARM) ACCESS(READ | UPDATE)TSS PERMIT(user) IBMFAC(MVSADMIN.XCF.CFRM) ACCESS(READ | UPDATE)TSS PERMIT(user) IBMFAC(MVSADMIN.XCF.LOGR) ACCESS(READ | UPDATE)TSS PERMIT(user) IBMFAC(MVSADMIN.XCF.SFM) ACCESS(READ | UPDATE)Two access levels are available <strong>for</strong> these resources:READ—Report only on a policyUPDATE—Alter <strong>and</strong> maintain a policyDefining the Sysplex to <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>Defining the sysplex environment to <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> is easy to do. To usethe XCF or XES feature, the SYSPLEX control option must be entered. Thiscontrol option contains the in<strong>for</strong>mation necessary <strong>for</strong> <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> tocommunicate with the sysplex using the proper structure <strong>and</strong> group names.For more details, see the Control Options Guide.Managing the Coupling Facility<strong>OS</strong>/390 <strong>and</strong> <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> use the definitions in the Coupling FacilityResource Management (CFRM) policy when managing the Coupling Facilitystorage. The CFRM policy resides in a CFRM couple data set which the systemprogrammer creates using the IBM IXCL1DSU <strong>for</strong>mat utility program. To createthe administrative CFRM policies, the systems programmer uses the IBM utilityprogram IXCMIAPU. You can activate, change or rebuild the CFRM policy usingthe <strong>OS</strong>/390 operator comm<strong>and</strong> SETXCF.3–6 Cookbook
Managing the Coupling FacilityCFRM PolicyTo set up the CFRM policy, the systems programmer must know whichsubsystems <strong>and</strong> applications in the installation will use the Coupling Facility <strong>and</strong>the structure requirements of each.Using the IBM utility program IXCMIAPU, define the CFRM policy to:■■■■Identify each Coupling Facility <strong>and</strong> each structure.Specify the size of each structure. The structure size will initially be allocatedat the INITSIZE you specify. The maximum size of the structure is definedby SIZE. Use the TSSFAR utility to run a TSSFAR ACIDCHAN report, whichwill recommend the XES structure size. You can use this to help determinethe structure size you want to specify in the CFRM policy. Otherconsiderations are discussed in the IBM guide MVS Setting Up a Sysplex.Specify the preference list (PRELIST), which is an ordered list of CouplingFacility names in which the structure can be allocated.Specify an exclusion list of structures that are not to be allocated in the sameCoupling Facility as the structure.Every application specifies the required structure types, as well as the name <strong>and</strong>size of the structure or structures it uses. <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> uses the SYSPLEXcontrol option to provide this in<strong>for</strong>mation. For details on the SYSPLEX controloption, see the Control Options Guide.For further in<strong>for</strong>mation regarding the CFRM policy, see the IBM guide MVSSetting Up a Sysplex.Altering the Coupling Facility Structure Size<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> supports dynamic system-managed resizing or rebuildingof the Coupling Facility structure. You can use the SECXCF <strong>OS</strong>/390 operatorcomm<strong>and</strong> to increase the Coupling Facility structure size with no disruption tothe connected systems.Use the following comm<strong>and</strong> to increase the structure size up to the SIZE value,which is the maximum size defined in the active Coupling Facility resourcemanagement (CFRM) policy:SETXCF START,ALTER,STRNAME=strname,SIZE=nnnHowever, if the optional initial size (INITSIZE) value was not specified in theCFRM policy, the structure size cannot be increased. In this case, the structurewould have been initially allocated based on the maximum SIZE value, ratherthan the INITSIZE. If the structure is already at the maximum size specified inthe CFRM policy, the CFRM must be modified to allow a larger structure sizeusing the SETXCF START, REBUILD comm<strong>and</strong>.Using the Sysplex Coupling Facility 3–7
Managing the Coupling FacilityWhen a structure ALTER processing completes, each connected system is postedby the Computer Associates security Coupling Facility service (<strong>CA</strong>SECCFS) toallow those systems to update the size <strong>and</strong> utilization counts <strong>for</strong> the connectedstructure.Note: To display in<strong>for</strong>mation about the current Coupling Facility XES structure,use the TSS MODIFY(STATUS(SYSPLEX)) comm<strong>and</strong>. The following sysplexrelated data will appear in message TSS9661I:CURRENT STRUCTURE SIZE—Current allocated sizeMAX STRUCTURE SIZE—Maximum structure sizeNUMBER OF STRUCTURE ENTRIES—Current entry countMAX NUMBER OF STRUCTURE EXTRIES—Maximum possible entry countAn example of message TSS9661I follows:TSS9661I <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> SYSPLEX StatusCF CONNECT NAME(XE11 ) XCF GROUP(TSSXCF )STRUCTURE NAME(SECURITY3 ) ACTIVATEDCURRENT STRUCTURE SIZE( 10240K)MAX STRUCTURE SIZE( 16128K)NUMBER OF STRUCTURE ENTRIES( 132)MAX NUMBER OF STRUCTURE ENTRIES( 1223)Rebuilding the Coupling Facility StructureAfter you have updated the CFRM policy with new structure attributes such asSIZE or INITSIZE, you can use the SETXCF <strong>OS</strong>/390 operator comm<strong>and</strong> torebuild the Coupling Facility structure characteristics based on the new CFRMpolicy changes. The rebuild is per<strong>for</strong>med with minimum disruption to theconnected systems.Use the following comm<strong>and</strong> to initiate the rebuild process based on the newCFRM policy structure attributes, while connected systems remain connected tothe structure.SETXCF START,REBUILD,STRNAME=strnameDuring the rebuild process, the system defers any requests that are issued whilethe structure is unavailable. These requests are processed after the rebuildprocess has completed.3–8 Cookbook
Defining SYSTEM LOGGER to <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>The following requirements apply to the system-managed rebuild:■■■■Coupling facility has to be at CFLEVEL=8 or higher.The structure has at least two entries in the CFRM PREFLIST.All systems using the CFRM couple data set must be at <strong>OS</strong>/390 version 8 orhigher.The CFRM couple data set must be <strong>for</strong>matted with the ITEMNAME(SMREBLD) NUMBER(1) statement.Connecting to the StructureAt startup, or through a start comm<strong>and</strong>, <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> attempts toconnect to the defined structures in the Coupling Facility. If successful, <strong>eTrust</strong><strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> attempts to use the Coupling Facility <strong>for</strong> all I/O direct requestsbeing made <strong>for</strong> the defined file.Defining SYSTEM LOGGER to <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>System logger is an <strong>OS</strong>/390 component that allows an application to log datafrom different systems across a sysplex. A system logger application can besupplied by:■■■IBM, <strong>for</strong> example the CICS log manager <strong>and</strong> the operations log stream(OPERLOG)Independent software vendorsYour installationA system logger application can merge the log data from systems across thesysplex into a log stream. A log stream is simply a collection of data in log blocksresiding in a coupling facility list structure, on DASD, or on both.Using the Sysplex Coupling Facility 3–9
Defining SYSTEM LOGGER to <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>Setting up the <strong>OS</strong>/390 CICS log manager with <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> involves thefollowing steps:Step 1—Follow substep A or B to define the IXGLOGE address space <strong>and</strong> therequired SAF authorizations.■Define IXGLOGR in the Started Task table to bypass SAF calls:or■TSS ADD(STC) PROCNAME(IXGLOGR) ACID(BYPASS)This bypasses all SAF calls <strong>and</strong>, there<strong>for</strong>e, does not require additionalresource permits.Define IXGLOGR in the Started Task table:TSS ADD(STC) PROCNAME(IXGLOGR) ACID(ixglogr)Permit access to the log stream coupling facility structures.TSS ADD(dept) IBMFAC(IXLSTR.structure_name)TSS PER(ixglogr) IBMFAC(IXLSTR.structure_name) ACCESS(ALL)Permit access to the DASD log stream <strong>and</strong> staging data sets.TSS ADD(dept) DSNAME(hlq.data_set_name)TSS PER(ixglogr) DSNAME(hlq.data_set_name) ACCESS(ALL)The default hlq is IXGLOGR if none is specified on the HLQ parm of theDEFINE LOGSTREAM statement.Permit access to the systems SYSx.PARMLIBTSS ADD(dept) DSNAME(SYS1.PARMLIB)TSS PER(ixglogr) DSNAME(SYS1.PARMLIB) ACCESS(READ)Step 2—Control which applications can access the system logger resources.For logrec log stream, CICS log manager, <strong>and</strong> OPERLOG system loggerapplication, define access to the log stream.TSS ADD(dept) LOGSTRM(log_stream_name)TSS PER(acid) LOGSTRM(log_stream_name) ACCESS(UPDATE)Step 3—Authorize who can use the IXCMIAPU utility.Define authorizations to use IXCMIAPU.TSS ADD(dept) IBMFAC(MVSADMIN.)TSS PER(acid) IBMFAC(MVSADMIN.) ACCESS(ALL)
AppendixA IMVSECURIMVSECUR//JOBNAME JOB//******************************************************************//* TOP SECRET SECURITY(TSS) VIA THE BATCH TMP (IKJEFT01) *//* This member contains the TSS COMMANDS that are used to define *//* the <strong>Top</strong> <strong>Secret</strong> authorizations needed to implement an <strong>OS</strong>/390 *//* environment. *//* These comm<strong>and</strong>s reflect default procnames as well as typical *//* GID <strong>and</strong> UID values , <strong>and</strong> typical group names. *//* The areas defined include: *//* *//* OpenEdition (Unix System Services <strong>for</strong> <strong>OS</strong>/390) *//* TCP/IP (Communications Server IP <strong>for</strong> <strong>OS</strong>/390) *//* FTP (Packaged with TCP/IP) *//* Lotus Domino Go Webserver (WebSphere Appl Server <strong>for</strong> os/390 *//* Firewall Technologies *//* LDAP <strong>Security</strong> *//* *//* INSTRUCTIONS: *//* 1. INSERT A VALID JOB<strong>CA</strong>RD(ABOVE). *//* 2. TAILOR THE PROC STATEMENT AND TSSIN-DD TO MEET *//* YOUR SITE STANDARDS. *//* 3. SUBMIT THIS JOB. *//* *//******************************************************************//TSSTMP PROC PRINT=A /* SYSOUT O/P DESTINATION *///TSSTMP EXEC PGM=IKJEFT01,REGION=300K//SYSPRINT DD SYSOUT=&PRINT//SYSTSPRT DD SYSOUT=&PRINT,// DCB=(LRECL=133,BLKSIZE=133,RECFM=FA)//SYSTSIN DD DDNAME=TSSIN// PEND//*//BACKTMP EXEC TSSTMP//TSSIN DD *IMVSECUR A–1
IMVSECUR/*======================================================================*//* OpenEdition setup. *//*======================================================================*/TSS CRE(OMVSGRP) TYPE(GROUP) NAME('DEFAULT OMVS GROUP') DEPT(anydept)TSS ADD(OMVSGRP) GID(1)TSS CRE(TTY) TYPE(GROUP) NAME('REQ''D OMVS TTY GROUP') DEPT(anydept)TSS ADD(TTY) GID(2)TSS CRE(OMVSKERN) TYPE(USER) NAME('OPENMVS STC ID') -DEPT(anydept) FAC(STC,APPC) PASSWORD(password,0)TSS ADD(OMVSKERN) UID(0) GROUP(OMVSGRP,TTY) -DFLTGRP(OMVSGRP)TSS CRE(INETD) TYPE(USER) NAME('OMVS INETD STC') DEPT(anydept) -FAC(STC) PASSWORD(password,0)TSS CREATE(BPXROOT) TYPE(USER) NAME('BPXROOT ACID') DEPT(anydept) -FAC(APPC) PASSWORD(password,0)TSS ADD(BPXROOT) GROUP(OMVSGRP) DFLTGRP(OMVSGRP) UID(0)TSS ADD(INETD) UID(0) GROUP(OMVSGRP) DFLTGRP(OMVSGRP) -HOME(/) OMVSPGM(/bin/sh)TSS ADD(STC) PROC(OMVS) ACID(OMVSKERN)TSS ADD(STC) PROC(BPXOINIT) ACID(OMVSKERN)TSS ADD(STC) PROC(BPXAS) ACID(OMVSKERN)TSS ADD(STC) PROC(INETD) ACID(INETD)/*======================================================================*//* TCP/IP setup. *//*======================================================================*/TSS CRE(TCPIP) TYPE(USER) NAME('TCP/IP STC ID') DEPT(anydept) -FAC(STC,BATCH) PASSWORD(password,0) -NOVOLCHK NODSNCHK NORESCHK NOLCFCHK N<strong>OS</strong>UBCHKTSS ADD(TCPIP) UID(0) GROUP(OMVSGRP) DFLTGRP(OMVSGRP) -HOME(/) OMVSPGM(/bin/sh)TSS ADD(STC) PROC(TCPIP) ACID(TCPIP)/* *//*======================================================================*//* FTP setup. *//*======================================================================*/TSS CRE(FTP) TYPE(USER) NAME('FTP STC ID') DEPT(anydept) -FAC(STC,BATCH) PASSWORD(password,0) MASTFAC(TCP) -NOVOLCHK NODSNCHK NORESCHK NOLCFCHK N<strong>OS</strong>UBCHKTSS ADD(FTP) UID(0) GROUP(OMVSGRP) DFLTGRP(OMVSGRP) -HOME(/) OMVSPGM(/bin/sh)TSS ADD(STC) PROC(FTPSERVE) ACID(FTP)A–2 Cookbook
IMVSECUR/*======================================================================*//* Domino Go WebServer setup. *//*======================================================================*//* *//* Facility setup. *//* */TSS MODIFY FAC(USERx=NAME=IMWEB)/* *//* Acid <strong>for</strong> Web Server started-task *//* */TSS CRE(IMWEB) TYPE(GROUP) NAME('WEBSERVER GROUP') DEPT(anydept)TSS ADD(IMWEB) GID(205)TSS CRE(WEBADM) TYPE(USER) NAME('WEB ADMINISTRATOR') -DEPT(anydept) FAC(IMWEB) PASSWORD(password)TSS ADD(WEBADM) UID(206) GROUP(IMWEB) DFLTGRP(IMWEB) -HOME(/usr/lpp/internet) OMVSPGM(/bin/sh)TSS CRE(WEBSRV) TYPE(USER) NAME('WEBSERVER DAEMON/STC') -DEPT(anydept) FAC(STC,IMWEB) PASSWORD(password,0)TSS ADD(WEBSRV) UID(0) GROUP(IMWEB) DFLTGRP(IMWEB) -HOME(/usr/lpp/internet) OMVSPGM(/bin/sh) -MASTFAC(IMWEB)TSS ADD(STC) PROC(IMWEBSRV) ACID(WEBSRV)/* *//* Acids to allow access to Web Server without signon *//* */TSS CRE(EXTERNAL) TYPE(GROUP) NAME('WEB GROUP') DEPT(anydept)TSS ADD(EXTERNAL) GID(999)TSS CRE(EMPLOYEE) TYPE(GROUP) NAME('WEB GROUP') DEPT(anydept)TSS ADD(EMPLOYEE) GID(500)TSS CRE(SPECIAL) TYPE(GROUP) NAME('WEB GROUP') DEPT(anydept)TSS ADD(SPECIAL) GID(255)TSS CRE(PUBLIC) TYPE(USER) NAME('WEB SURROGATE ID') -DEPT(anydept) FAC(IMWEB) PASSWORD(NOPW,0)TSS ADD(PUBLIC) UID(998) GROUP(EXTERNAL) DFLTGRP(EXTERNAL) -HOME(/) OMVSPGM(/bin/sh)TSS CRE(INTERNAL) TYPE(USER) NAME('WEB SURROGATE ID') -DEPT(anydept) FAC(IMWEB) PASSWORD(NOPW,0)TSS ADD(INTERNAL) UID(537) GROUP(EMPLOYEE) DFLTGRP(EMPLOYEE) -HOME(/) OMVSPGM(/bin/sh)TSS CRE(PRIVATE) TYPE(USER) NAME('WEB SURROGATE ID') -DEPT(anydept) FAC(IMWEB) PASSWORD(NOPW,0)TSS ADD(PRIVATE) UID(416) GROUP(SPECIAL) DFLTGRP(SPECIAL) -HOME(/) OMVSPGM(/bin/sh)/* *//* Allow Web Server started-task acid to access *//* resources IBMFAC <strong>and</strong> SURROGAT *//* */TSS ADD(anydept) IBMFAC(BPX.)TSS PERMIT(WEBSRV) IBMFAC(BPX.DAEMON) ACCESS(READ)TSS PERMIT(WEBSRV) IBMFAC(BPX.SERVER) ACCESS(UPDATE)TSS ADD(anydept) SURROGAT(BPX.)TSS PERMIT(WEBSRV) SURROGAT(BPX.SRV.WEBADM) ACCESS(READ)TSS PERMIT(WEBSRV) SURROGAT(BPX.SRV.PUBLIC) ACCESS(READ)TSS PERMIT(WEBSRV) SURROGAT(BPX.SRV.PRIVATE) ACCESS(READ)TSS PERMIT(WEBSRV) SURROGAT(BPX.SRV.INTERNAL) ACCESS(READ)/* *//* Give all users access to the three load libraries *//* related to the Web Server. *//* */TSS ADD(anydept) DSNAME(CEE.)TSS ADD(anydept) DSNAME(IMW.)TSS ADD(anydept) DSNAME(SYS1.)TSS PERMIT(ALL) DSNAME(CEE.V1R5M0.SCEERUN) ACCESS(READ)TSS PERMIT(ALL) DSNAME(IMW.V1R1M0.IMWMOD1) ACCESS(READ)TSS PERMIT(ALL) DSNAME(SYS1.LINKLIB) ACCESS(READ)IMVSECUR A–3
IMVSECUR/*=====================================================================*//* <strong>OS</strong>/390 Firewall setup. *//*=====================================================================*/TSS CRE(FWGRP) TYPE(GROUP) NAME('FIREWALL GROUP') DEPT(anydept)TSS ADD(FWGRP) GID(nn) any unused GID number is allowed/* */TSS CRE(FWKERN) TYPE(USER) NAME('FIREWALL STARTUP ID') -DEPT(anydept) FAC(STC,BATCH) PASS(password,0)TSS ADD(FWKERN) GROUP(FWGRP) DFLTGRP(FWGRP) -HOME(/usr/lpp/fw/home/fwkern/) OMVSPGM(/bin/sh) UID(0)TSS ADD(STC) PROCNAME(FWKERN) ACID(FWKERN)SS MODIFY(OMVSTABS)/* */TSS ADD(STC) PROCNAME(I<strong>CA</strong>PSLOG) ACID(FWKERN)TSS ADD(STC) PROCNAME(I<strong>CA</strong>PSOCK) ACID(FWKERN)TSS ADD(STC) PROCNAME(I<strong>CA</strong>PPFTP) ACID(FWKERN)TSS ADD(STC) PROCNAME(I<strong>CA</strong>PTNAT) ACID(FWKERN)/*TSS ADDTO(anydept) DSN(TCPIP.)TSS PERMIT(FWKERN) DSN(TCPIP.) ACCESS(READ)/* */TSS PERMIT(FWKERN) IBMFAC(BPX.SMF) ACCESS(READ)/* *//* To give administrators access to FWGRP *//* */TSS ADDTO(acid) GROUP(FWGRP)/* *//* *//* Define <strong>and</strong> give ICFS services */TSS ADDTO(anydept) CSFSERV(service-name)TSS PERMIT(acid) CSFSERV(service-name) ACCESS(READ)/* *//*======================================================================*//* LDAP setup. *//*=====================================================================*/TSS CRE(LDAPGRP) TYPE(GROUP) NAME('LDAP GROUP') DEPT(anydept)TSS ADD(LDAPGRP) GID(nn) any unused GID number is allowed/* */TSS CRE(LDAPSRV) TYPE(USER) NAME('LDAP STARTUP ID') -DEPT(anydept) FAC(STC,BATCH) PASS(password,0)TSS ADD(LDAPSRV) GROUP(LDAPGRP) DFLTGRP(LDAPGRP) -HOME(/) OMVSPGM(/bin/sh) UID(0)TSS ADD(STC) PROCNAME(LDAPSRV) ACID(LDAPSRV)TSS MODIFY(OMVSTABS)/* */TSS PERMIT(LDAPSRV) IBMFAC(BPX.DAEMON) ACCESS(READ)TSS PERMIT(LDAPSRV) IBMFAC(BPX.SERVER) ACCESS(UPDATE)/* *//* To give administrators access to LDAPGRP */TSS ADDTO(acid) GROUP(LDAPGRP)/*A–4 Cookbook
AppendixBRACF to <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>TranslationMany applications <strong>and</strong> products describe the setup <strong>for</strong> external security in RACFterms. The purpose of this Appendix is to describe what the RACF terminologymeans so a <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> administrator can take the in<strong>for</strong>mation <strong>and</strong>create the necessary <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> records to implement it.Use the following chart to check the corresponding <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> feature.Feature RACF <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>Users/GroupsResourceProtectionSPECIAL GroupconceptData SetsDASD volumesTape volumesTerminalsLoad modules(programs)IMS applicationgroup names(AIMS)IMS transactions(TIMS <strong>and</strong> GIMS)IMS applicationsCICS PSBsCICS transactionsCICS filesCICS journalsCICS programsMS<strong>CA</strong>, LS<strong>CA</strong>s, Zones, Divisions,Departments, Profiles, ACIDsData Sets (DSN)DASD volumes (VOL)Tape volumes (VOL)Terminals (TERM, SOURCE)Programs (PROG)IMS applications (APPL)Transactions via Limited Comm<strong>and</strong> Facility(LCF) or protected resources (OTRAN)Facility checkingCICS PSBsTransactions via Limited Comm<strong>and</strong> Facility(LCF) or protected resources (OTRAN)CICS files (FCT)CICS journals (JCT)CICS programs (PPT)RACF to <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> Translation B–1
IMVSECURFeature RACF <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>Resourceprotection(cont’d)AccessauthorizationsCICS transientdata destinationsCICS temporarystorage definitionsInstallation-defined resources (CDT)PERMIT comm<strong>and</strong>CICS destinations (DCT)CICS temporary storage (TST)Installation-defined resources (RDT)TSS PERMIT comm<strong>and</strong>UACCTSS PERMITs in the ALL RecordUser Privileges SPECIAL MS<strong>CA</strong> <strong>and</strong> S<strong>CA</strong> with administrativeauthoritiesAUDITOROPERATIONSCLAUTHGRPACCNODSNCHK, NOVLCHK, <strong>and</strong> NORESCHKattributesS<strong>CA</strong> with MISC1, RES(REPORT) <strong>and</strong>DATA(ALL) authoritiesAdministrator with specifically namedresource XAUTH authorityPROFILEsAdministration RACF comm<strong>and</strong>s TSS comm<strong>and</strong>sReports <strong>and</strong>ListingsISPF panelsRACF ReportWriterDSMON UtilitySETROPS ListOutputLISTUSER OutputPanels <strong>for</strong> different facilities (TSO,<strong>CA</strong>-Roscoe, CICS <strong>and</strong> IMS)TSSUTIL, TSSTRACKTSSAUDIT, TSS LIST, TSS WHOHAS <strong>and</strong>TSS WHOOWNSTSS LISTTSS LISTCustomization Exits Exists <strong>and</strong> interfacesOther featuresUserididentificationLoggingStarted TasksACID identificationLoggingSTC facilityB–2 <strong>Security</strong> Cookbook
ADDGRPADDGRPThe ADDGRP comm<strong>and</strong> is used to add a group definition. For example:ADDGRP OMVSGRP OMVS(GID(1))In <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>, this would be a profile record as follows:TSS ADD(OMVSGRP) GID(1)ADDUSERRACF uses the ADDUSER comm<strong>and</strong> to define a new user to its database <strong>and</strong> todefine the profile in<strong>for</strong>mation necessary to allow that user to use the desiredcomponents of the system. <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> does the same using ACID <strong>and</strong>PROFILE records. The ADDUSER comm<strong>and</strong> is the same as the ADD comm<strong>and</strong>in <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>. For example:ADDUSER USER01 DFLTGRP(OMVSGRP) OMVS(UID(200) HOME(/) PROGRAM(/bin/sh))PASSWORD(password)In <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>, this would be rendered as follows:TSS CREATE(USER01) TYPE(USER) DEPARTMENT(dept1) PASSWORD(password,0)TSS ADDTO(USER01) GROUP(OMVSGRP) UID(0) HOME(/) PROGRAM(/bin/sh)ALTUSERRACF uses the ALTUSER comm<strong>and</strong> to change an existing user’s profile. Forexample:ALTUSER USER01 CICS(OPCLASS(10) OPIDENT(U01) TIMEOUT(30))In <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>, this would be a change to the Acid record as follows:TSS ADD(USER01) OPCLASS(10) OPID(U01) OPTIME(30)CLASSIn RACF, with the exception of DATASET, USER, <strong>and</strong> GROUP classes, theentries in the class descriptor table (CDT) represent all resource classes both <strong>for</strong>MVS <strong>and</strong> VM. The CDT consists of two modules: one is <strong>for</strong> IBM-supplied entries,the other is <strong>for</strong> installation-defined entries.RACF to <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> Translation B–3
PERMITIn <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>, all resources <strong>for</strong> both VM <strong>and</strong> MVS are defined in theResource Descriptor Table (RDT). Resources are predefined by <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong><strong>Secret</strong> or dynamically defined by the particular installation.PERMITThe RACF PERMIT comm<strong>and</strong> allows access to resources. The PERMIT comm<strong>and</strong>also exists in <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>. Use the TSS PERMIT comm<strong>and</strong> function toallow designated users to access the indicated data sets in an unlimited or arestricted manner. Restrictions are indicated by incorporating the appropriatePERMIT parameter. For example, the following RACF PERMIT allows USER01to read data set SYS1.PARMLIB:PERMIT SYS1.PARMLIB CLASS(DATASET) ID(user01) ACCESS(READ)In <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>, this would be a permit:TSS PERMIT(user01) DSNAME(SYS1.PARMLIB) ACCESS(READ)RDEFINERDEFINE is used to define resources to RACF.In <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>, the Resource Descriptor Table is a special ACID that isused to define resource classes <strong>and</strong> their properties. The RDT containspredefined TSS resource classes, including resources used by other ComputerAssociates product interfaces. It also contains dynamically defined resourceclasses. To administer the contents of the RDT Record, the TSS administrator canspecify attributes, access levels, <strong>and</strong> default access levels using the TSS ADDcomm<strong>and</strong>. The following is an example of creating a User defined resource in<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> using the TSS ADD comm<strong>and</strong>:TSS ADD(RDT) RESCLASS(xx)RESCODE(nn)ACLST(ALL=FFFF,UPDATE=6000,READ=4000,CREATE=1000,NONE=0000) ATTR(LONG)B–4 <strong>Security</strong> Cookbook
RACF Attribute TranslationRACF Attribute TranslationThe following table shows how <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> translates a RACFattribute. <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> does provide additional access levels <strong>for</strong> moregranular control.RACF AttributeREADUPDATEALTERCONTROL<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> Access LevelREADUPDATEALLCONTROLRACF to <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> Translation B–5
Indexcomponent names <strong>for</strong> z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390, 1-4CRITMAP, 1-77Aaccessing USS, 1-8Authorized data setswith program control, 2-3authorizing servers <strong>for</strong> WebSphere, 1-36authoriztion checking <strong>for</strong> WebSphere, 1-38BBPX facility resources, 1-12BPX.DAEMON, 2-3BPX.SAFFASTPATH, 2-3BPX.SERVER, 2-3CCertificate name filtering, 1-73CERTMAP, 1-75CHKCERT, 1-64CLIST <strong>for</strong> WebSphere, 1-43, 1-70, 1-43, 1-70CNF. See certificate name filtering. See certificatename filteringCryptographic Services support, 1-99DDB2 <strong>Security</strong> Exit support, 1-99DCDSN, 1-62DCE <strong>Security</strong> Server support, 1-96DFS SMB support, 1-91DIGICERT, 1-53Digital certificate support, 1-51associating a certificate with a user, 1-52changing a user, 1-61changing certificate, 1-62, 1-63, 1-62, 1-63determining who has a certificate, 1-64exporting a certificate to a data set, 1-64generating a certificate, 1-55key rings, 1-66listing certificates, 1-60removing a certificate, 1-63sharing certificates, 1-66verifying a certificate, 1-61Dirty bit, 2-3EEJBROLE, 1-5Enterprise Java Bean (EJB) support, 1-5<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> implementation, 1-1Index–1
FIFAC rule, 2-3FACILITY resourcesBPX.DAEMON, 2-3BPX.SAFFASTAUTH, 2-3BPX.SERVER, 2-3FASTAUTH processing, 2-3File securitybypassing, 2-3Firewall Technologies support, 1-97fixes, installing, 1-2FTPhow to secure, 1-33how to secure <strong>for</strong> OpenEdition, 1-33using, 1-32FUNCUNIX System Services, 1-20GGEJBROLE, 1-5GID, 1-14GID table refresh, 1-12GROUP ACIDcreating, 1-13implementing<strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390, 1-1ISCF support, 1-99KKEYRINGS, 1-66LLABLCERT, 1-60, 1-63, 1-60, 1-63LDAP <strong>Security</strong> Server support, 1-98LDAP server support, 1-6Lotus Domino Go Webserver, how to secure, 1-36,1-47, 1-50, 1-51, 1-36, 1-47, 1-50, 1-51MMOUNT N<strong>OS</strong>ECURITY, 2-3NHHierarchical File System (HFS), 2-1FASTAUTH checking, 2-3processes that affect security, 2-3program control, 2-3HOME keyword, 1-8hyper fixes, installing, 1-3NFS support, 1-92N<strong>OS</strong>ECURITY MOUNT option, 2-3OOMVSPGM keyword, 1-8OpenEdition MVS, 1-6Index–2Cookbook
OpenEdition MVS supportACIDs needed <strong>for</strong> installation, 1-13creating superuser ACID, 1-15, 1-16, 1-18, 1-15,1-16, 1-18defining OMVS started task ACID, 1-13defining OMVS started task ACIDs, 1-15TSO ISHELL support, 1-15PProgram control in the UNIX environment, 2-3RR_cacheserv, 1-5R_proxyserv, 1-5RACF, 1-95attribute translation, 5terminology translation, 1release-specific security requirements, 1-4SSAF callable services, 1-5SAFDEF<strong>for</strong> HFS FASTAUTH, 2-3security requirements by z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390component, 1-4<strong>Security</strong> server support, 1-51Server Message Block support, 1-91STC ACID, 1-14Stopping SECTRACEUNIX System Services, 1-21Superuser ACID, 1-15, 1-16, 1-18, 1-19, 1-15, 1-16, 1-18,1-19SYSPLEXcontrolling access to XCF policies, 3-5coupling facility, 3-2list structure, 3-2XCF security, 3-3, 3-5, 3-3, 3-5XES security, 3-1, 3-3, 3-1, 3-3TTCBNCTL flag, 2-3TCP/IPestablishing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>, 1-29SERVAUTH Class, 1-30using, 1-29TELNET, 1-35how to secure <strong>for</strong> OpenEdition, 1-35TSO ISHELL support, 1-15TTY, 1-13UUID, 1-8UID table refresh, 1-12UNIX System Services (USS), 1-6UNIX System Services supportcontrolling access, 1-8GROUP profile records, 2-2UNIX System Services, SAF SECTRACE OMVSFUNC, 1-20upgrade solutions, 1-2USS supportassigning users to groups, 1-10changing default group, 1-10, 1-12, 1-10, 1-12creating superuser ACID, 1-19defining groups, 1-9defining users, 1-8WWASADM CLIST, 1-43, 1-70, 1-43, 1-70WebSphere support, 1-36WebSphere user indentification, 1-40WLM (Workload Management, 1-94Index–3
XZXCF(*) control option, 3-5z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390<strong>eTrust</strong> <strong>CA</strong>--<strong>Top</strong> <strong>Secret</strong> implementation, 1-1z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 component names, 1-4z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 Firewall Technolgies, 1-97z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 <strong>Security</strong> ServerRACF, 1-95z/<strong>OS</strong> <strong>and</strong> <strong>OS</strong>/390 <strong>Security</strong> Server support, 1-94Index–4Cookbook
Change language