Gaining access to data through indirect means

To successfully manage security, you need to be aware of indirect ways that users can gain access to data.

The following list represents the indirect means through which users can gain access to data they might not be authorized to access:

• Catalog views: The DB2® database system catalog views store metadata and statistics about database objects. Users with SELECT access to the catalog views can gain some knowledge about data that they might not be qualified for. For better security, make sure that only qualified users have access to the catalog views.
  Note: In DB2 Universal Database™ Version 8, or earlier, SELECT access on the catalog views was granted to PUBLIC by default. In DB2 Version 9.1, or later, database systems, users can choose whether SELECT access to the catalog views is granted to PUBLIC or not by using the new RESTRICTIVE option on the CREATE DATABASE command.
• Explain snapshot: The explain snapshot is compressed information that is collected when an SQL or XQuery statement is explained. It is stored as a binary large object (BLOB) in the EXPLAIN_STATEMENT table, and contains column statistics that can reveal information about table data. For better security, access to the explain tables should be granted to qualified users only.
• Section explain: The section explain procedures (EXPLAIN_FROM_SECTION, EXPLAIN_FROM_CATALOG, EXPLAIN_FROM_ACTIVITY and EXPLAIN_FROM_DATA) can populate explain tables with information from any section that resides in the package cache. This information includes statement text which may contain input data values. For better security, access to the section explain procedures and explain tables should be granted to qualified users only.
• Log reader functions: A user authorized to run a function that reads the logs can gain access to data they might not be authorized for if they are able to understand the format of a log record. These functions read the logs:

  Function	Authority needed in order to execute the function
  db2ReadLog	SYSADM or DBADM
  db2ReadLogNoConn	None.

• Replication: When you replicate data, even the protected data is reproduced at the target location. For better security, make sure that the target location is at least as secure as the source location.
• Exception tables: When you specify an exception table while loading data into a table, users with access to the exception table can gain information that they might not be authorized for. For better security, only grant access to the exception table to authorized users and drop the exception table as soon as you are done with it.
• Backup table space or database: Users with the authority to run the BACKUP DATABASE command can take a backup of a database or a table space, including any protected data, and restore the data somewhere else. The backup can include data that the user might not otherwise have access to.

  The BACKUP DATABASE command can be executed by users with SYSADM, SYSCTRL, or SYSMAINT authority.

• Set session authorization: In DB2 Universal Database Version 8, or earlier, a user with DBADM authority could use the SET SESSION AUTHORIZATION SQL statement to set the session authorization ID to any database user. In DB2 Version 9.1, or later, database systems a user must be explicitly authorized through the GRANT SETSESSIONUSER statement before they can set the session authorization ID.

  When upgrading an existing Version 8 database to a DB2 Version 9.1, or later, database system, however, a user with existing explicit DBADM authority (for example, granted in SYSCAT.DBAUTH) will keep the ability to set the session authorization to any database user. This is allowed so that existing applications will continue to work. Being able to set the session authorization potentially allows access to all protected data. For more restrictive security, you can override this setting by executing the REVOKE SETSESSIONUSER SQL statement.

• Lock monitoring: As part of the lock monitoring activity of DB2 database management systems, values associated with parameter markers are written to the monitoring output when the HIST_AND_VALUES collection level is specified. Values may also be embedded in the statement text captured by the lock event monitor. A user with access to the monitoring output can gain access to information for which they might not be authorized.
• Activity monitoring: As part of monitoring activities in a DB2 database management system using an activity event monitor, the values associated with parameter markers are written to the monitoring output when the VALUES clause is specified, and the statement text (which may contain input data values) is written to the monitoring output when the WITH DETAILS clause is specified. A user with access to the monitoring output can gain access to information for which they might not be authorized. For better security, access to the CREATE EVENT MONITOR statement and any event monitor tables should be granted to qualified users only.
• Package cache monitoring: As part of monitoring the package cache in a DB2 database management system using a package cache event monitor, the statement text (which may contain input data values) is written to the monitoring output whenever a section is ejected from the package cache. For better security, access to the CREATE EVENT MONITOR statement and any event monitor tables should be granted to qualified users only.
• Monitor table functions, views and reports: The following monitor table functions, views and reports expose statement text for either currently executing statements or statements in the package cache:
  • SYSPROC.MON_GET_ACTIVITY_DETALS
  • SYSPROC.MON_GET_PKG_CACHE_STMT
  • SYSPROC.MON_GET_PKG_CACHE_STMT_DETALS
  • SYSIBMADM.MON_PKG_CACHE_SUMMARY
  • SYSIBMADM.MON_CURRENT_SQL
  • SYSIBMADM.MON_LOCKWAITS
  • SYSIBMADM.MONREPORT.LOCKWAIT
  • SYSIBMADM.MONREPORT.CURRENTSQL
  • SYSIBMADM.MONREPORT.PKGCACHE
  The statement text may contain input data values. For better security, EXECUTE privilege on these table functions and reports and SELECT privilege on these views should be granted to qualified users only.
• Traces: A trace can contain table data. A user with access to such a trace can gain access to information that they might not be authorized for.
• Dump files: To help in debugging certain problems, DB2 database products might generate memory dump files in the sqllib\db2dump directory. These memory dump files might contain table data. If they do, users with access to the files can gain access to information that they might not be authorized for. For better security you should limit access to the sqllib\db2dump directory.
• db2dart: The db2dart tool examines a database and reports any architectural errors that it finds. The tool can access table data and DB2 does not enforce access control for that access. A user with the authority to run the db2dart tool or with access to the db2dart output can gain access to information that they might not be authorized for.
• REOPT bind option: When the REOPT bind option is specified, explain snapshot information for each reoptimizable incremental bind SQL statement is placed in the explain tables at run time. The explain will also show input data values.
• db2cat: The db2cat tool is used to dump a table's packed descriptor. The table's packed descriptor contains statistics that can reveal information about a table's contents. A user who runs the db2cat tool or has access to the output can gain access to information that they might not be authorized for.