Limited Capabilities Workaround
January 25, 2012 Patrick Botz
Limited capabilities is a widely used security function of IBM i. User profiles have an attribute named limited capabilities or LMTCPB. CL commands have an attribute named allow limited capabilities users or ALWLMTUSR). CL commands set to ALWLMTUSR(*NO) cannot be run from a command line by user profiles set to LMTCPB(*YES). To be more precise, these commands cannot be run from a command line, the command-entry display, FTP, REXEC, the QCAPCMD API, or as an option from a command grouping menu.
This is all well and good. Sometimes, however, you run into situations where a few user profiles, that should otherwise be set to LMTCPB = *YES, need to use a command or a few commands that are shipped with ALWLMTUSR = *NO. The average administrator looks at this problem and sees two choices:
Both of these options are unsatisfactory. The first allows these few users to execute any command to which they have *USE authority. Clearly this option gives these users the ability to do way more than they need to on the system. The second option gives all users on the system the ability to execute these few commands, assuming they have authority to the commands.
Changing the authority of the commands so that only these few users are allowed to run them is not an option. Remember that even limited capability users can execute commands that are embedded in other commands. Users are likely using applications that use these commands internally. Changing the authority of the commands will result in authority failures.
So how do you allow limited capabilities users to:
The answer is pretty straightforward actually. Create a new command.
Creating a new command takes advantage of the fact that CL commands used within other CL commands are not subject to the limited capabilities restriction. Since we are talking specifically about commands that need to be executed from some form of command line, there is no need to replace existing commands or worry about the order of the library list. You can simply create a new command with your own name and train only those users that need to execute that particular command how to use it.
There are three steps involved in creating a new command to work around the limited capabilities restriction for a subset of users:
I recently ran into this exact problem again. For PCI data security purposes, a customer had changed all “regular” users on the system to LMTCPB(*YES). They quickly found out that a couple of these users were running the SBMJOB command through the SBMRMTCMD function on their PCs. The job they were submitting was a long running report generation program. They were using SBMJOB because they didn’t want to leave the connection open until the report finished. The customer’s initial workaround was to set these users to LMTCPB(*NO). In addition to the PCI concerns, however, these users were not normal System i users. The customer wanted to allow them to continue to generate their reports but otherwise be prevented from running arbitrary commands. I’ll use this example to illustrate the steps required to work around this limited capabilities user problem.
Step 1: Create a CL Program
The users need to run a single program. We’ll call it RPTGEN, which takes a single parameter. We’ll call it RPTOPT. The remote users were originally entering this command as the parameter to the SBMRMTCMD function.
SBMJOB CMD(CALL PGM(XXXX/RPTGEN) PARM('RPTOPTS'))
We created a new CL program, NEWRPTGEN. It encapsulates the SBMJOB command and allows the users to still choose the report generation options. The program accepts one parameter, RPTOPT. Here’s the source code for NEWRPTGEN:
PGM PARM(&ARG1) DCL VAR(&ARG1) TYPE(*CHAR) LEN(10) SBMJOB CMD(CALL PGM(XXXX/NEWRPTGEN) PARM(&ARG1)) ENDPGM
Step 2: Create a CL Command
Creating the CL command is very straightforward. Here’s the code:
CMD PROMPT('New Report Generation Command') PARM KWD(OPTIONS) TYPE(*CHAR) LEN(10) DFT(*NONE)
After creating the command, use the DSPPGM options to ensure that the ALWLMTUSR attribute is set to *YES. If not, use the CHGPGM command to change it to *YES.
Users now only need to type something like this:
Step 3: Set the Proper Authority
Finally, you need to change the authority of the command AND the program in order to prevent all limited capabilities users from using the command.
Use the Edit Object Authority (EDTOBJAUT) command or Grant Object Authority (GRTOBJAUT) command to change the authority. Set *PUBLIC to *EXCLUDE and grant *USE authority to those users that need to generate reports remotely.
Edit Object Authority Object . . . . . . . : NEWRPTGEN Owner . . . . . . . : PBOTZ1 Library . . . . . : XXXX Primary group . . . : *NONE Object type . . . . : *PGM ASP device . . . . . : *SYSBAS Type changes to current authorities, press Enter. Object secured by authorization list . . . . . . . . . . . . *NONE Object User Group Authority *PUBLIC *EXCLUDE PBOTZ1 *ALL GREG *USE TSECRETO *USE Object . . . . . . . : NEWRPTGEN Owner . . . . . . . : PBOTZ1 Library . . . . . : XXXX Primary group . . . : *NONE Object type . . . . : *CMD ASP device . . . . . : *SYSBAS Type changes to current authorities, press Enter. Object secured by authorization list . . . . . . . . . . . . *NONE Object User Group Authority *PUBLIC *CHANGE PBOTZ1 *ALL
Now you’ve created a new command to work around the limited capabilities restriction.
Patrick Botz is the principal consultant and founder of Botz & Associates Inc. He is also president of Valid Technologies, LLC, a biometric middleware ISV. Pat spent nearly 20 years working at IBM in various security roles including lead IBM i security architect, IBM eServer security team, and the head of IBM Lab Services Security Consulting practice. Check out his Website at www.botzandassociates.com. Send your questions or comments for Patrick to Ted Holt via the IT Jungle Contact page.