User Is Allowed To INSERT Into DB2 Table After TSS REVOKE But Should Not Be

Products

• Top Secret

Issue/Introduction

With Top Secret for DB2 (TSSDB2), a permit for DB2SYS(DATAACCESS) was revoked from an ACID and the ACID was refreshed (TSS REFRESH(acid) JOBNAME(*) ). TSSSIM says the ACID should NOT be able to do an INSERT into a DB2 table. The ACID was still allowed to do an INSERT on the yyyyyyyy.xxx* tables for another day or two before finally being denied. Why did it take so long for the TSS REVOKE and REFRESH commands to take effect?

Environment

Release : 1.3

Component : CA Top Secret for DB2

Resolution

The reason for the delay is the DB2 cache normally caches successful accesses, which is the case here. Manually refreshing the DB2 cache depends upon what resource access is cached. Here is an example of IBM's DB2 documentation on clearing the cache for plans and packages:

=====
Caching of EXECUTE on plans, packages, and routines
The results of authorization checks on the EXECUTE privilege for plans are not cached when those checks are performed by the authorization access control exit routine. The results of authorization checks on the EXECUTE privilege for packages and routines are cached if package and routine authorization caching is enabled on your system.

https://www.ibm.com/docs/en/SSEPEK_12.0.0/seca/src/art/pspi_opn.svgIf authorization checks on the EXECUTE privilege for packages and routines are performed by the authorization access control exit routine, the role in effect or the primary authorization ID is cached. Db2 authorization can cache roles or primary authorization IDs for handling packages and routines. Db2 checks and caches a role if it is in effect and authorized. If a role is not in effect or authorized, Db2 checks and caches the primary authorization ID.

If this privilege is revoked in the exit routine, the cached information is not updated to reflect the revoke. You must use the SQL GRANT statement and the REVOKE statements to refresh the specific entry in the cache and invalidate any dependent package. If the privilege is revoked from a RACF® group, you must issue the GRANT and REVOKE statements to refresh the cache information for every user in the RACF group. If the privilege is revoked from a profile name that is specified with generic characters, you must issue the GRANT and REVOKE statements to refresh the cache information for every object in Db2 that matches the generic characters for that object type.

If the AUTHEXIT_CACHEREFRESH system parameter is set to ALL, Db2 refreshes the cache entries of the package authorization, the routine authorization, and the dynamic statement when a user profile or resource access is changed in RACF and the access control authorization exit is active. Db2 refreshes the cache entries for DDF user authentication when the user profile is changed in RACF. The DDF user authentication cache is refreshed regardless of whether security is managed with Db2 facilities or with the access control authorization exit.
=====

DB2 has a parameter called AUTH EXIT CACHE REFR (AUTHEXIT_CACHEREFRESH subsystem parameter) that specifies whether the cache entries of the package authorization, the routine authorization, the DDF user authentication, and the dynamic statement are refreshed and whether the dependent packages are invalidated when a user profile or resource access is changed in RACF. This currently is not supported by Top Secret and TSSDB2, however, the support for this is being looked into.