Limited Capabilities Workaround

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:

1. Change the user profiles that need to run these few commands to LMTCPB = *NO
2. Change the commands that need to be used by these few users to ALWLMTUSR = *YES

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:

1. Execute a small number of commands while continuing to be prevented from running all other ALWLMTUSR = *NO commands
2. Do so without allowing all users to run these same commands

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:

1. Create the CL program
2. Create the CL command
3. Set the proper authority of the program and command

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:

NEWRPTGEN 'OPT123'

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.

                     Post this story to del.icio.us
               Post this story to Digg
    Post this story to Slashdot