Carol discusses the security features coming in the new version of IBM i.

V7R3 provides some new and changed features in the IBM i integrated auditing function as well as a new feature that will take the guesswork out of implementing object-level security. I want to save the best for last, so I’ll start with the updated auditing features.

New and Changed Auditing Features

The CP (Changes to User Profiles) audit journal entry has always contained useful information about a user profile, but in previous releases it logged only the security-relevant user profile attributes when a profile was created or changed. CP entries never included attributes such as the Attention program, Job description, Limit device sessions, or Message queue. In V7R3, all of the attributes with the exception of the TEXT and AUT (*PUBLIC authority) attributes are part of the CP audit journal entry when a profile is created, and all fields except the TEXT field are part of the entry when a profile is changed.

Three new values can be specified for the QAUDLVL (Auditing level) system value: *NETSECURE (to audit secure network connections), *NETTELSVR (to audit Telnet connections), and *NETUDP (to audit UDP connections). In addition, *NETSCK is no longer considered a subset of *NETCMN. While the mail and DHCP functions logged with *NETSCK will still be logged when specifying *NETCMN, if you want to log accepts and connects of socket connections, you must specify *NETSCK separately for QAUDLVL.

Authority Collection

V7R3 introduces a feature called authority collection. Authority collection is part of the base operating system and requires no additional operating system features. Authority collection provides a way to determine exactly what authority is required when an object (such as a program, file, or directory) is accessed. The motivation behind IBM’s providing this function is to provide a tool to help security administrators and application providers understand the minimum authority required when accessing objects. If you think about the security scheme of most IBM i applications, they were designed with menu security but did not take care to properly secure the application objects (e.g., files, programs, data areas). As a result, many applications’ objects are set with *PUBLIC authority of *CHANGE or *ALL when a more restrictive setting would be sufficient. Authority collection will make changing the authority settings less risky because you can tell—prior to changing any settings—exactly what authority is required for each application function.

To use authority collection to rework an application’s security settings, choose one of your power users and run the STRAUTCOL (Start Authority Collection) command (see Figure 1). You have many options for specifying what data you want to collect. I’m guessing that you’ll be like I was when I first started to use this feature and specify that you want to collect everything! Once you do that and start to look at the data, you’ll quickly find out that the analysis is far less overwhelming if you narrow down what is collected. So in this example, I have specified that I want to collect the authority information whenever user CWOODBURY accesses *PGM and *FILE objects in the APPDTALIB, APPOBJLIB, and LOCLIB libraries.

Once you run this command, the collection starts immediately—no need to have CWOODBURY log off, then on again. You can also view the collected data at any time—no need to end the collection prior to viewing it. Once CWOODBURY has run through her tasks, you can examine what has been collected by running a query against the AUTHORITY_COLLECTION view.

Figure 1: The STRAUTCOL (Start Authority Collection) command

The amount of information recorded for each entry in the collection has more details than you’ll likely ever need or want to know. However, some information is invaluable—specifically the DETAILED_REQUIRED_AUTHORITY and DETAILED_CURRENT_AUTHORITY fields. The field names perfectly describe their contents. With the DETAILED_REQUIRED_AUTHORITY field, gone is the guessing game or trial and error when trying to determine how much authority to assign. Also incredibly useful are the AUTHORITY_SOURCE and ADOPTED_AUTHORITY_SOURCE fields, which list where the authority named in the DETAILED_CURRENT_AUTHORITY field comes from.

Authority collection is not limited to libraries and objects in libraries. You can also collect authority information about directories and objects in directories as well as Document Library Objects (DLOs) and folder objects.

I wish the authority collection feature had been available at one of our clients when we were trying to secure a directory containing sensitive information. Before we could secure the directory, we had to determine what authority the service account writing into the directory required. We thought we had granted the profile the correct authority, but when we ran the process, it failed with an authority error. Through trial and error, we finally got the authority set correctly. If authority collection had been available, we could have simply turned on authority collection for the service account, specifying the directory being secured, run the process, examined the DETAILED_REQUIRED_AUTHORITY field, granted the authority listed to the service account, set *PUBLIC authority to *DTAAUT(*EXCLUDE) OBJAUT(*NONE), and then know that the process would continue to work as it did previously.

Figure 2 shows the result of running a query against the AUTHORTY_COLLECTION view. In this case, I wanted to see only the pathname, the authority required, and the current authority. The first line of Figure 2 shows the entry that was logged when the attempt to list the contents of a directory failed. The second and third lines show the entries when the access completed successfully after I granted the user DTAAUT(*RX) OBJAUT(*NONE) to the /SkyView directory.

Figure 2: Using Run SQL Scripts to query the contents of the authority collection

Authority collection can be used to simply and verify the authority settings in many situations. Here are just a few:

• Run a query before rolling out a new security implementation to your entire user base and ensure your test users have all the authority required to run the application and that it’s coming from the source you intended.
• Determine which application objects (especially *FILE objects) can have their authority immediately set to a more restricted authority setting, without fear that the application will stop working. This is especially helpful when the QCRTAUT system value has been set to *ALL. Some file accesses (such as when adding a physical file member) require more than *CHANGE authority. So it’s difficult to know what will break if you change QCRTAUT from *ALL to the system default of *CHANGE. You can query the authority collection and list the files that require more than *CHANGE authority to run the application. You may want to secure the files even further, but you can at least make this initial step to start to reduce your risk.
• Determine the exact authority required to work with IFS objects prior to implementing a new FTP process or ODBC connection on production.
• Determine the authority required for service accounts to work with database files. Service accounts are often created with *ALLOBJ special authority because the authority that’s required is unknown. Simply turn on the authority collection for the service account, examine the entries, and determine the authority required. Undoubtedly, it will not require *ALLOBJ!
• Use the authority-required fields to prove to developers and application providers that *ALL authority is not required!

Here’s some additional information about authority collection:

• To run the authority collection commands, you must have either *ALLOBJ special authority or be authorized to the Database Security Administrator function (QIBM_DB_SECADM). You can administer this function via Application Administration (which is available as part of Navigator for i) or the Work with Function Usage (WRKFCNUSG) command.
• The Limit User Function (Application Administration) settings are not recorded.
• For those features where authority to an object plus some special authority is required, the special authority requirement is not recorded. For example, the CRTUSRPRF (Create User Profile) command requires the user to have *SECADM special authority. The special authority requirement is not in the authority collection.
• To display whether a collection is active and/or an authority collection repository exists for a user, run the DSPUSRPRF (Display User Profile) command and scroll to the end of the display.
• While a user’s collection setting is saved when running the SAVSECDTA (Save Security Data) command, the actual collection data is not. If you want to save the collection data, you’ll have to save it into a file, which can then be saved/restored through normal IBM i interfaces.
• If an authority collection exists and the profile is deleted, its authority collection is also deleted.
• If you specify to collect authority for all objects in all libraries, some objects, such as operating system programs are omitted from the collection; however, objects, such as IBM-supplied commands will be included in the collection data
• See Chapter 10 (new in V7R3 and dedicated to this new feature) of the IBM i Security Reference manual for more details of the authority collection, including the complete layout of the authority collection view.