04
Fri, Oct
2 New Articles

Take Security to the Next Level

IBM i (OS/400, i5/OS)
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

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.


Take_Security_to_the_Next_Level06-00.png 395x280

Figure 1: The user profile QPGMR is attached to job description QBATCH.

Take_Security_to_the_Next_Level06-01.png 600x425

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.


John Earl

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

 

 

BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More 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.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY 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.

  • SB HelpSystems ROBOT GenericForms 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.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA 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:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA 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.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra 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: