I have to be honest. Moving from QSECURITY level 20 to 40 is a much different story than the 30 to 40 move. Miss the first part of the excerpt?  Read it here.

Editor's Note: This article is excerpted from chapter 3 of the security book, Mastering IBM i Security, by Carol Woodbury.

Simply put, the move is not trivial. But because QSECURITY level 20 will no longer be an option as of IBM i 7.5 and I know there are still systems running at this security level, I’m going to describe how I’ve helped organizations make this move.

The only difference between QSECURITY level 20 and 30 is that at level 20 all profiles are created—by default—with *ALLOBJ, *SAVSYS, and *JOBCTL special authorities. When you IPL the system off of level 20 to anything higher, the system adjusts the users’ special authorities based on the value of the User Class (*USRCLS) parameter in the user profile. This is the absolute only time you’ll ever hear me talking about the importance of the user class setting, but in this one scenario, it’s critical.

The primary reason it’s so difficult to move off of level 20 is because at level 20 you basically don’t have to worry about security at all because all profiles have *ALLOBJ. So now you’re moving from an environment where security isn’t a concern to one where it is. Of course, this is the perfect opportunity to rework your application security design to be more secure, possibly even implementing a deny-by-default approach. But even if you don’t want to go to those lengths, you can’t ignore the fact that *ALLOBJ is going to be removed from most users, and if your application’s *PUBLIC authority settings aren’t set to accommodate all actions being taken, there will be authority failures. While there’s no way to use the audit journal to know what will fail (as you can with the 30 to 40 move), the good news is that the same authority-checking algorithm runs at all security levels.

This means that you can remove some users’ *ALLOBJ special authority while still running at security level 20 to test your application and make the necessary adjustments prior to IPLing. You can also—and I encourage you to—audit for security level 40 issues at the same time. It’s a waste of time to IPL from 20 to 30 and then audit for level 40 issues and then IPL to 40. You can easily make the move from 20 directly to 40.

Analyzing and Adjusting Profiles’ User Class

The analysis for moving off of QSECURITY 20 begins with analyzing the profiles’ user class settings. To get this listing, we’ll make use of the QSYS2.USER_INFO IBM i Service:

SELECT authorization_name,

   user_class_name,

   special_authorities,

   text_description

FROM qsys2.user_info

ORDER BY user_class_name;

I’ve included the currently assigned special authorities in my SQL so you can see what special authorities may potentially be stripped away when you IPL. I say “potentially” because the special authorities will be assigned based on the user’s user class, as shown in Table 3.1 from chapter 2 of the IBM i Security Reference manual.

Table 3.1: Table from chapter 2 of the IBM i Security Reference manual shows special assignments by user class.

I encourage you to assign users to a user class that best matches their job responsibilities. Special authorities may have been assigned throughout the years but may no longer be (or never were) necessary. Now is the perfect time to reduce excess special authorities. This means that most profiles should be assigned to the *USER user class.

Obviously, security and system administrators will likely be assigned to the *SECOFR user class. But you may have some service accounts that are designed to have *ALLOBJ special authority—perhaps a profile designated to run all job scheduler jobs. What do you do with this profile’s user class? You have two choices: leave it in the *USER user class and assign *ALLOBJ once the IPL has taken place or assign it to the *SECOFR user class. I prefer the former. It’s unlikely that any service account needs all special authorities. Assigning it to the *SECOFR user class may be convenient, but you risk leaving that profile with way more special authorities than are required. It’s likely that you’re going to have a list of profiles that need adjusting after the IPL, so add these service accounts to that list.

Another set of profiles you may need to adjust are your programmers—or at least the profile your programmers use to debug production issues. It’s likely that profile will need *JOBCTL special authority after the IPL has taken place. In this case, I’d assign the special authorities required to their group. Or, if they don’t belong to a group, take this opportunity to create a group for them and assign it *JOBCTL so you only have one profile to adjust after the IPL.

Determine the Users’ Source of Authority to Application Data after IPLing

The next step is to determine how users are going to have sufficient authority to run the application once their *ALLOBJ authority has been removed. You must first decide what your security posture is going to be after the IPL. Do you want to have a secure posture so data can only be accessed by those with a business requirement—in other words, deny by default? Do you want to make sure the integrity of the data is in place but allow all people with a user profile to read it? Perhaps you have a handful of files containing confidential data that must be secured and the rest are not of concern (or you only have time to focus on those confidential files right now). Or do you know that you need to get your system off of level 20 and just want to do the bare minimum to accomplish that? Of course, I can’t dictate which posture you choose, but obviously my preference would be to have a deny-by-default approach to securing your data.

I’ve provided examples of listing object authorities and ownership in chapter 7, so look at those. Also, for a detailed explanation of implementing object-level security for an application, see chapter 17 in IBM i Security Administration and Compliance, Third Edition.

Here are the high-level steps you must take for each approach:

• Implementing a deny-by-default approach is most labor-intensive. You must identify the libraries that contain the data to be secured (I omit the libraries associated with vendor tools that don’t actually contain data—for example, job schedulers), determine which profile will own the application, ensure all application objects are owned by this profile, set program objects to adopt this owner’s authority, and secure physical and logical files with an authorization list. That’s the setup. The analysis is the intensive portion because you must identify any profile that’s updating or reading application files using an interface such as via ODBC or FTP—that is, not using an application program to read or update the file. Profiles accessing the data using non-application programs must be authorized to the authorization list securing the file. Again, step-by-step instructions for this approach are in my companion book.

• Implementing a data-integrity approach—that is, ensuring the data can be updated only via the application but can be read by all—requires the same setup as the deny-by-default approach. What makes this much less work is that you have to detect only the profiles that are legitimately changing the data outside of the application because, instead of setting the *PUBLIC authority of the database files to *EXCLUDE as you do in the deny-by-default model, you set the *PUBLIC authority to *USE. Therefore, the number of audit journal entries you have to analyze is significantly less. That said, if you have confidential data or Personally Identifiable Information (PII), this approach is not sufficient to protect that data. In this case, you need to go for either the full deny-by-default approach or a hybrid approach that secures some files more strictly than others. If you can identify where your confidential data resides, you can use Authority Collection to see which profiles are accessing it. Authority Collection is a great tool, but it generates so much information that it’s difficult to use to secure all files in an application.However, it’s fantastic when the focus is a handful of files. You’ll see examples of using Authority Collection in chapters 6 and 9.

• If you are focusing only on a handful (10 or fewer) files, I recommend that you use Authority Collection to determine who is accessing those files and by which interface. If access is via an application program, you can set the program to adopt authority as long as the owner of the program also owns (or is authorized) to the If access is via an interface such as ODBC or query or SSH, then you may want to consider attaching an authorization list, setting the file’s *PUBLIC to *AUTL, and setting the *PUBLIC authority of the authorization list to *EXCLUDE. Then authorize the users requiring access as identified via the file’s Authority Collection entries.

Using one of these two methods will take care of the files containing confidential information. But what about the rest of the application objects? How will users have sufficient authority to those once *ALLOBJ is removed from their profile? It’s highly likely that the current *PUBLIC authority setting of the rest of the application objects will be sufficient. That’s because, when creating most objects, the object’s *PUBLIC authority is set based on the value of the QCRTAUT system value. IBM ships this system value as *CHANGE. Therefore, most application objects are likely set to *PUBLIC *CHANGE. *CHANGE authority will be (more than) sufficient for most operations performed by the application. The only issue you may have is with database files. Specifically, if the application is doing something such as adding a physical file member or creating a duplicate copy of an application file, then *CHANGE won’t be sufficient. This underscores the importance of implementing and testing your new security scheme at QSECURITY level 20 prior to IPLing and having all users’ authorities adjusted.

• Now for the two approaches you can take if you just want to get off level 20:
  • Determine which profiles own the applications your users are running and assign each owner as a group profile for the application users. I absolutely do not like this approach because it gives those users *ALL authority to the application objects, including the data. (The owner of an object has *ALL authority, and everything a group owns, all members own.) However, it’s better than users having *ALLOBJ, which is the second choice.
  • Last and very much least and one I absolutely don’t recommend: After IPLing to level 40, grant back *ALLOBJ to every The only good thing about this approach is that level 40 provides operating system integrity, which cannot be achieved below level 40.

If you want to understand the gory details of the differences between each security level, see chapter 3 in IBM i Security Administration and Compliance, Third Edition or chapter 2 in the IBM i Security Reference manual.

Want to learn more?  You can pick up Carol Woodbury's book, Mastering IBM i Security, at the MC Press Bookstore Today!

 

Carol Woodbury is IBM i Security SME and Senior Advisor to Kisco Systems, a firm focused on providing IBM i security solutions. Carol has over 30 years’ experience with IBM i security, starting her career as Security Team Leader and Chief Engineering Manager for iSeries Security at IBM in Rochester, MN. Since leaving IBM, she has co-founded two companies: SkyView Partners and DXR Security. Her practical experience and her intimate knowledge of the system combine for a unique viewpoint and experience level that cannot be matched.

Carol is known worldwide as an author and award-winning speaker on security technology, specializing in IBM i security topics. She has written seven books on IBM i security, including her two current books, IBM i Security Administration and Compliance, 3^rd Edition and Mastering IBM i Security, A Modern, Step-by-Step Approach. Carol has been named an IBM Champion since 2018 and holds her CISSP and CRISC security certifications.

---

MC Press books written by Carol Woodbury available now on the MC Press Bookstore.

		IBM i Security Administration and Compliance: Third Edition Don't miss the newest edition by the industry’s #1 IBM i security expert. List Price $71.95 Now On Sale
		Mastering IBM i Security Get the must-have guide by the industry’s #1 security authority. List Price $49.95 Now On Sale