AS/400 Links Partner with Rochester Institute Contact Us
Training Catalog Free Downloads Privacy / Usage


FREE AS/400, iSeries, and System i / iSeries Downloads
HOME >> FREE AS/400, iSeries, and System i / iSeries Downloads >> Making Sense of the Misunderstood Concepts
of OS/400 Security



Making Sense of the Misunderstood Concepts
of OS/400 Security

Author: Carol Woodbury


Over the years, I have received numerous questions about OS/400 security. The questions most frequently fall into one of the following categories. Of course, many would say that every aspect of OS/400 security is totally confusing! But this article tries to clarify, what seem to be, some of the most confusing aspects of OS/400 security.

User class
Most people seem to think that the user class is checked during the OS/400 security-checking algorithm. It's not. Because of this misconception, Administrators will look to see if a user is in a particular user class, such as security officer, and assume that they have the special authorities associated with that user class.

The fact is that a user can be in one user class, such as the *SECOFR user class and have no special authorities. (Normally if a user is in the *SECOFR user class they have all special authorities.) When you examine a user's capabilities, you need to look at the Special authorities they have been assigned and not the user class the user is in.

If you do alter the user's special authorities so they don't match the "normal" special authority assignments, the message, CPI2224 - User class and special authorities do not match system-supplied values, is issued. Quite honestly, I'm not sure why this message is issued because it really doesn't matter whether the special authorities assigned to the user match the default values for that user class or not. In other words, you can ignore the message.

Display and Edit Object Authority (DSPOBJAUT and EDTOBJAUT)
A couple of different values can show up on the DSPOBJAUT and EDTOBJAUT commands. If you are signed on as a user with a group profile and that group profile has been given a private authority to an object, you will see the value "*GROUP" in the User column of Display or Edit Object Authority. The group's name is listed in the Group column. It does not imply that other profiles listed are not group profiles. They might be, but if *GROUP is not shown, the profile is not one of your groups.

The other special value that can be displayed is *ADOPTED. If a program that adopts is in the call stack and you run the Display or Edit Object Authority command, *ADOPTED indicates the authority you have to the object through adopted authority. See Figure 1 for an example of both *GROUP and *ADOPTED values.


FIgure 1

Auditing
I have talked to OS/400 administrators who think you can only turn on auditing at security level 50. Auditing can be turned on at all security levels. In fact, before going to security level 40 or 50, you need to turn on auditing to determine if you need to change anything before going to level 40 or 50

Performance
Misconceptions about performance and OS/400 security abound. The first misconception is that authorization lists cause run-time performance problems. While this was true in the first release or two of OS/400, the performance issues associated with authorization lists have long since been resolved. The other misconception that is closely related is that you can't use private authorities without affecting performance.

Back in the early releases of OS/400 Version 4, IBM added an authority cache for each user. The cache holds up to 32 private authorities and up to 32 private authorities to authorization lists. If the authority-checking algorithm needs to go look in the user's profile for authority to the object, the cache is checked first. (The cache is checked very quickly; going to the user's profile takes much longer.) If the user is accessing the same set of objects or objects secured by the same authorization lists, the overhead for the check is virtually undistinguishable.

I've seen tests from the Rochester Benchmark Center where the time it took for an *ALLOBJ user to access an object (the fastest authority check performed) was basically the same as a user whose group had authority to the authorization list securing the object. I still don't recommend an overabundance of private authorities, primarily because an over-abundance of private authorities tends to indicate a scheme that is out of control and difficult to manage and maintain. Many, many private authorities will slow down your Save Security Data (SAVSECDTA) and subsequent Restore Authority (RSTAUT). However, there are definitely appropriate times to use private authorities. For those cases, you should feel free to use them and not worry about affecting performance.

The performance tools are provided to help administrators analyze and resolve performance issues. However, they give many false positives that security is the cause of the system's performance issues. In the Performance tools, the Authority Look-up Number is incremented whenever the system goes to another source (such as the user's profile or an authorization list) to determine whether the user has sufficient authority to the object. As explained earlier, looking at these other sources is a more time-consuming check. Unfortunately, the authority look-up number is also incremented when the authority comes from the user's authority cache. As described in the previous paragraph, authority coming from the cache is a fast check. Therefore, the number is no longer reliable. The authority look-up number may be high but it's likely no performance issue exists with authority checking because all of the look-ups are coming from the cache. It has been a very long time since I have heard of a performance issue being legitimately attributed to authority checking.

Another misconception is that adopted authority causes performance problems. If a program adopts authority and the owner of the program is also the owner of the object being accessed, this check is extremely fast. If the owner of the program is not the owner of the object being accessed, the check takes slightly longer (although it's doubtful that it would be noticed).

Some people seem to think that auditing the use of one object causes the whole system to slow down. This slow down used to be true, but isn't any longer. One of the last releases of Version 4 improved how the system performs the check to determine whether an audit journal entry needs to be generated. Because of this new method, you can safely audit the use of an object without affecting performance. Note, however, that there will be overhead whenever an audit journal entry is generated.

Finally, many people believe that they will have a performance issue if they move their system to security level 50. While theoretically possible, I have never seen this proven out on a customer's system.

Adopted authority
I have to attribute this misconception to two poorly named attributes of a program. The attributes that cause the confusion are the "User profile" and "Use adopted authority" parameters. (See Figure 2.) Because of the way it's worded, most people think that it is the Use adopted authority parameter that determines whether a program adopts. That's not actually the case. When set to *OWNER, it is the User profile parameter that causes the program to adopt its owner's authority. (By the way, the default for this parameter is*USER which means that the program does not adopt authority.) The Use adopted authority parameter determines whether the program will use the adopted authority being passed to it from a program that is higher in the call-stack. Adopted authority is call-stack based. When a program is called and it adopts authority, as long as the program remains in the call-stack, the adopted authority will be in effect. So if Pgm_A adopts authority and calls Pgm_B and Pgm_B calls Pgm_C, Pgm_C, will be able to use the adopted authority from Pgm_A. The default for this parameter is *YES which means that by default, programs always use the adopted authority available to it.

Figure 2

*ALLOBJ special authority
Some administrators still don't understand the power associated with *ALLOBJ special authority. Once you assign a user *ALLOBJ special authority, you cannot prevent that user from accessing objects. You can grant an *ALLOBJ user a private authority *EXCLUDE, but it won't prevent the *ALLOBJ user from accessing the object. When OS/400 sees that the user has *ALLOBJ, the user is granted access to the object. In other words, once *ALLOBJ is found, the authority checking algorithm stops and allows the user to access the object. The algorithm never gets to the user's private authority.

Authority checking between security levels
Some administrators seem to think authority checking is different between the various security levels. Most think there is no checking at security level 20. Additionally, many think OS/400 performs more checking at security levels 40 and 50. In fact, the same authority checking algorithm runs at all security levels. It looks like there is no authority checking at security level 20 because, by default, all profiles are created with *ALLOBJ special authority. However, you can remove a user's *ALLOBJ at level 20 and simulate what will happen on the system when you move to security level 30. Security levels 40 and 50 provide "system integrity," but that does not include additional authority checking. There is one exception. At security level 30, to use a job description, you only need authority to the job description, even if it names a specific user profile under which to run the jobs. At security levels 40 and 50, you must have authority to both the job description and the user profile it specifies.

Integrated File System (IFS)
Finally, some administrators do not feel they need to pay attention to the IFS. Because they are not using their iSeries as a Web server, they can forget about the IFS. The truth is that the IFS needs to be examined on all systems because IBM ships more and more code in the Integrated File System. In addition, IBM and other vendors are increasingly enabling functions that require the use of the IFS.

Many administrators are also unaware that the IFS can host viruses. While the viruses we have heard so much about do not affect OS/400 itself, the IFS can be. Patrick Botz, eServer Security Architect and I co-authored a detailed white paper about OS/400 and viruses. The paper, "Virus got You Down?" can be found on my company's website at www.skyviewpartners.com.

Perhaps this article was old news to you and if that's the case, gold stars to you for being honor roll students of OS/400 security. For the rest of you, I hope this article has helped clarify some of the misperceptions you may have had about OS/400 security. 


Carol Woodbury is co-founder of SkyView Partners, a firm specializing in security consulting and assessments as well as assessment software. Carol has over 13 years in the security industry, 10 of those working for IBM's Enterprise Server Group as the AS/400 Security Architect and Chief Engineering Manager of Security Technology. Look for Carol's second book, Experts' Guide to OS/400 Security, to be released later this spring. Carol can be reached at carol.woodbury@skyviewpartners.com