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.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online