Much has been made over the years about the robust security features of OS/400. 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 OS/400 as a highly secure environment and one that has been immune to virus and tampering.
So, it was with some surprise when I recently stumbled over the CHKOBJITG (Check Object Integrity) command on my system. If OS/400 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 not yet been converted for RISC use. 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
If any of those 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.
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 they can be taken as warnings. These include the following:
- 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 V5R1 and V5R2 implementations of the command have the ability to scan objects in any directory or path, which may be helpful for locating problem objects in the IFS. Earlier implementations checked only 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 AS/400 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. So, if you find anything, please e-mail me at rich@kisco.com. I'd be interested to hear your stories and will publish them in future articles.
About the author:. Rich Loeber is president of Kisco Information Systems Inc. in Saranac Lake, N.Y. The company is a provider of various security products for the iSeries market.
==================================
MORE INFORMATION
==================================
- Identify nonsystem objects in system libraries
A user asks, "Is there a fail-safe way of identifying all the nonsystem objects in the system libraries?" Security expert Carol Woodbury says there are two OS/400 commands you can try.
- Increasing security levels
What are the ramifications of going from security level 20 to level 30 and possibly 40? Security expert Carol Woodbury explains.
- Top 10 iSeries security tips
Security problems on the iSeries don't make big news, but there are things you need to be careful of. Let Search400.com help you with these top security tips.
- Expert advice on security
Get answers to your iSeries security questions from Search400.com expert Carol Woodbury.
