Use of WARN mode under TSSDB2
Document ID : KB000100368
Last Modified Date : 06/06/2018
 Show Technical Document Details
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.