Plan library security

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:

Libraries contain objects with similar security requirements.
Users are not allowed to add new objects to restricted libraries. Changes to programs in the libraries are controlled. That is, application libraries should have public authority of *USE or *EXCLUDE unless users need to create objects directly into the library.
Library lists are controlled.

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:

Any application functions which add objects to the library.
Whether any objects in the library are deleted during application processing.
What profile owns the library and its objects.
Whether the library should be included on library lists.

See the following sample format for providing this information:

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.

Use library security to complement menu security

To access an object in a library, you must 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, you must 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:

Application Description form
Library Description form
User Group Description form for any groups that need the library
Your diagram of applications, libraries, and user groups

Think about which groups need the information in a library, why they need it, and what they need to do with it. Determine the contents of the application libraries, as they contain the important application files. They may also contain other objects, most of which are programming tools to make the application work properly, such as:

Work files
Data areas and messages queues
Programs
Message files
Commands
Output queues

Most of the objects, other than files and output queues, do not represent a security exposure. They usually contain small amounts of application data, often in a format that is not easily intelligible outside the programs. You can list names and descriptions of all the objects in a library by using the Display Library command. For example, to list contents of the CONTRACTS library: DSPLIB LIB(CONTRACTS) OUTPUT(*PRINT) Next you need to decide what public authority you want to have for application libraries and program 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:

Should everyone in the company have access to most of the information in this library?
What kind of access should people have to the majority of the information in this library?

Concentrate on decisions for the majority of the people and the majority of the information. Later, you will learn how to deal with the exceptions. Planning resource security is often a circular process. You may discover that you need to make changes to public authority after considering the requirements for specific objects. Try several combinations of public and private authority to both objects and libraries before you choose one that meets your security and performance needs.

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:

Are any files or other objects in the library deleted during processing? Are any files cleared? Are members added to any files? Deleting an object, clearing a file, or adding a file member requires *ALL authority to the object.
Are any files or other objects in the library created during processing? Creating an object requires *CHANGE authority to the library.

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:

Does the application use data areas or message queues to communicate between programs? Are they in the program library? *CHANGE authority to the object is required for handling data areas and message queues.
Are any objects in the program library, such as data areas, deleted during processing? *ALL authority to an object is required to delete the object.
Are any objects in the program library, such as data areas, created during processing? *CHANGE authority to the library is required to create any new objects in the library.

Fill in all of the resource security information on both parts of the Library Description form except the library owner and the authorization list column. You then can determine ownership of libraries and objects.

Note: 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.

Avoid using an IBM-supplied profile, such as QSECOFR or QPGMR, as an application owner. These profiles own many objects in IBM-supplied libraries and are already very large.
Normally, a group profile should not own an application. Every member in the group has the same authority as the group profile, unless you specifically assign lower authority. In effect, you would be giving every member of the group complete authority to the application.
If you plan to delegate responsibility for control of applications to managers in various departments, those managers could be the owners of all the application objects. However, the manager of an application might change responsibilities. If that is the case, then you would transfer ownership of all the application objects to a new manager.
Many people use the technique of creating a special owner profile for each application with the password set to *NONE. The owning profile is used by the system to manage authorities for the application. The security officer, or someone with that authority performs the actual management of the application or it is delegated to managers with *ALL authority to particular applications.

Decide what profiles should own your applications. Enter the owner profile information on each Library Description form. You can now decide ownership and access for your user libraries.

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:

Use authorization lists for objects that require security protection and that have similar security requirements. Using authorization lists encourages you to think about categories of authority rather than individual authorities. Authorization lists also make it easier to restore objects and to audit the authorities on your system.
Avoid complicated schemes that combine authorization lists, group authority, and individual authority. Choose the method that best suits the requirement, rather than using all of the methods at the same time.

You will also need to add the naming convention for authorization lists to your Naming conventions form. Once you have prepared an AuthorizationlList form, go back and add that information to your Library description form. Your programmer or application provider might have already created authorization lists. Be sure to check with them.

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:

Use a library to store all confidential files for a particular group of applications.
Ensure that public authority is sufficient for all objects (in the library) that are used by applications (*USE or *CHANGE).
Restrict public authority to the library itself (*EXCLUDE).
Give selected groups or individuals authority to the library, using *USE or *ADD if the applications require it.

Although library security is a simple, effective method for protecting information, it may not be adequate for data with high security requirements. Highly sensitive objects should be secured individually or with an authorization list, rather than relying on library security.

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.

Note: 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.