Command line security considerations -- Part 2

In part one, we talked about limiting user access to the OS/400 command line. For some installations, however, you may have some good business reasons for providing command line access. This time, we'll take a look at how you can restrict access to specific commands in OS/400.

Every command in OS/400 exists as an object on the system with object type *CMD. The best way to control access to the commands is through OS/400 object security. Command objects can exist in any library. The OS/400 commands are generally all found in the QSYS library. Command objects can be part of OS/400, and they can be part of application programs installed on your system either from your own homegrown applications or from software providers other than IBM.

critical OS components The danger of indiscriminately assigning special authorities

Most OS/400 commands are shipped from IBM with the public authority set to *USE. That means anyone on your system can run any command. To restrict a command, change the public authority to *EXCLUDE. When you make that change, then only users with all object authority (generally a no-no in a security-conscious installation) will be able to run the command. Then, either using an authorization list or by granting specific user profile access, you can control who can run the command.

For example, suppose you decide you want to restrict the use of the Work with Output Queue (WRKOUTQ) command. That is one of the commands that is shipped with public authority of *USE. To change the public authority to *EXCLUDE, run the following Grant Object Authority (GRTOBJAUT) command:

 GRTOBJAUT OBJ(QSYS/WRKOUTQ) OBJTYPE(*CMD) USER(*PUBLIC)
   AUT(*EXCLUDE)

Now, if you have a set of users you specifically want to allow access to the command, you can grant them individual access using the following command format:

 GRTOBJAUT OBJ(QSYS/WRKOUTQ) OBJTYPE(*CMD) USER(MYPROFILE)
   AUT(*USE)

The USER parameter can point to a specific user profile or to a group profile. If you have implemented group profile security, this is the better way to approach this issue.

When setting up command security using this method, you can use wildcard characters for the object name in the Grant Object Authority command. Using this method, you can update the public and private authority for many related commands all at the same time. The OS/400 Security Guide suggests controlling all of the commands that change device configurations as an example. Using that example, the following command would do the trick:

 GRTOBJAUT OBJ(QSYS/CHGDEV*) OBJTYPE(*CMD) USER(*PUBLIC)
   AUT(*EXCLUDE)

Your best approach is still to limit your users' ability to run commands directly from the command line. But if you absolutely have to allow it, then make sure an inquisitive user doesn't accidentally (or purposefully) run a command you don't want them running. Also, remember that for this technique to work, your system must be set to security level 30 or higher. If you're running at level 20, shame on you and make the change now.

If you have any questions about this topic, you can reach me at rich@kisco.com, I'll give it my best shot. All e-mail messages will be answered.

---------------------------------------
About the author: Rich Loeber is president of Kisco Information Systems Inc.s in Saranac Lake, N.Y. The company is a provider of various security products for the iSeries market.

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.