Allow SYSTOOLS and SYSFUN schemas to be permitted separate from SYSCTRL

Thank you for submitting this Db2 for z/OS Idea.

After giving the request a comprehensive review, we have determined that we cannot include it as a candidate in an upcoming deliverable because it is not consistent with the product direction for future deliverables. As a consequence we will not be implementing this Idea.

We appreciate your input to the Db2 for z/OS development team. We also hope that you will continue to submit ideas for improvements as customer feedback is a key component to shaping the future direction of Db2 for z/OS.

Sincerely,

Db2 for z/OS Team

IBM,

Thanks for your consideration. There are a couple of reasons why the INSTALL SYSOPR approach is not, in my opinion, ideal:

First of all, the installation privileges, INSTALL SYSOPR and INSTALL SYSADM, bypass the SAF, since they are coded into the ZPARM module. This means that we have no ability to audit anything done under INSTALL SYSOPR privilege within our SAF environment. This presents a security risk.

Second, the use of INSTALL SYSOPR requires some custom configuration to the security environment, making the procedure esoteric and cryptic, rather than straightforward and standard. For example, it requires the creation of the ID "SYSINSTL" in our security environment to be creator/definer of many of the system routines defined by DSNTIJRT. Our shop does not generally support the use of secondary IDs in our mainframe environment, particularly switching into secondary IDs.

Third, INSTALL SYSOPR grants privileges beyond the scope of simply managing SYSTOOLS/SYSFUN schemas. The granularity and specificity of Db2 permissions is one of its major advantages, and I have long advocated the position that administrative authorities should be avoided wherever possible and permissions should be granted explicitly, following the guideline of "least privilege". According to the Db2 12 "Managing Security" guide, INSTALL SYSOPR provides some pretty broad authorities, including the ability to issue virtually any Db2 Command, as well as the ability to use any ID as a "BIND AGENT". The BIND AGENT authority particularly has a broad capacity for abuse, for someone who understands it well enough.

DSNTIJRT/actual installation is not the only time when one would want to change the operating environment of a SYSTOOLS function. Recently, we had a user request Db2 JSON functionality. The BSON2JSON and JSON2BSON routines (SYSTOOLS schema) were defined to DSNWLM_NOT_ENABLED. We did not want to run the full DSNTIJRT again, so I attempted to perform an ALTER and point the functions to a different WLM APPLENV. Doing so generated a security violation and resulted in suspension.

To be honest, I believed that the Install SYSOPR/SYSINSTL solution was intended to provide customers with a temporary work-around until this issue could be given a more permanent resolution. I am not fully understanding why every other schema, including some system schemas like SYSIBM, allow for the customer to define the Schema, database, tables, packages, plans, etc as explicit resources to be granularly controlled, while SYSFUN and SYSTOOLS require the grant of an administrative privilege that the customer may not desire to use and that carries permissions beyond the scope of these schemas.

Although this restriction seems well-meaning, it makes broad assumptions about how customers manage their mainframe security environments, as well as how they manage the roles and responsibilities related to Db2. In that light, it seems arbitrary and capricious.

I am not asking for any "special" operation for these schemas...rather, I am asking that the "special" operation be removed, and the SYSFUN/SYSTOOLS schemas be able to be granted, revoked, and managed as every other schema in Db2.

I hope this clarifies my position on this RFE. If you have any further questions, let me know.

Thanks

-Mark

Hi Mark, This requirement was originally submitted as RFE 121868. In that RFE we had stated DSNTIJRT can be run with INSTALL SYSOPER privilege. Can you please explain why this is not a reasonable alternative?

Thank you.