Misconceptions are common regarding how users are granted command privileges.

Editor's note: This article introduces the white paper "Managing Privileged Users on IBM i," free for download at the MC White Paper Center.

For years, analysts have predicted the demise of the platform whose heart beats in the chest of many of the world's largest organizations. But frustrated industry experts reject the notion that IBM i is outdated, citing highly scalable 64-bit Power-PC technology, class-leading reliability, and integrated security. Much of the controversy involves the "green screen," so IBM and many third-party solution providers have sought to provide users with a modern GUI to their IBM i applications.

Despite strides to enable a GUI, IBM i remains primarily a command-based OS. Therefore, the OS is uniquely vulnerable when access to server commands is lax. Best practices and regulatory compliance standards mandate that IBM i server commands be restricted to users on an as-needed basis to ensure integrity. This paper exposes some little-known risks associated with commands and provides recommendations on managing command access. It also highlights the need for commercial-grade security solutions designed specifically to assist administrators, auditors, and managers with this often-difficult task.

Defining "Command"

An IBM i command is simply an interface to a server or application function, much like a Microsoft Windows shortcut icon. IBM supplies more than 1,700 commands to control the server's OS and licensed program products. In addition, an easy-to-use programming interface enables software developers to create their own commands. This paper focuses on IBM-supplied commands, but most of the concepts are equally applicable to user-written commands.

Compared to directly invoking a program, a command has three primary benefits:

• Easy to remember

• Simple to invoke

• Validation of user information (parameters)

Let's consider a fictitious order report program, myorders, which requires users to supply qualifying information—perhaps a customer number, a data range, and whether out-of-state orders should be included—before it can execute.

Programmers typically design a screen interface to facilitate this type of information entry; however, this makes automation difficult as users must be at a workstation and take a menu option to enter the information.

Depending on how the application is programmed, users may be able to supply the required information directly to the program via parameters. The call to our orders report program may resemble the following:

CALL PGM(myorders) PARM('000010' '09012011' '093114' '*NO')

This approach eliminates the automation restriction by enabling users and batch programs to bypass the entry screen. However, it's not something we want users typing on a command line; it's too complex and the formatting is prone to human error. This is a perfect scenario where a command provides ease of use and flexibility.

Unlike the simple myorders program, IBM's operating system programs often have dozens of parameters. Parameters may also have co-dependencies; for example, the RSTOBJ command allows users to designate that a save file (*SAVF) is to be used as the source of the restored objects. If users designate *SAVF, they also must provide the save file's name and library location. Allowing users to call an IBM i CPP directly could make the server vulnerable to abuse (not to mention how complex and cumbersome the CALL command would be). Instead, IBM prohibits users from invoking OS programs directly and provides commands and APIs.

Which Users Can Run Commands?

Misconceptions are common regarding how users are granted command privileges. The OS doesn't allow control over whether users can access a command line, but only whether they can run commands on it. Contrary to popular belief, control is not a system- or profile-wide setting, but is determined by each command individually.

Every user's profile contains an attribute designating whether the user has limited capabilities. This attribute has three possible values: *YES, *NO, and *PARTIAL. *NO and *PARTIAL grant users command privileges. *YES works in conjunction with a corresponding attribute on each command definition object, which indicates if the command is available to the user with limited capabilities.

Most IBM i commands ship with an Allow Limited User attribute value of *NO, which prevents execution by users with limited capabilities. This command attribute can be altered and should be audited occasionally to ensure that it hasn't been modified without permission, especially for powerful or sensitive commands. Auditing *CMD objects will generate a "ZC" (object change access) event if this command attribute is modified, although the log won't indicate which command parameter was altered. All audit entries should be monitored and reported on with dedicated auditing solutions.

The limit capability setting is applicable only to commands invoked from a system command line. Commands still can be run within a program and initiated from a menu. This provides the flexibility to permit users indirect access to necessary system functions without giving them command execution permission. Unfortunately, client-server interfaces don't always enforce the limit capability restriction.

Want to Know More?

Download the free white paper "Managing Privileged Users on IBM i" at the MC White Paper Center.