Checking System Integrity

By Rich Loeber

Much has been made over the years about the robust security features of the IBM i OS. Those of us who have been working with the system since day one, along with all those who have jumped on the bandwagon since 1988, have experience with the depth of security features that are available to us. IBM continues to proudly tout the IBM i as a highly secure environment and one that has been very resistant to virus and tampering.

So, it was with some surprise when I found the CHKOBJITG (Check Object Integrity) command on my system. If the IBM i OS is so secure, what's the deal with this command?

The stated purpose of the command it to check objects on your system for "integrity violations". Thinking that my system should be in pristine condition, I ran a quick analysis. Running the analysis is simple; it creates an *OUTFILE with the results of the analysis that you can then either view or run a Query report against. I was surprised to find several items on the report listed under my user profile name. Looking closer, however, I found that they were listed simply because they had never been converted for RISC use (showing the age of objects on my system). Whew, I'm off the hook!

The CHKOBJITG command scans your system for the following situations:

• Commands that have been tampered with
• Objects with invalid digital signatures
• Objects with an incorrect domain setting for the object's type
• Programs and/or modules that have been tampered with
• Library attributes that have been tampered with
• Objects that failed a file system scan

If any of these situations are identified, a record is logged to the output file. A violation code is posted in the record and you can use the HELP key on the command to get a list of these codes and their meanings. Keep in mind that if no violations are found, the outfile is not created. Also, your user profile must have *AUDIT special authority in order to be able to use the command.

Additional items can also be logged to the output file, such as those found on my system. These additional categories are not integrity violations per se, but can be taken as warnings. These include:

• Objects that do not have a digital signature, but could
• Objects that could not be checked
• Objects that cannot be run on this system without format changes

Those items on my system fall into this last category. Objects that cannot be checked would include *PGM objects that are in debug mode, items that were saved with the storage freed option, compressed objects and damaged objects.

The current implementation of the command has the ability to scan objects in any directory or path, which may be helpful for locating problem objects in the IFS. Earlier implementations only checked the QSYS file structure for problems.

I would love to hear from anyone who has used this command on their system and discovered any surprises. Years ago, I knew of one IBM i programmer who was able to get user programs to run in system state so that he could "do things" at the system level, but I know he's retired now. It would be interesting to me to know if there are objects on user systems that get reported and the stories that lie behind those objects.

If you have any questions about anything in this tip, just ask me and I'll give you my best shot. My email address is rich at kisco.com. All email will be answered.