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
Controlling HFS Using the Native UNIX Security ModelWhen group access checks are performed, eTrust CA-Top Secret compares theGID of the file to the GID of the default group defined in DFLTGRP. If thesedon’t match, eTrust CA-Top Secret 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 eTrust CA-Top Secret command:TSS ADD('acidname') GROUP('group name')If a match is found, eTrust CA-Top Secret uses group permissions to determinethe user's access to the file.Obtaining security information for a File within OpenEdition can be achieved byone of the following:■■■Use the OpenMVS ISPF ShellEnter the ls -l or ls -E shell commandRun a stat( ) or fstat( ) function in a programIn response, the system will display the TSO/E user ID and the eTrust CA-TopSecret group name that correspond to the file’s UID and GID permission bits.The system displays the UID and GID only if it cannot find the correspondingTSO/E user ID and eTrust CA-Top Secret group name. The informationreturned will include:■■■■Type of file or directoryOwner permission bitsGroup permission bitsOther permission bitsShell commands exist that change file/directory authorizations within the openedition arena. These shell commands include:CHMOD—Change permission bits for a file/directory.CHOWN—Change the owner or group for a file or directory.CHGRP—Change the group of a file.For more information about the Hierarchical File System and setting filepermissions, see these IBM documents: OS/390 OpenEdition User's Guide andOS/390 OpenEdition Planning.2–2 Cookbook
Controlling HFS Using the Native UNIX Security ModelProcesses that Affect HFS SecurityWhen using the UNIX security model, various options can affect the filevalidation process. The processes and their effect on file security or validationare described in this section.HFS FASTPATH CheckingAs of OS/390 V2R7, OMVS issues a SAF call at initialization. This SAF callchecks to see if access is authorized for OMVS to the FACILITY class resourceBPX.SAFFASTPATH. If access is allowed, OMVS performs 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 eTrust CA-Top Secret commands 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 NOSECURITYWith OS/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 commandrequires superuser authority. If the file system is mounted with theNOSECURITY 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 and BPX.SERVER facilities are active, processingauthorized functions, such as SETUID, requires that programs or executables beloaded from an authorized library. In a eTrust CA-Top Secret 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 and 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 command.Controlling Access to the Hierarchical File System 2–3
- 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
- Page 89 and 90: Certificate Name Filtering SupportL
- Page 91 and 92: KerberosKerberosetrust CA-Top Secre
- Page 93 and 94: KerberosThe command syntax for this
- Page 95 and 96: KerberosThe following command creat
- Page 97 and 98: Mapping of Foreign EnvironmentsMapp
- Page 99 and 100: Mapping of Foreign EnvironmentsMapp
- Page 101 and 102: Distributed File Server SMB SUPPORT
- Page 103 and 104: NFS (Network File System)The first
- Page 105 and 106: z/OS and OS/390 Security Server Sup
- Page 107 and 108: z/OS and OS/390 Security Server Sup
- Page 109 and 110: z/OS and OS/390 Security Server Sup
- Page 111: Chapter2Controlling Access to theHi
- Page 115 and 116: Controlling HFS Using CA SAF HFS Se
- Page 117 and 118: Securing HFS FunctionsKeywordALLCON
- Page 119 and 120: Securing HFS FunctionsFile Function
- Page 121 and 122: Implementing CA SAF HFS SecurityImp
- Page 123 and 124: HFSSEC Control Option+12—The addr
- Page 125 and 126: HFSSEC Control OptionDiagnosticsThe
- Page 127 and 128: HFSSEC Control OptionUNIX CMDCHMOD(
- Page 129 and 130: HFSSEC Control OptionTSSSUTIL EQUIV
- Page 131 and 132: HFSSEC Control OptionUNIX CMDS ACCE
- Page 133 and 134: HFSSEC Control OptionExample 1// JO
- Page 135 and 136: HFSSEC Control OptionExample 2// JO
- Page 137 and 138: MessagesMessagesCAS2301EEVENT PROCE
- Page 139 and 140: MessagesCAS2306Wxxxxxxxxxxxxxxx EVE
- Page 141: MessagesCAS2319ITRACEID=aaaaaaaa US
- Page 144 and 145: The SYSPLEX XES FunctionThere are t
- Page 146 and 147: eTrust CA-Top Secret and the SYSPLE
- Page 148 and 149: Defining the Sysplex to eTrust CA-T
- Page 150 and 151: Managing the Coupling FacilityWhen
- Page 152 and 153: Defining SYSTEM LOGGER to eTrust CA
- Page 154 and 155: IMVSECUR/*=========================
- Page 156 and 157: IMVSECUR/*=========================
- Page 158 and 159: IMVSECURFeature RACF eTrust CA-Top
- Page 160 and 161: PERMITIn eTrust CA-Top Secret, all
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
Change language