When creating or changing Commands and Menus (*CMD, *MNU) objects you can set the PRDLIB, which cause the specified library to be inserted between the system library list and the user library list in the library list order. This provides a nice way to have programs which are invoked under the command or menu to use library list resolution and find objects in a library dynamically set at an application install time (especially when installing into a user chosen library name). This works well for well-intentioned users (mostly-- we've run into situations where a command in the product library is superseded by a command in a user's custom library in the system library list).
However, for a bad actor, they have three attack vectors:
1) impacting what libraries are in the system library list (system wide or just their own job) -- if they have cracked authority to do so.
2) Inserting an object into an existing system library list library that supersedes the intended on in the product library
3) Calling the underlying program for the command directly, bypassing the setting of the product library entirely and putting the product library into the user portion of the library list and a higher library in the user library list with the bad acting program (presumably to have it run under adopted authority.)
Since a user of a command must also have authority to call the program referenced by the command, they will always be able to call the program directly.
To protect against all of the above, add a CHG[SRV]PGM and/or UPD[SRV]PGM command option to set the primary library for a program. While that program is running, the primary library is at the top of the library list, removed when the top level invocation level of the program is exited via return or exception, etc. If another program is called with a primary library before exit, add it's primary library to the top of the library list. This assures programs can use non-qualified object references but still be assured that they find the object in the expected library which is dynamic based on where the program resides. This is particularly valuable for CL programs that call commands, because there is no way to dynamically qualify a command usage in a CL program, other than constructing a string for each command and using QSYS/CALL QCMDEXC or QCAPCMD-- this defeats the User Experience for writing can compiling CL programs getting command syntax errors at compile time rather than run time -- not to mention any command prompting assistance various Dev environments provide.
At a minimum, we should be able to specify a PRDLIB at the *PGM or *SRVPGM level that behaves the same as for *CMD and *MNU objects, but better to be able to avoid the system library list as well.
Even if a program is intended to be written will fully library qualified references to all objects, any programming error that fails to list a library name and gets *LIBL resolution would be covered with this additional protection, reducing the opportunity for unintended security holes.
