Question: I have a user that I’ve set up to limit capabilities in his user profile. When he signs on, he runs a CL program, which gives him access to one application on our system. But, he can still go into the System Request menu and select option 6 to see and also respond to the system operator messages. Is there a way I can restrict access to the System Request function?

Answer: There are two things that you could do to prevent a user from answering QSYSOPR’s messages. The first is to limit access to the System Request function, as you have suggested. An easy way to do this is to set the authority on the QSYS/QGMNSYSR panel group to *EXCLUDE for a user, a group of users, or even for *PUBLIC. The command to accomplish that task might look like this:

CHGOBJAUT OBJ(QSYS/QGMNSYSR) +

OBJTYPE(*PNLGRP) +

USER(ThatGroup) AUT(*EXCLUDE)

If users are not authorized to the panel group, they will not be able to see the System Request display. Mission accomplished.

However, if all you are trying to do is prevent the answering of QSYSOPR’s messages, there is another route. You could remove the ability to display QSYSOPR’s messages, thereby preventing users from responding to a message no matter what method they try to use to access the queue. Be careful: You want to remove a user’s ability to display the queue only. Do not grant any user *EXCLUDE authority to QSYSOPR’s message queue. Every job on the system needs authority to add new messages to QSYSOPR’s message queue, because that is where OS/400 routes error messages for batch and communications jobs. If you remove a user’s ability to *ADD new messages to message queue QSYSOPR, the user’s job will generate a new error (No Authority to Message Queue QSYSOPR) and try to send that new message to message queue QSYSOPR, which will generate another error message.... Well, you get the picture.

The correct way to limit authority to the QSYSOPR message queue is to remove the data *READ authority to the message queue but leave object *OPR + data *ADD authority. This gives a user the ability to drop new messages on the queue but no ability to answer or view any messages that are on the queue.

Question: I read your articles “Technology Insight: The Most Secure System Ever?” (AS/400 Technology SHOWCASE, September 2000) and “Security Patrol: Tracking File Downloads” (Midrange Computing, August 2000). With the ability of Windows 98 to access the AS/400 like any other server and modify and delete with a click, what other ways besides exit programs can the AS/400 be protected?

Answer: Given the security designs inherent in most existing AS/400 application packages, exit programs are likely the easiest way to provide a means of regulating access to the data. You’re hearing a lot about exit programs and will likely hear more, because many people have found that exit programs provide the most efficient method of securing applications. However, there are other ways to protect your AS/400 from network access. Here are some of the better-known ways:

• Don’t start any network interfaces, or don’t hook up PCs to your AS/400—OK, it sounds silly, but one (very impractical) method of security is to simply prevent all PC and network access. If you choose this route, your AS/400’s days as a production system are numbered.

• Change the authority of all libraries and objects on your system to *EXCLUDE, and use only adopted authority to access your system—This approach was often referred to as Application Only Access, or AoA. And while it may sound severe, a small number of those organizations that are doing something about network access security choose this route and are relatively successful. AoA requires a fair amount of work on your side and some cooperation from all your application vendors, but it has the benefit of being quite good at completely blocking access to your system.

AoA is not particularly good, however, at providing limited access through the network unless you extend the AoA model to the entire network and require the use of adopted authority stored procedures for all network access. This approach would entail writing a new program for each data request that is allowed over the network. And, of course, whenever you change the default security settings for objects in a third-party purchased application, plan on reinstituting these changes after every vendor software upgrade.

• Use Object Level Security (OLS) typically requires that you change all of the objects on your system so that users have only the authority that they need to do their jobs. It sounds great at first blush and is in fact the preferred method of securing data if you have the time and resources to actually implement it.

OLS requires a fairly high degree of knowledge of the internal workings of your applications and of the daily responsibilities of your users. OLS is the most labor-intensive of the three methods listed here because you’ll have to manage the relationships between all of the objects and all of the users on your system at a fairly low level.

You can employ group profiles and authority lists to lower the day-to-day maintenance of these tasks, but this is still going to be a substantial undertaking. And, even if you use OLS, you may still want to implement exit programs for the following reason: Any user to whom you give *CHANGE authority to a payroll application, for example, will be able to change that file through network interfaces as well as through the traditional AS/400 application that you expect that user to use.

And remember that the payroll program you wrote in RPG performs all kinds of security functions (Mary can only change the salary for her direct reports; supervisors can’t view executives’ compensation; there are only 50 valid state codes, etc.) that network access methods will simply not know about. You’ll still need another tool to block authorized users from changing data in unauthorized databases. And, with AoA, plan on reinstituting these changes after every vendor software upgrade.

I am not saying that you should not use object level security. If you have the time and the resources necessary to implement an OLS design, you’re going to have one of the most secure AS/400s anywhere. But the sad fact is that many shops do not have the time, resources, and technical wherewithal to pull off an undertaking of this magnitude.

So, yes, there are some other options, but, of all the methods listed, I still think that exit programs offer the best combination of security and flexibility for shops. And, best of all, a good exit program implementation should not require any changes to your green- screen applications.

Question: I’ve been teaching myself about FTP lately and noticed that you can issue remote commands through FTP. This seems pretty cool for programmers and such, but when I tried to restrict it by setting my FTP profile to limited capability, that profile could still enter commands that executed on the remote AS/400. Does FTP remember the original settings or what? How do I stop FTP remote commands?

Answer: I’m going to guess that you are using V4R1 or an earlier version of OS/400. The problem you describe was fixed (for FTP at least) beginning with V4R2.

The essence of what you discovered is this: When the Limited Capability (LMTCPB) parameter is set on (*YES) in a user profile, OS/400 blocks the user from entering commands at an OS/400 command line. But, before the FTP change in V4R2, the OS/400 command line program was the only place that Limited Capability users were restricted. FTP, Distributed Data Management (DDM), and Client Access all supported remote command capabilities that did not check the LMTCPB flag in the user’s profile.

In V4R2 of OS/400, FTP was changed so that remote commands are not allowed for users that are LMTCPB(*YES). Keep in mind, however, that only FTP was changed. DDM and Client Access (which utilizes DDM for its remote command support) were not changed to respect the LMTCPB flag. The reasons are quite sensible, really. FTP was announced in V3R7, and, when IBM changed FTP to check the LMTCPB flag, it was only two releases old. At that tender age, IBM correctly assumed it could modify this tool without throwing the world into turmoil. But DDM is as old as S/38 CPF Release 7.0 and is much broader than AS/400, so changing DDM to respect the LMTCPB flag is a much more disruptive proposition. Don’t expect that IBM will ever change DDM to respect the LMTCPB flag.

REFERENCES AND RELATED MATERIALS

• OS/400 Security—Reference V4R4 (SC41-5302-03, CD-ROM QB3ALC03)
• “Security Patrol: Tracking File Downloads,” John Earl, MC, August 2000
• “Technology Insight: The Most Secure System Ever?” John Earl, AS/400 Technology SHOWCASE, September 2000

John Earl is the founder and Director of Technology and Security for  The PowerTech Group.  a Seattle-area software company that specializes in System i security. He has over 25 years experience with IBM midrange systems and security, has published numerous articles and columns for industry magazines, and served as a Subject Matter Expert (SME) for Security for COMMON. A highly regarded speaker on OS/400 and i5/OS security, Mr. Earl has presented several hundred of iSeries security sessions at industry conferences and user groups all over the world. He is a three-time winner of COMMON's Speaker Excellence award and has also served on the board of directors of COMMON U.S.

 

He can be reached at 253.872.7788 or at This email address is being protected from spambots. You need JavaScript enabled to view it..

 

 

Also Read

IBM i Security Essentials: 4 Components for an Effective Strategy

New IBM i Security Features and a Farewell

Securing IBM i: A Dual Responsibility