This topic describes how to plan security for the libraries on your system.
Many factors affect how you choose to group your application information into libraries and manage libraries. This topic addresses some of the security issues associated with library design. To access an object, you need authority to the object itself and to the library containing the object. You can restrict access to an object by restricting the object itself, the library containing the object, or both.
Planning Libraries
A library is like a directory used to locate the objects in the library. *USE authority to a library allows you to use the directory to find objects in the library. The authority for the object itself determines how you can use the object. *USE authority to a library is sufficient to perform most operations on the objects in the library.
Using public authority for objects and restricting access to libraries can be a simple, effective security technique. Putting programs in a separate library from other application objects can also simplify security planning. This is particularly true if files are shared by more than one application. You can use authority to the libraries containing application programs to control who can perform application functions.
Library security is effective only if these rules are followed:
Describing Library Security
As an application designer, you need to provide information about a library for the security administrator. The security administrator uses this information to decide how to secure the library and its objects. Typical information needed is:
Library name: ITEMLIB
Public authority to the library: *EXCLUDE
Public authority to objects in the library: *CHANGE
Public authority for new objects (CRTAUT): *CHANGE
Library owner: OWNIC Include on library lists? No. Library is added to library list by
initial application program or initial query program.
List any functions that require *ADD authority to the library: No objects are added to
the library during normal application processing.
List any objects requiring *OBJMGT or *OBJEXIST authority and what functions need that
authority: All work files, whose names begin with the characters ICWRK, are cleared at
month-end. This requires *OBJMGT authority.
Using library security to complement menu security
To access an object in a library, have authority both to the object and to the library. Most operations require either *EXECUTE authority or *USE authority to the library. Depending on your situation, you may be able to use library authority as a simple means for securing objects. For example, assume that for the Order-Entry menu example, everyone who has authority to the Order Entry menu can use all of the programs in the ORDERPGM library.
Rather than securing individual programs, you can set the public authority to the ORDERPGM library to *EXCLUDE. You can then grant *USE authority to the library to specific user profiles, which will allow them to use the programs in the library. This assumes that public authority to the programs is *USE or greater. Library authority can be a simple, efficient method for administering object authority. However, ensure that you are familiar with the contents of the libraries that you are securing so that you do not provide unintended access to objects.
Planning security for application libraries: After you have determined your objectives for your resource security, you can begin planning security for application libraries. Choose one of your application libraries to work with as you follow the process described here. If your system stores files and programs in separate libraries, choose a library that contains files. When you finish the topic, repeat these steps for your remaining application libraries.
Review the information that you gathered about your the applications and libraries:
Deciding public authority to application libraries: For purposes of resource security, the public means anyone you authorize to sign on to your system. Public authority allows a user access to an object if you have not any other more specific access. In addition to deciding public authority for objects already in the library, you can specify the public authority for any new objects added to the library later. To do this, you use the Create Authority (CRTAUT) parameter. Usually, public authority to library objects and library create authority for new objects should be the same.
The Create Authority (QCRTAUT) system value determines the system-wide public authority for new objects. IBM ships the QCRTAUT system value with *CHANGE. Avoid changing QCRTAUT, because many system functions use it. If you specify *SYSVAL for the CRTAUT of an application library, it uses the QCRTAUT system value (*CHANGE).
Use public authority as much as possible, for both simplicity and good performance. To determine what public authority to a library should be, ask these questions:
Ensuring adequate authority: *CHANGE authority to objects and *USE authority to a library are adequate for most application functions. However, you need to ask your programmer or application provider some questions to determine if certain application functions require more authority:
Deciding public authority to program libraries: Often, application programs are kept in a separate library from files and other objects. You are not required to use separate libraries for applications, but many programmers use this technique when they design applications. If your application has separate program libraries, you need to decide the public authority to those libraries.
You can use *USE authority to both the library and the programs in the library to run programs sufficiently, but program libraries may have other objects that require additional authority. Ask your programmer a few questions:
A knowledgeable programmer who has access to a library may be able to retain access to objects in the library even after you have revoked authority to the library. If a library contains objects with high security requirements, restrict the objects and the library for complete protection.
Determining ownership of libraries and objects: After you plan security for application libraries, you can decide ownership of libraries and objects. Each object is assigned an owner when it is created. The owner of the object automatically has all authority to the object, which includes authorizing others to use the object, changing the object, and deleting it. The security officer can perform these functions for any object on the system.
The system uses the profile of the object owner to track who has authority to the object. The system completes this function internally. This may not affect the user profile directly. However, if you do not plan object ownership properly, some user profiles can become very large.
When the system saves an object, the system also saves the name of the owning profile with it. The system uses this information if it restores the object. If the owning profile for a restored object is not on the system, the system transfers ownership to an IBM-supplied profile called QDFTOWN.
Recommendations: The recommendations below apply in many, but not all, situations. After reviewing the recommendations, discuss your ideas for object ownership with your programmer or application provider. If you purchase applications, you may not be able to control what profile owns libraries and objects. The application may be designed to prevent changes of ownership.
Deciding ownership and access for user libraries: If your system has the IBM® Query for iSeries™ licensed program or another decision support program, your users need a library for storing the query programs they create. Normally, this library is the current library in the user profile. If a user belongs to a group, you use a field in the user profile to specify whether the user or the group owns any objects created by the user.
If the user owns the objects, you can specify what authority the group members have to use the objects. You can also specify whether the group’s authority is primary group authority or private authority. Primary group authority may provide better system performance. The Group authority to objects created field is not used if the owner of objects created is the group. Group members automatically have *ALL authority to any objects created.
Decide who should own and have access to user libraries. Enter your choices in the Owner of objects created and Group authority over objects fields on the Individual User Profile form. Now you are ready to begin grouping objects.
Grouping objects
After you have determined ownership of libraries and objects, you can begin grouping objects on the system. To simplify managing authorities, use an authorization list to group objects with the same requirements. You can then give the public, group profiles, and user profiles authority to the authorization list rather than to the individual objects on the list. The system treats every object that you secure by an authorization list the same, but you can give different users different authorities to the entire list.
An authorization list makes it easier to reestablish authorities when you restore objects. If you secure objects with an authorization list, the restore process automatically links the objects to the list. You can give a group or user the authority to manage an authorization list (*AUTLMGT). Authorization list management allows the user to add and remove other users from the list and to change the authorities for those users.
Recommendations:
Library Security
Most objects on the system reside in libraries. To access an object, you need authority both to the object itself and the library in which the object resides. For most operations, including deleting an object, *USE authority to the object library is sufficient (in addition to the authority required for the object). Creating a new object requires *ADD authority to the object library. Appendix D shows what authority is required by CL commands for objects and the object libraries.
Using library security is one technique for protecting information while maintaining a simple security scheme. For example, to secure confidential information for a set of applications, you could do the following:
Library Security and Library Lists
When a library is added to a user’s library list, the authority the user has to the library is stored with the library list information. The user’s authority to the library remains for the entire job, even if the user’s authority to the library is revoked while the job is active. When access is requested to an object and *LIBL is specified for the object, the library list information is used to check authority for the library. If a qualified name is specified, the authority for the library is specifically checked, even if the library is included in the user’s library list.
If a user is running under adopted authority when a library is added to the library list, the user remains authorized to the library even when the user is no longer running under adopted authority. This represents a potential security exposure. Any entries added to a user’s library list by a program running under adopted authority should be removed before the adopted authority program ends. In addition, applications that use library lists rather than qualified library names have a potential security exposure. A user who is authorized to the commands to work with library lists could potentially run a different version of a program.