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
Tracing UNIX System Services (OMVS)Security Credentials and File Security PacketsMany log entries show additional information about the request. Theinformation is contained internally as Security Credentials (CRED) and FileSecurity Packets (FSP). This information is common to many calls and can appearin the following fields on the TSSOERPT report if it is available:FUNCTION—The function attempted for 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 for 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, and 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 for the file's owning UID (owner),the file's owning GID (group) and all others attempting access (other).OWNING UID—UID of the owner of the file or directory. If the real UID of 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 and Filename are for this call, find the last previous callwith the same File Identifier. The Pathname and Filename for that call are thesame as for 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 for 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 for the user.Auditor—Indicates the type of file access that should be logged for 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 for the auditor.Using TCP/IPTCP/IP (Transmission Control Protocol/Internet Protocol) is a file transferprotocol used to store and forward jobs between nodes. TCP/IP is the protocolused on the Internet, which allows computers to talk to each other, and is wellestablished in the midrange and PC platforms.Prior to OS/390 V2R5, TCP/IP ran as a native MVS application, or as an UNIXSystem Services application. Starting with OS/390 V2R5, TCP/IP relies on UNIXSystem Services and must be configured as an UNIX System Services application.Security configuration depends on the environment in which it runs.Establishing Security for TCP/IP and OE/TCPIP (Communications Server IP for z/OSand OS/390)To establish a proper security connection, you must follow these steps.Step 1—Define TCP/IP to eTrust CA-Top Secret.To define TCP/IP to eTrust CA-Top Secret, you must add a facility definition forTCP/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 eTrust CA-Top Secret in a z/OS or OS/390 Environment 1–29
- Page 1 and 2: eTrust CA-Top Secret ® Securityfo
- Page 3: Technical UpdatesMay 2003The follow
- Page 6 and 7: Superuser Granularity .............
- Page 8 and 9: WLM (Workload Management)..........
- Page 11 and 12: Chapter1Implementing eTrust CA-TopS
- Page 13 and 14: z/OS and OS/390 CompatibilityThe li
- Page 15 and 16: z/OS and OS/390 Release-Specific Se
- Page 17 and 18: OpenEdition MVS / UNIX System Servi
- Page 19 and 20: OpenEdition MVS / UNIX System Servi
- Page 21 and 22: OpenEdition MVS / UNIX System Servi
- Page 23 and 24: OpenEdition MVS / UNIX System Servi
- Page 25 and 26: OpenEdition MVS / UNIX System Servi
- Page 27 and 28: OpenEdition MVS / UNIX System Servi
- Page 29 and 30: OpenEdition MVS / UNIX System Servi
- Page 31 and 32: Tracing UNIX System Services (OMVS)
- Page 33 and 34: Tracing UNIX System Services (OMVS)
- Page 35 and 36: Tracing UNIX System Services (OMVS)
- Page 37: Tracing UNIX System Services (OMVS)
- Page 41 and 42: Using TCP/IPwheresysname is the nam
- Page 43 and 44: Using FTPHow to Secure FTPFTP runs
- Page 45 and 46: Using TELNETTerminal Source Restric
- Page 47 and 48: WebSphere Application Server for z/
- Page 49 and 50: WebSphere Application Server for z/
- Page 51 and 52: WebSphere Application Server for z/
- Page 53 and 54: WebSphere Application Server for z/
- Page 55 and 56: WebSphere Application Server for z/
- Page 57 and 58: Lotus Domino Go Webserver/* PERMITT
- Page 59 and 60: Lotus Domino Go WebserverTo disable
- Page 61 and 62: Lotus Notes and Novell Directory Se
- Page 63 and 64: Digital Certificate SupportGeneral
- Page 65 and 66: Digital Certificate SupportFOR|UNTI
- Page 67 and 68: Digital Certificate SupportDCDSN(re
- Page 69 and 70: Digital Certificate SupportNote: In
- Page 71 and 72: Digital Certificate SupportYou can
- Page 73 and 74: Digital Certificate SupportCase #2.
- Page 75 and 76: Digital Certificate SupportImportan
- Page 77 and 78: Digital Certificate SupportAdding a
- Page 79 and 80: Digital Certificate SupportReconnec
- Page 81 and 82: Digital Certificate SupportTSS LIST
- Page 83 and 84: Certificate Name Filtering SupportT
- Page 85 and 86: Certificate Name Filtering SupportI
- Page 87 and 88: Certificate Name Filtering SupportD
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