Library List Security - Part 1

By Rich Loeber

The library list on your IBM i controls how the IBM i OS 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 an object access is requested by a program and the request is not library specific, the IBM i OS 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 and most secure 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 very 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 actual 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 their 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 IBM i library, QSYS, is a requirement for IBM i OS functions to run properly. In many shops, the QSYS2 library is also needed as it contains objects required for many system APIs. If your code, or a software vendor's code, uses any IBM i OS APIs, you'll need this library in the system list. From the factory, you will normally also find the QHLPSYS and QUSRSYS libraries. The QHLPSYS library contains the help text panel groups for the IBM i OS and should be left in the list, but you should make sure that public only has *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 check their availability to the public and make sure they are restricted. You should also validate the business reason for having non-IBM libraries in the system library list on your system.

In a future tip, I'll take a look at controlling the user library list and the current and production library entries.

If you have any questions about this topic, you can reach me at rich at kisco.com, I'll give it my best shot. All email messages will be answered.