Planning 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:

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:

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.

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:

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:

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:

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:

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:

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.

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.

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:

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:

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.

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.

 

Parent topic:

Planning resource security