As more and more or- ganizations posture for network-enabled applications, security issues have risen to the fore. In the old days, when you could poke your head up over the cubicle walls and see everyone who was signed on to your system, security just didn’t seem that important. But when an organization endeavors to connect itself to the Internet, and (therefore) to persons and places unknown, then old habits must give way to new realities. In this article, I will concentrate on OS/400 security levels (system value QSECURITY) and provide in-depth understanding of what these different levels do. I will also debunk the traditional view that AS/400 object-level security (security level 30) is adequate. I’m going to explain why it is not, and then I’ll tell you what AS/400 security level you really ought to have.
When it first shipped in 1988, the AS/400 supported three security levels: level 10, 20, and 30, with level 10 being the least secure. In 1990, IBM added security level 40 to address a security exposure that allowed certain machine interface (MI) procedures to completely bypass AS/400 security. And then, in 1994, security level 50 was added primarily to acquire the Department of Defense’s C2 certification for trusted systems.
Security Level 10
IBM euphemistically refers to security level 10 as “physical security,” which really means that, if you can physically stand in front of any AS/400 terminal, you own it! At security level 10, not only are passwords not required (the sign-on screen does not even accept a password), neither are user profiles. If, for example, you were to type a user profile name at the sign-on screen and the user did not already exist, OS/400 would automatically create a profile to match what you had typed at the screen! And, if that security isn’t loose enough for you, every user profile created on a security level 10 box is created with *ALLOBJ special authority. So much for physical security.
But that is the bad news. The good news is that, beginning with V4R2, OS/400 no longer supports moves to security level 10. If you are already at security level 10 and you upgrade your OS/400 level, IBM will allow you to stay at level 10. But, if you are at security level 20 or higher, you cannot go back to security level 10.
Security Level 20
Security level 20 is referred to in the OS/400 Security - Reference V4R4 (SC41-5302-03, CD-ROM QB3ALC03) manual as “password security,” and that’s a fitting description. With security level 20, any user that attempts to sign on must have a valid user profile and password. While this is a tremendous improvement over security level 10, once the user profile and password have been authenticated, the user owns your AS/400. And, like security level 10, every user profile created under security level 20 has *ALLOBJ special authority and therefore has complete and unrestricted access to your system. (See “Security Patrol: Limiting *ALLOBJ Users” in the August 2000 issue of MC for more details.) Security level 20 bypasses OS/400 object level security by giving every user *ALLOBJ special authority, so anyone who presents a valid user profile and password is given unfettered access to the system.
On a well-managed system, there are few profiles that have *ALLOBJ authority. Instead, all authority is managed at the object level, granting individual and group profiles the necessary authority to access specific objects. This is called object level security, and it begins at security level 30.
Security Level 30
IBM refers to security level 30 as “object level security.” I refer to level 30 as “the security level formally known as ‘good enough.’” Object level security, as practiced by security level 30, is not good enough, and it has not been good enough for more than 10 years. The idea behind security level 30 was that an AS/400 system administrator could set the individual permissions to any OS/400 object, and the operating system would enforce access control based on an individual’s specifically stated permissions.
Theoretically, under security level 30, very few profiles have *ALLOBJ special authority, and access to individual objects is controlled by individual or group authority over that object. If you want to read an object, you must have *USE authority; to change the content of an object, you must have *CHANGE authority; and to delete an object, you must have *OBJEXST or *ALL authority. The typical way a user gets authority to an object is to have either her user profile, one of her (up to) 16 group profiles, or *PUBLIC named on the object with the desired authority.
Acquiring authority can be accomplished through program authority adoption (where the User Profile (USRPRF) parameter on a program object is set to *OWNER), through the assumption of another profile’s identity either through a job description, through swapping profiles, or by dipping below the operating system into MI and accessing certain IBM programs (i.e., blocked instructions) directly. Two of these methods of acquiring authority—assuming the identity on a job description and directly accessing certain MI objects—represent a complete circumvention of security level 30 and are compelling reasons to increase security to at least level 40.
User Identity Assumption
The first and best-known exposure under security level 30 is where a user can assume the identity of a user profile named on a job description. There is a parameter on every OS/400 job description called USER. When a user profile name is referenced in the USER parameter of a job description (JOBD), a batch job can be submitted to run under the authority of the user name attached to the job description. This means that, to submit a job and have it run under the authority of some other user under security level 30, a user need only have *USE authority to a job description. No specific authority to the user profile is required. Figure 1 shows an example of job description QBATCH in library QGPL, in which user profile QPGMR is attached to the job description. These are the default settings for this JOBD as shipped from IBM. Figure 2 is an example of a Submit Job (SBMJOB) command that uses JOBD QGPL/QBATCH to submit a job under the authority of user QPGMR.
The technique outlined in Figures 1 and 2 represent a serious exposure for any shop at security level 30. Take a look at your system right now, and see how many JOBDs you already have that can assume another’s identity. Aside from the default IBM JOBDs, such as QGPL/QBATCH and QGPL/QPFRCOL, you’re likely to have third-party-vendor- supplied JOBDs with profiles attached. I’m aware of one vendor that attaches default IBM user profiles to all of its JOBDs. If you’re running this vendor’s software, you’ve likely got JOBDs with user profiles QSECOFR, QLPINSTALL, and QSYS attached to them. To make matters worse, the JOBDs are usually installed with *PUBLIC *ALL authority. The solution to this problem is either to go to security level 40 or to restrict all the commands that can create and change job descriptions, including CRTJOBD, CHGJOBD, and all of the Restore (RST*) commands. (You wouldn’t want someone restoring one of these JOBDs from the AS/400 model B10 they bought off of eBay for a buck, would you?)
Direct MI Access
The second and more serious exposure is when high-level language (HLL) programs are used to directly access and manipulate OS/400 MI objects. Level 30 security depends on the concept that non-IBM programmers will not have direct access to certain sensitive OS/400 objects. But this concept simply cannot be enforced under security level 30. Beneath the covers of the operating system is a host of sensitive objects that can be used to obtain authority to other objects. It’s a simple concept, really. Sometimes your job may need access to internal IBM objects that you do not have direct access to. When this situation arises, you can gain authority to those sensitive objects by referencing an MI object that either has or can get authority to other MI objects.
If a clever programmer finds one of these authority-granting processes, he can use it to completely ignore your object-level-authority scheme. In the early days of the AS/400, this exposure was generally restricted to programs written in MI. More recently announced languages, such as C and Java, as well as recent updates to the venerable RPG language, have enabled access to low-level MI interfaces to virtually any programmer. This is amply evidenced by recent disclosures of password-sniffing interfaces that use RPG to exploit security level 30 weaknesses. (See my Monday Morning AS/400 Update articles “AS/400 Security Alert: Password Problem on AS/400” [June 26 issue] and “IBM Posts Updated Security PTFs for ‘Son of Sniff’” [August 21 issue] at www.midrangecomputing. com/mmu for more information.) The only cure for this exposure is to move up to at least security level 40.
Security Level 40
Security level 40 is where OS/400 begins to get serious about security. As I have already mentioned, security level 40 also enforces object level security on user profiles that are attached to job descriptions. For someone to use a job description with an attached user profile, he must have at least *USE authority to the user profile.
Another security problem that security level 40 fixes is the ability to sign on to a workstation without using a password. Even though this sounds scary, it wasn’t that big of an exposure, because a system administrator would have had to reconfigure the communications subsystem to enable this weak security design. I mention it because some shops have set up terminals to log on as a default user just by pressing the Enter key. That ability is blocked at security level 40.
Operating System Integrity
IBM refers to security level 40 as “operating system integrity,” which is a good descriptor because level 40 introduces the concepts of system state programs and system domain objects as well as restricted instructions. These three concepts were added to specifically prevent the direct MI access problem I have just outlined, and they do a good (but not perfect) job. At security level 40, OS/400 sets up a firewall between user state programs
and system domain (more on what this is a little later) objects and thereby prevents programs that you and I write from slipping below the MI covers and bypassing AS/400 security.
The idea that every object belongs to either the system domain or the user domain is a very simple concept. Typical objects in the system domain are programs, files, and data areas that were created by IBM and are part of either the operating system or one of OS/400’s Licensed Program Products (LPPs), like the RPG compiler or the performance tools. Typical objects in the user domain are programs, files, and data areas that either you or third-party application vendors have created.
In addition to its domain, a program has a state. Programs can be either a system state program or a user state program. System state programs are written by IBM and can reference objects in both the system domain and the user domain. User state programs are ones that you would write yourself. User state programs can only address objects that are in the user domain. In this way, IBM keeps the programs that you write from directly manipulating MI objects and bypassing object level security. But just remember, if you want to brag about the AS/400’s superior security to your Windows NT and UNIX friends, don’t do it until you are at least at security level 40.
Movin’ on Up!
If you’re ready to move up to security level 40, the good news is that it’s fairly easy to do. OS/400 can monitor for domain and state violations and report those to you. If you see programs that cause a domain or state violation, it’s a darn good bet that that violation was caused by a third-party vendor application, and it’s an equally good bet that the vendor already has a PTF version that works at security level 40.
To get to level 40, you should have the IBM-supplied Security Auditing Journal (QAUDJRN) command turned on and monitoring for authority failures (*AUTFAIL) and program failures (*PGMFAIL). It’s easy to check whether or not you have security auditing turned on; just look for the security audit journal, called QSYS/QAUDJRN. If you don’t see the QAUDJRN object in library QSYS, you’ll need to turn on security auditing yourself. Turning on security auditing is easy and can be done at anytime without disrupting normal operations. The following parameters for the Change Security Auditing (CHGSECAUD) command will turn on the auditing required for a move to level 40:
CHGSECAUD QAUDCTL(*AUDLVL) +
QAUDLVL(*PGMFAIL *AUTFAIL) +
INLJRNRCV(SECURELIB/AUDRCV0001)
After a reasonable time interval has passed (month-end is always good), display the journal and look for events that violate security level 40. Figure 3 (page 49) lists all of the level 40 violations as well as suggestions on how to correct each violation. As you can see, in many cases, you’ll need to replace the program in question. This usually means asking your vendor for a level-40-compliant version of the program. One more note: It is likely that your system will also generate journal entries of authority failures (journal type ‘AF’) with a violation type of either A or P. A violation type A is a regular authority failure (i.e., “user not authorized” to access object). And a violation type P indicates that there was a profile swap violation. While these entries may be interesting from a security auditor’s point of view, they have no impact on level 40 security.
Once you’ve been given a clean bill of health, you’re ready to move on up. This is the easy part. Simply change the system value to security level 40 and then IPL. When your AS/400 comes back up after the IPL, you should have that warm fuzzy feeling that good security brings. But don’t bask in the afterglow too long; recent events have caused many AS/400 security analysts to recommend to security-conscious customers that security level 50 is the right place to be.
Security Level 50
IBM calls security level 50 “enhanced integrity protection” for worthy reasons. Level 50 provides all of the protection of the previous levels and then some. Level 50 was originally created with V3R0M5 of OS/400 to enable OS/400 to comply with strict U.S. government standards for trusted computing systems (C2). But don’t be confused into thinking that moving to security level 50 makes your AS/400 C2-compliant; it’s just one of many steps along the way.
Security level 50 does provide valuable protection against some other nasty security problems. Recently, there have been several published reports of compromised AS/400 password integrity. PTFs have been issued to correct some of these problems, but others can be fixed only at security level 50. Security level 50 provides for protection against parameter violation (wherein a user state program passes parameters to a system state program), validates message-handling to prevent user state programs from sending exception messages to system state programs, and prevents the changing of internal control blocks. You don’t have to understand what all of that means to know that level 50 protects you from programs that violate operating system integrity.
Unfortunately, there is no way to test for level 50 compliance through audit journal entries as there is at security level 40, because the violations at level 50 are not logged, only blocked. That means you just have to move to level 50 and test it out. But it only takes a CHGSYSVAL QSECURITY command to change the value back.
As you’ve probably heard, security level 50 does extract a performance penalty. When it was first announced, IBM warned us that the penalty was anywhere from 5 to 15 percent of overall CPU utilization. Recent improvements in both security and performance- measuring ability caused those numbers to be lowered to as little as 2 percent. But I should warn you that your mileage may vary depending on your applications, access to their objects. The best advice on this front is to proceed slowly and take careful measurements. But, as one user recently quipped on a Internet list, even a 15 percent performance penalty is meager if one considers the alternative.
Are You Ready?
So there you have it: security from top to bottom. If you’re not at security level 40, start mapping a strategy right now for getting there. If you are at security level 40, congratulations! But don’t rest on your laurels. The ever-evolving nature of the AS/400 and computing in general argue persuasively for one more step up.
REFERENCES AND RELATED MATERIALS
• “AS/400 Security Alert: Password Problem on AS/400,” John Earl, Monday Morning AS/400 Update, June 26, 2000, www.midrangecomputing.com/mmu
• “IBM Posts Updated Security PTFs for ‘Son of Sniff,’“ John Earl, Monday Morning AS/400 Update, August 21, 2000, www.midrangecomputing.com/mmu
• “Security Patrol: Limiting *ALLOBJ Users,” John Earl, MC, August 2000
• Security-Enabling for C2 V4R1 (SC41-5303-00, CD-ROM QB3ALD00.
Figure 1: The user profile QPGMR is attached to job description QBATCH.
Figure 2: Specific authority to the user profile is not required if the user has *USE authority.
Journal Entry Violation Violation Corrective Code Type Type Description Action
T AF B Restriction (blocked) Obtain new program from vendor or instruction violation re-create program
T AF C Object validation failure Obtain new program from vendor or re-create program
T AF D Unsupported interface Obtain new program from vendor or
(domain) violation re-create program T AF J Job-description Remove the user profile from JOBD and user-profile or grant user authority to JOBD authorization failure
T AF R Attempt to access Obtain new program from vendor or protected area of disk re-create program
T AF S Default sign-on attempt Modify the subsystem entry to not allow sign on at enter
Figure 3: These are the recommended fixes for level 40 violation types.
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