To successfully manage security, you need to be aware of
indirect ways that users can gain access to data.
The following are 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.
- Visual explain: Visual explain shows the access plan chosen
by the query optimizer for a particular query. The visual explain
information also includes statistics about columns referenced in the
query. These statistics can reveal information about a table's contents.
- 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.