Remove default grants to PUBLIC on SYSIBM tables

An IBM Db2 Security Health Check audit will identify a SELECT privilege held by PUBLIC on the SYSIBM tables as an issue, with specific concern when the privilege is held on the authorization tables (i.e. SYSIBM.SYS%AUTH%). The IBM Db2 Administration Tool for Db2 z/OS grants SELECT to PUBLIC on the SYSIBM tables (see job ADBSETUP).

If IBM’s recommendation is to not have these grants, then IBM products should not be providing the grants in the provided SQL. There are valid reasons for not allowing PUBLIC to have SELECT on the SYSIBM tables given the information that can be obtained from them by a savvy hacker.

Db2 z/OS customers may already have these privileges granted to PUBLIC on the SYSIBM tables and it is not a trivial task to revoke the access from PUBLIC given how difficult it can be to figure out what is dependent on the PUBLIC privileges. Products such as Data Studio, Db2 Developer Extension, Db2 Administration Tool, Db2 Administration Foundation and some third-party vendor products, access the Db2 catalog to get schema information. Revoking access from PUBLIC can have unintended consequences. For example, views that were created after the PUBLIC grant will be implicitly dropped when the privilege is revoked from PUBLIC. Packages that were bound after the PUBLIC grant and have a dependency on this grant will be invalidated when the privilege is revoked from PUBLIC.

Customers that have transitioned or are in the process of transitioning away from PUBLIC having SELECT on the SYSIBM tables cannot afford to have IBM software putting the SELECT privilege back. As experienced people leave, the risk of someone not noticing or not understanding these grants increases, thus the IBM software can put the PUBLIC access exposure back.

The Db2 Administration Tool product (and other IBM products) needs to provide methods to:

1. Allow the customer to bypass the SYSIBM table grants completely, with this being the default.

2. Generate grants based on a list of ids provided by the customer.

   1. The installation instructions should recommend strongly against granting to PUBLIC and the sample scripts should not have PUBLIC as a grantee.

   2. The installation instructions should recommend the use of RACF groups, or other vendor’s equivalent, instead of individual ids.

IBM should be following the National Institute of Standards and Technology (NIST) least privilege guideline of least privilege. Granting SELECT access to PUBLIC does not follow this guideline.

Least privilege

The principle that a security architecture should be designed so that each entity is granted the minimum system resources and authorizations that the entity needs to perform its function. (least privilege - Glossary | CSRC (nist.gov) [csrc.nist.gov])