Skip to Main Content
IBM Data and AI Ideas Portal for Customers


This portal is to open public enhancement requests against products and services offered by the IBM Data & AI organization. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:


Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,


Post your ideas

Post ideas and requests to enhance a product or service. Take a look at ideas others have posted and upvote them if they matter to you,

  1. Post an idea

  2. Upvote ideas that matter most to you

  3. Get feedback from the IBM team to refine your idea


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

IBM Employees should enter Ideas at https://ideas.ibm.com


Status Functionality already exists
Created by Guest
Created on Apr 4, 2024

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])

Needed By Yesterday (Let's go already!)
  • Admin
    Chris Pomasl
    Reply
    |
    Aug 19, 2024

    While IBM Db2 Administration Tool for z/OS did provide the means for changing the GRANT, the default in the configuration tool was PUBLIC.

    IBM Db2 Administration Tool is now changed to default to no GRANT processing.

    This change is made by

    APAR PH62395 and is now available.

  • Admin
    Chris Pomasl
    Reply
    |
    Apr 29, 2024

    The National Institute of Standards and Technology, NIST, has published standard 800-53 on Privileged Access Management and Least privilege. With the principle of Least Privilege, one grants users the minimum level of access necessary for their job functions, restricts access to sensitive information and critical systems, and segregates roles to maintain checks and balances.

    Of particular interest to database tools is the GRANT provision for permitting access to specific assets by a person’s role. In a world where dynamic SQL is pervasive, the expedient thing is to GRANT SELECT (i.e. read) access to system tables to PUBLIC. This, however, breaks the least privilege standard by allowing ANYONE with access to the database system to query those tables. Under a secure system, even metadata can be sensitive and must be treated as such.

    IBM Db2 Tools product teams always strive to comply with the concept of Least Privilege.

    For example, IBM Db2 Administration Tool enables the installer to specify the authid(s) that should be granted access to the SYSIBM.SYSxxxAUTH tables and which authid(s) should be granted access to the remaining Db2 catalog tables. NONE can be specified if no GRANTs should be generated during install i.e. if the installation is using RACF security or wants to control the access by other means (e.g. Grant management in Db2 Administration Tool).