Home > AS/400 Tips > iSeries security tips > Command line security considerations -- Part 2

	iSeries 400 Tips:	EMAIL THIS

	TIPS & NEWSLETTERS TOPICS

	ISERIES SECURITY TIPS Command line security considerations -- Part 2 Rich Loeber 06.28.2005 Rating: -4.12- (out of 5) Digg This!     StumbleUpon     Del.icio.us    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. [TABLE]			[IMAGE]

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

Digg This!     StumbleUpon     Del.icio.us

RELATED CONTENT iSeries security tips Controlling remote access on your IBM i Checking in on your IBM i authorization lists PCI data security standards and the System i Securing the integrated file system on IBM System i Contextual security on IBM i: Limit user profile access Time for a security checkup for your i Security monitoring on IBM i: Watching your super users Tracking System i program object changes Recovering your AS/400 security configuration System values on i: Setting them up and locking i down iSeries system and application security Checking in on your IBM i authorization lists Strategies for securing IBM i production files Changing password security levels and upgrading operating systems on the IBM i Determine the value of parameter UPPWEI in the DSPUSRPRF field Define journal code value "K" Modify content within a journal receiver file Change password parameters on the AS/400 without deactivating user's passwords Prevent insiders with *READ or *USE access from circumventing object authority on IBM i Prevent insiders from obtaining user ids and passwords on the IBM i Change the IBM i system to allow only certain types of SSL protocol versions

RELATED GLOSSARY TERMS Terms from Whatis.com − the technology online dictionary midrange  (Search400.com)

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary

, 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.

Rate this Tip To rate tips, you must be a member of Search400.com. Register now to start rating these tips. Log in if you are already a member. Submit a Tip 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.