|
Issue:
Warn Mode does not work the same in TSSDB2 as it does in Top Secret.
TSS/DB2 was developed after TSSMVS was setup in most sites. Rather than
force sites to permit users MODE(WARN) to test TSS/DB2, TSS/DB2 was
designed to use the mode on the DB2 subsystem facility for calls from
DB2.
Resolution:
OPTIONS(40) in the TSS parameter file disables the TSS/DB2 subsystem
mode. Setting OPTIONS(40) (and recycling TSS) should cause the security
calls from the DB2 subsystems to use the WARN mode permit on the acid.
Below describes how Warn Mode works in TSSDB2.
Use of WARN mode under TSS/DB2:
The following is a TSSUTIL Report for when SELECT is requested in FAIL mode and a secondary authid has DBADM.
06/05/18 16:12:47 XE56 TCSFJA TCSFJA DB2TEST FAIL DSNECP10 DBADM ALL OK+A
RESOURCE TYPE & NAME : DB2DBASE FJADBA
This is a TSSUTIL Report for when SELECT is requested in WARN mode for the same secondary authid which has DBADM.
06/05/18 16:43:26 XE56 FJAU1 TCSFJA DB2TEST WARN DSNECP10 SELECT NONE *08*-88
RESOURCE TYPE & NAME : DB2TABLE FJATBLA.DAYS2000
06/05/18 16:43:26 XE56 FJAU1 TCSFJA DB2TEST WARN DSNECP10 DBADM NONE *08*-88
RESOURCE TYPE & NAME : DB2DBASE FJADBA
06/05/18 16:43:26 XE56 FJAU1 TCSFJA DB2TEST WARN DSNECP10 NONE *08*-88
RESOURCE TYPE & NAME : DB2SYS DATAACCESS
06/05/18 16:43:26 XE56 FJAU1 TCSFJA DB2TEST WARN DSNECP10 NONE *08*-88
RESOURCE TYPE & NAME : DB2SYS SYSADM
06/05/18 16:43:26 XE56 TCSFJA TCSFJA DB2TEST WARN 01 DSNECP10 SELECT NONE *08*-88
RESOURCE TYPE & NAME : DB2TABLE FJATBLA.DAYS2000
06/05/18 16:43:26 XE56 TCSFJA TCSFJA DB2TEST WARN DSNECP10 DBADM ALL OK+A
RESOURCE TYPE & NAME : DB2DBASE FJADBA
Warn mode is tricky when used for TSS/DB2 resource checking. The reason is complicated to explain but is as follows:
TSS/DB2 performs at least one security check to verify access to a DB2 resource. There is also the possibility many resource checks may occur. TSS/DB2 will log only the relevant security checks in any particular case. So the resource checks that occurred in FAIL vs WARN mode for the above example are identical. The only difference is which events are logged.
TSS/DB2 will be called for any DB2 resource access check once, in this case to see if the user has SELECT access to the DB2TABLE resource FJATBLA.DAYS2000. Under that DB2 check a series of checks can be issued as follows:
- A list of authids is determined that may provide access to the resource.
- The first ID is chosen, typically the Primary Authid.
- A set of privileges that may allow the access are determined. In this case:
- Select for the table itself
- DBADM for the database containing the table
- DB2SYS(DATAACCESS)
- DB2SYS(SYSADM)
- A series of checks are issued for each of these possibilities beginning at the lowest level, SELECT to the DB2TABLE. The security checks will be issued for each privilege listed above for the first authid. If all these events fail, as was the case for acid FJAU1, the next authid will be checked. In the above case that would be acid TCSFJA. This process will continue until the access is allowed or denied to all users in the authid list. If the calls all fail then the initial call will be issued against the initial acid/authid with logging so that the user can see what resource attempt failed
- Initially these calls are all issued with the RACROUTE parameter LOG=NOFAIL which states the event is to be logged ONLY if it is successful. This is key to this situation. In WARN mode virtually all security checks will be successful. Thus these calls will all log because they did not fail.
Of course this would yield the wrong results for the security calls since in FAIL mode many of these events would actually fail. Thus, within the TSS/DB2 code we look not only at the real return code from the call but also at what the return code would have been in FAIL mode. In most of the calls above we see those calls would have failed. For that reason we continue onward issuing call after call until we come upon a call that would actually have succeeded in FAIL mode. In the case above that is the DB2DBASE(FJADBA) ACCESS(DBADM) check. No further checks are required after this point as we know the call would succeed in FAIL mode.
- This process makes the reading of the TSSUTIL reports tedious due to the sheer volume of events that get logged for TSS/DB2 but it is usable once you understand the process. What you can see is this event would have been allowed because authid TCSFJA had DBADM for the database.
Keep in mind, it is CA's recommendation that permissions to resources be allowed at the lowest possible level whenever possible. This means that, ideally, you would allow access to authid FJAU1 for DB2TABLE(FJATBLA.DAYS2000) ACCESS(SELECT). This allows for the cleanest implementation with the least overhead and the optimal event logging. The use of secondary authids is discouraged unless it cannot be avoided. Instead, permissions should be placed into Top Secret profile acids attached to the primary authid acids.
|