Securing the IFS remains a mystery to most, but with more confidential data being stored in the IFS, it’s time to figure it out.

Even though the IFS has been part of the system since V3R6, most administrators have never understood how or why it should be secured. However confusing it might seem, it should not be ignored. Most organizations have at least one directory that contains confidential information that should be secured. Let me see if I can clear up some confusion so that you can take steps to secure your confidential data residing in the IFS.

Clearing Up the Confusion

I think one of the reasons securing the IFS is such a mystery is that the authorities are named differently than what we use when securing libraries and objects in libraries. Instead of *ALL, *CHANGE, *USE, and *EXCLUDE, the authorities are denoted using UNIX terminology. (It’s based on UNIX terminology because, after all, that’s how the IFS came into being; there was an effort by IBM to get UNIX applications running on the iSeries.)

In the IFS, authorities are split into two groups: data authorities (*OBJOPR, *READ, *ADD, *UPD, *DLT) and object authorities (*OBJMGT, *OBJEXIST, *OBJALT, *OBJREF). Here’s how these translate from the familiar to the unfamiliar:

*ALL = DTAAUT(*RWX) OBJAUT(*ALL)

*CHANGE = DTAAUT(*RWX) OBJAUT(*NONE)

*USE = DTAAUT(*RX) OBJAUT(*NONE)

*EXCLUDE = DTAAUT(*EXCLUDE OBJAUT(*NONE)

The key is to make sure you specify both sets of authorities, especially the object authorities. It doesn’t make much sense to set the data authorities to *EXCLUDE and leave the object authorities at *ALL, for example. With those permissions, I can’t read the contents of the object, but I can delete it!

Another point of confusion is how authority is set when an object is created. In general, the authorities come from the directory in which the object is being created. For example, the root directory (/) ships as *PUBLIC authority set to DTAAUT(*RWX) OBJAUT(*ALL). When a subdirectory is created under root, it inherits that *PUBLIC authority setting. That’s why most directories in the IFS that I review are wide open—because they’ve inherited the wide-open setting of root. *PUBLIC authority is not the only authority inherited. If the directory is secured with an authorization list, has private authorities, or has a primary group assigned, these authorities are also inherited. The exception to this is when a Copy to Stream File (CPYTOSTMF) or Copy to Import File (CPYTOIMPF) is performed. When these commands were first introduced, the authorities on the resulting stream file were hardcoded such that the owner only had DTAAUT(*RWX) OBJAUT(*NONE)—that is, *CHANGE vs. *ALL, *PUBLIC authority was set to DTAAUT(*EXCLUDE) OBJAUT(*NONE), and no private authorities or authorization list were inherited. This behavior wreaked havoc when users other than the creator needed to read the file or when the owner needed to delete and re-create the file. Fortunately, in V6R1, an option was added to these commands that provides you with the ability to specify that the authority should come from the directory the file is being created into or from the file being copied. Unfortunately, the default behavior didn’t change, so people have to know about these options to take advantage of them.

Changing Authorities

It’s likely that not everything in your IFS needs to be secured. You may have created directories to hold image catalogues before applying PTFs or as a staging area for a product upgrade. These directories can be skipped or even deleted if you’re done with the task. But usually one or more directories contain at least one file with confidential information. Once you find those directories, you must first determine what profiles need access before you secure it. A variety of ways exist to find out the profiles needing access— for example, if there are multiple objects in the directory, look at the owner of the objects. If all are owned by the same profile, it’s likely that that’s the only profile needing access. But the definitive way to know is to look in the audit journal and examine the Creation of Objects (CO), Deletion of Objects (DO), and Object Move (OM) entries. Better yet, if you are running V7R4, you can take advantage of the Authority Collection feature. You can turn on the collection at the object level—in this case, the directory you’re trying to secure. The collection will list all profiles accessing the directory along with the authority required.

Once you do your research and determine the profiles needing access, directories containing confidential information are typically set to DTAAUT(*EXCLUDE) OBJAUT(*NONE). The root directory also needs to be secured. But a word of warning: DO NOT set the *PUBLIC authorities of the root directory to *EXCLUDE! Even if your own processes don’t break, internal operating system functions will, and the outcome will not be pleasant. Prior to securing root, you must first determine if objects are being created directly into it. Once again, look at the CO, DO, and OM entries in the audit journal. If you discover activity, the process should be reworked such that the object is being created/deleted/moved into a subdirectory rather than directly into root. Only after verifying there’s no activity should you change the *PUBLIC authority of root to the recommended setting of DTAAUT(*RX) OBJAUT(*NONE).

Final Thoughts

Note that my recommendations for root also apply to QOpenSys. QOpenSys behaves the same way root behaves. The difference between the two is that QOpenSys is case-sensitive and root is not.

I’m hoping that this discussion has helped you feel more comfortable about IFS security and that you are able to take steps to identify directories containing confidential information and secure them appropriately.