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