The library list on your i5-iSeries-AS/400 controls how OS/400 searches for objects when no specific library has been coded. Changes to the library list could easily be used to execute a rogue program or cause your processing to run against an incorrect set of data. Controlling how your library lists are set up on your system can mean the difference between secure and insecure processing.
The library list has four main components. These are the system library list, the current library, the product library, and the user library list. When object access is requested by a program and the request is not library-specific, OS/400 will search the system for the object requested in this sequence. The first object found with the right name and object type will be used. This could be to satisfy a program-to-program call, a request for a data file object or any other object access request.
The best solution is to always code your object requests as library-specific. For testing and other reasons, using the search capabilities of the library list can be a handy solution. But as you can see, it poses security risks.
The easiest illustration of a security risk is interposing an alternate (and malicious) program so that it gets called in place of the program object you really want to call. The alternate program could, for example, do the same processing but store credit card information in a private file for later access and abuse. Your user has no knowledge that anything unusual is going on, but information from his processing is being hijacked.
To limit the possibilities, it is important that you specifically limit the number of libraries that appear in your library lists. You must also control who is allowed to make changes, and you must have a clear business case made to add new libraries to either the system or user library list.
The system library list is maintained as a system value and should be kept to a minimum. The entry for the OS/400 library, QSYS, is a requirement for OS/400 functions to run properly. In many shops, the QSYS2 library is also needed, as it contains OS/400 objects required for many system APIs. If your code, or your software vendor's code, uses any OS/400 APIs, you'll need this library in the system list.
From the factory, you will also normally find the QHLPSYS and QUSRSYS libraries. The QHLPSYS library contains the help text panel groups for OS/400 and should be left in the list, but you should make sure that public has only *USE access to objects in the library.
Leaving QUSRSYS in the list is another matter. It should also have a public setting of *USE, but you should examine other special authorities set up for the library to make sure that the ability to create and add objects to this library is severely limited. If you find any other libraries in the system library list, you must also check their availability to the public and make sure they are restricted. In addition, you should validate the business reason for having non-IBM libraries in the system library list on your system.
Go back and take a look at your library lists, and next time I'll review controlling the user library list and the current and production library entries.
If you have any specific questions about this topic, you can reach me at rich@kisco.com, I'll try to answer your questions. All e-mail messages will be answered.
---------------------------
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.
