Removing Owner's Authority

Q: I read somewhere that removing the owner's authority to an object will reduce the number of private authorities on the system, saving me time on my Save Security Data (SAVSECDTA) process as well as on the Restore Authority (RSTAUT) process. And, as a bonus, it will also save space in user profiles. Is this true?

A: In a word--no. That's true if you have given someone other than the owner a private authority, but not the owner. Here's a little bit about how authorities are stored internally in a user profile object:

Stored in a user profile (among other things) are
--An entry for every object the profile owns
--An entry for every object the profile has a private authority to
--An entry for every user who has a private authority to an object owned by this profile

Even if you remove the owner's authority to the object, his user profile entry for owning the object doesn't go away. The authority you see for the owner through Edit Object Authority (EDTOBJAUT) or Display Object Authority (DSPOBJAUT) is not a private authority entry. So removing it does not remove a user profile entry.

Now, let's look at the user profile entries created when you grant an individual or group profile a private authority to an object by using the EDTOBJAUT or Grant Object Authority (GRTOBJAUT) command. Say we grant Allison a private authority to one of Suzanne's owned objects. A "private authority" entry is added to Allison's user profile and a "someone has a private authority to one of my owned objects" entry is added to Suzanne's user profile. If you then remove Allison's private authority, two user profile entries are removed--one from each profile. Why is this important?

When you do a SAVSECDTA, all of a user's private authorities are saved. The more private authorities on the system, the longer this process takes. In a recovery situation or when you are restoring a system onto new hardware, the process is to restore the profiles, then restore the objects, then run the Restore Authority (RSTAUT) command, which puts back all of the user's private authorities. Once again, the more private authorities you have on the system, the longer the RSTAUT takes.

Now, back to object ownership. The owner's authority to an object is stored with the object itself. Therefore, it is both saved and restored with the object and is not part of either the SAVSECDTA or the RSTAUT. Hopefully, it's now obvious why removing an object's ownership does not save either space or time, but removing private authorities does both.

Reducing private authorities is another reason to use authorization lists. Rather than having entries for every object, there is an entry in the authorization list owner's profile for owning the authorization list, an entry for each user authorized to the authorization list, and a private authority entry in each profile authorized to the authorization list. If the authorization list secures 100 objects, the savings is significant. It's even more significant because files and members are actually made up of multiple internal objects, with each object requiring the appropriate user profile entries.

Debugging Access Failures from Application Administration

Q: I've recently learned about the host applications that you can control using Application Administration in Operations Navigator (now known as iSeries Navigator). I set some of the functions to restrict access, but some system functions then didn't work. How can I tell if I've set something to be too restrictive?

A: First of all, let's make sure everyone knows what we're talking about. Open up Operations Navigator, right-click on the system name you're connected to, and select Application Administration. You'll see a window with three tabs: AS/400 Operations Navigator, Client Applications, and Host Applications. The first two tabs allow you to control the Ops Nav or Client Access Express or iSeries Access functions that appear on a user's desktop. The last tab provides true security function in that it provides access control--that is, it provides another mechanism that prevents users from doing things. If you click on the Host Applications tab and expand the list, you will see that you can control use of FTP, Digital Certificate Manager (DCM), and service tool usage. It's an obscure but pretty cool function.

Now back to the question.
 
The best way that I know of to determine whether you've set something to be too restrictive is to look in the audit journal. If you have *SECURITY specified as one of the values for the QAUDLVL system value and someone tries to perform a function that they've been restricted from using App Admin, you will see a GR audit journal entry listing the failure. To confirm this, I configured JOE_USER to not be able to do the Change Directory subfunction of the FTP Server. I logged on to FTP as JOE_USER and tried to do a change directory. After it failed, I went to the audit journal. There, you will find a GR type entry. One of the possible values for one of the fields in this type of entry is *USAGEFAILURE. The easiest way to look for this information is through the Display Audit Journal Entry (DSPAUDJRNE) command, specifying GR for the ENTTYP (Entry type) parameter. Also, you might want to take a look at the iSeries Security Reference manual Appendix F. There, you'll find the layouts for all of the model outfiles for all audit journal entry types. 

How Much Security Do Exit Programs Provide?

Q: What's the difference between the QIBM_QCA_RTV_COMMAND and the QIBM_QCA_CHG_COMMAND exits? Should these be considered security tools?

A: The QIBM_QCA_CHG_COMMAND exit point allows you to register an exit program for a particular command. That exit program will receive the command string the user entered before the command is run. If the user does not specify the library for the command (e.g., *LIBL/CHGJOB), you can actually change the command string being entered. However, if the user enters the library for the command (e.g., QSYS/CHGJOB), the exit program will receive--but not be able to change--the command string.

The QIBM_QCA_RTV_COMMAND exit sends the exit program the command string, but in no cases can you change the command string. However, your exit program could log the command string and retrieve information about the current job--such as the process user profile name (be careful; don't retrieve the job user name because it might be different from the name of the user actually running the job)--and then log it to a journal. This way, you could track who was running the Change Job (CHGJOB) command (or some other command). You can define up to 10 exits programs to be called per command.

So are these security functions? I have a hard time declaring the CHG_COMMAND exit to be security-related simply because its behavior (the ability to change the command string) is not foolproof. Once people know to library-qualify a command, they know their command string will not be changed. However, the RTV_COMMAND string is different. You can consistently send an audit journal entry every time a command is run. I consider this exit point to be a part of the "security bag of tricks" that OS/400 provides.

You can find the documentation for these two exit programs in the IBM iSeries Information Center. Go to Programming->CL and APIs->APIs->Exit programs. Look for Command Analyzer Change and Command Analyzer Retrieve.

Q: I'm trying to get a list of all the objects a particular user owns, but when I run the Display User Profile (DSPUSRPRF) *OBJOWN option and send it to an outfile, I get a message that not all objects are included in the list. What's going on, and how to I get a complete list?

A: The issue is that the user owns objects in the Integrated File System (IFS). IFS objects use pathnames and the outfile can only handle fixed-length fields. You will have to use the QSYLOBJA (List Object Authority) API. This API provides similar function to the Display User Profile (DSPUSRPRF) command. Several of its formats provide object information using pathnames.

Again, you can find the documentation for these two exit programs in the IBM iSeries Information Center. Go to Programming->CL and APIs->API by Category->Security. 

That's all for this month's "Security Patrol." Happy New Year, everyone!


Carol Woodbury is co-author of the book Implementing AS/400 Security as well as co-founder of SkyView Partners, a firm specializing in security consulting and services. Carol has 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. Carol recently authored iSeries security training videos that are now available for purchase at www.expertanytime.com. Carol can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..