Plan object authority

Following are several suggestions when you restrict authority to IBM-supplied objects:

• When you have more than one national language on your system, your system has more than one system (QSYS) library. Your system has a QSYSxxxx library for each national language on your system. If you are using object authority to control access to system commands, remember to secure the command in the QSYS library and in every QSYSxxx library on your system.
• The System/38™ library sometimes provides a command with function that is equivalent to the commands that you want to restrict. Be sure you restrict the equivalent command in the QSYS38 library.
• If you have the System/36™ environment, you may need to restrict additional programs. For example, the QY2FTML program provides System/36™ file transfer.

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 Authorization List 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.

Authority means the type of access allowed to an object. Different operations require different types of authority. Note: In some environments, the authority associated with an object is called the object’s mode of access. Authority to an object is divided into three categories:

1. Object Authority defines what operations can be performed on the object as a whole.
2. Data Authority defines what operations can be performed on the contents of the object.
3. Field Authority defines what operations can be performed on the data fields.

The following table describes the types of authority available and lists some examples of how the authorities are used. In most cases, accessing an object requires a combination of object, data, field authorities. Appendix D provides information about the authority that is required to perform a specific function.

You can define resource security for individual objects on the system. You can also define security for groups of objects using either library security or an authorization list:

• 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 (*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.

  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. See Library Lists for more information.
• Field Authorities:

  Field authorities are now supported for database files. Authorities supported are Reference and Update. You can only administer these authorities through the SQL statements, GRANT and REVOKE. You can display these authorities through the Display Object Authority (DSPOBJAUT) and the Edit Object Authority (EDTOBJAUT) commands. You can only display the field authorities with the EDTOBJAUT command; you cannot edit them.

  Changes for field authorities include the following:

  • The Print Private Authority (PRTPVTAUT) command has a new field that indicates when a file has field authorities.
  • The Display Object Authority (DSPOBJAUT) command now has a new Authority Type parameter to allow display of object authorities, field authorities, or all authorities. If the object type is not *FILE, you can display only object authorities.
  • Information provided by List Users Authorized to Object (QSYLUSRA) API now indicates if a file has field authorities.
  • The Grant User Authority (GRTUSRAUT) command will not grant a user’s field authorities.
  • When a grant with reference object is performed using the GRTOBJAUT command and both objects (the one being granted to and the referenced one) are database files, all field authorities will be granted where the field names match.
  • If a user’s authority to a database file is removed, any field authorities for the user are also removed.
• Security and the System/38™ Environment:

  The System/38 Environment and CL programs of type CLP38 represent a potential security exposure. When a non-library qualified command is entered from the System/38 Command Entry screen, or invoked by any CLP38 CL program, library QUSER38 (if it exists) is the first library searched for that command. Library QSYS38 is the second library searched. A programmer or other knowledgeable user could place another CL command in either of these libraries and cause that command to be used instead of one from a library in the library list.

  Library QUSER38 is not shipped with the operating system. However, it can be created by anyone with enough authority to create a library. See the System/38 Environment Programming manual for more information about the System/38 Environment.

  Recommendation for System/38 Environment: Use these measures to protect your system for the System/38 Environment and CL programs of type CLP38:

  • Check the public authority of the QSYS38 library and if it is *ALL or *CHANGE then change it to *USE.
  • Check the public authority of the QUSER38 library and if it is *ALL or *CHANGE then change it to *USE.
  • If the QUSER38 and QSYS38 do not exist then create them and set them to public *USE authority. This will prevent anyone else from creating it at a later time and giving themselves or the public too much authority to it.
• Directory Security:

  When accessing an object in a directory, you must have authority to all the directories in the path containing the object. You must also have the necessary authority to the object to perform the operation you requested.

  You may want to use directory security in the same way that you use library security. Limit access to directories and use public authority to the objects within the directory. Limiting the number of private authorities defined for objects improves the performance of the authority checking process.

• Authorization List Security:

  You can group objects with similar security requirements using an authorization list. An authorization list, conceptually, contains a list of users and the authority that the users have to the objects secured by the list. Each user can have a different authority to the set of objects the list secures. When you give a user authority to the authorization list, the operating system actually grants a private authority for that user to the authorization list.

  You can also use an authorization list to define public authority for the objects on the list. If the public authority for an object is set to *AUTL, the object gets its public authority from its authorization list.

  The authorization list object is used as a management tool by the system. It actually contains a list of all objects which are secured by the authorization list. This information is used to build displays for viewing or editing the authorization list objects.

  You cannot use an authorization list to secure a user profile or another authorization list. Only one authorization list can be specified for an object.

  Only the owner of the object, a user with all object (*ALLOBJ) special authority, or a user with all (*ALL) authority to the object, can add or remove the authorization list for an object. Objects in the system library (QSYS) can be secured with an authorization list. However, the name of the authorization list that secures an object is stored with the object.

  In some cases, when you install a new release of the operating system, all the objects in the QSYS library are replaced. The association between the objects and your authorization list would be lost. See the topic Planning Authorization Lists for examples of how to use authorization lists.

  Authorization List Management: You can grant a special operational authority called Authorization List Management (*AUTLMGT) for authorization lists. Users with *AUTLMGT authority are allowed to add and remove the users’ authority to the authorization list and change the authorities for those users. *AUTLMGT authority, by itself, does not give authority to secure new objects with the list or to remove objects from the list.

  A user with *AUTLMGT authority can give only the same or less authority to others. For example, assume USERA has *CHANGE and *AUTLMGT authority to authorization list CPLIST1. USERA can add USERB to CPLIST1 and give USERB *CHANGE authority or less. USERA cannot give USERB *ALL authority to CPLIST1, because USERA does not have *ALL authority.

  A user with *AUTLMGT authority can remove the authority for a user if the *AUTLMGT user has equal or greater authority to the list than the user profile name being removed. If USERC has *ALL authority to CPLIST1, then USERA cannot remove USERC from the list, because USERA has only *CHANGE and *AUTLMGT.

  Using Authorization Lists to Secure IBM-Supplied Objects: You may choose to use an authorization list to secure IBM-supplied objects. For example, you may want to restrict the use of a group of commands to a few users. Objects in IBM-supplied libraries, other than the QUSRSYS and QGPL libraries, are replaced whenever you install a new release of the operating system. Therefore, the link between objects in IBM-supplied libraries and authorization lists is lost. Also, if an authorization list secures an object in QSYS and a complete system restore is required, the link between the objects in QSYS and the authorization list is lost. After you install a new release or restore your system, use the EDTOBJAUT or GRTOBJAUT command to re-establish the link between the IBM-supplied object and the authorization list.

  The Implementation Guide for AS/400^® Security and Auditing redbook contains sample programs, such as ALLAUTL and FIXAUTL, that can be used to attach authorization lists to the objects after the authorization lists are restored.

For example, assume library CUSTLIB has a CRTAUT value of *USE. Both of the commands below create a data area called DTA1 with public authority *USE:

• Specifying the AUT parameter: CRTDTAARA DTAARA(CUSTLIB/DTA1) + TYPE(*CHAR) AUT(*LIBCRTAUT)
• Allowing the AUT parameter to default. *LIBCRTAUT is the default: CRTDTAARA DTAARA(CUSTLIB/DTA1) + TYPE(*CHAR)

The default CRTAUT value for a library is *SYSVAL. Any new objects created in the library using AUT(*LIBCRTAUT) have public authority set to the value of the QCRTAUT system value. The QCRTAUT system value is shipped as *CHANGE. For example, assume the ITEMLIB library has a CRTAUT value of *SYSVAL. This command creates the DTA2 data area with public authority of change: CRTDTAARA DTAARA(ITEMLIB/DTA2) + TYPE(*CHAR) AUT(*LIBCRTAUT) Create Authority (CRTAUT) Risks: If your applications use default authority for new objects created during application processing, you should control who has authority to change the library descriptions. Changing the CRTAUT authority for an application library could allow unauthorized access to new objects created in the library.

The following applies to adopted authority:

• Adopted authority is added to any other authority found for the user.
• Adopted authority is checked only if the authority that the user, the user’s group, or the public has to an object is not adequate for the requested operation.
• The special authorities (such as *ALLOBJ) in the owner’s profile are used.
• If the owner profile is a member of a group profile, the group’s authority is not used for adopted authority.
• Public authority is not used for adopted authority. For example, USER1 runs the program LSTCUST, which requires *USE authority to the CUSTMST file:
  • Public authority to the CUSTMST file is *USE.
  • USER1’s authority is *EXCLUDE.
  • USER2 owns the LSTCUST program, which adopts owner authority.
  • USER2 does not own the CUSTMST file and has no private authority to it.
  • Although public authority is sufficient to give USER2 access to the CUSTMST file, USER1 does not get access. Owner authority, primary group authority, and private authority are used for adopted authority.
  • Only the authority is adopted. No other user profile attributes are adopted. For example, the limited capabilities attributes are not adopted.
• Adopted authority is active as long as the program using adopted authority remains in the program stack. For example, assume PGMA uses adopted authority:
  • If PGMA starts PGMB using the CALL command, these are the program stacks before and after the CALL command:
    Adopted Authority and the CALL Command

    Program stack before CALL command	Program stack after CALL command
    QCMD . . . PGMA	QCMD . . . PGMA PGMB

    Because PGMA remains in the program stack after PGMB is called, PGMB uses the adopted authority of PGMA. (The use adopted authority (USEADPAUT) parameter can override this.
  • If PGMA starts PGMB using the Transfer Control (TFRCTL) command, the program stacks look like this:
    Adopted Authority and the TFRCTL Command

    Program stack before TFRCTL command	Program stack after TFRCTL command
    QCMD . . . PGMA	QCMD . . . PGMB

    PGMB does not use the adopted authority of PGMA, because PGMA is no longer in the program stack.
• If the program running under adopted authority is interrupted, the use of adopted authority is suspended. The following functions do not use adopted authority:
  • System request
  • Attention key (If a Transfer to Group Job (TFRGRPJOB) command is running, adopted authority is not passed to the group job)
  • Break-message-handling program
  • Debug functions
  Note: Adopted authority is immediately interrupted by the attention key or a group job request. The user must have authority to the attention-key-handling program or the group job initial program, or the attempt fails.

For example, USERA runs the program PGM1, which adopts the authority of USERB. PGM1 uses the SETATNPGM command and specifies PGM2. USERB has *USE authority to PGM2. USERA has *EXCLUDE authority to PGM2. The SETATNPGM function is successful because it is run using adopted authority. USERA receives an authority error when attempting to use the attention key because USERB’s authority is no longer active.

• If a program that uses adopted authority submits a job, that submitted job does not have the adopted authority of the submitting program.
• When a trigger program or exit point program is called, adopted authority from previous programs in the call stack will not be used as a source of authority for the trigger program or exit point program.
• The program adopt function is not used when you use the Change Job (CHGJOB) command to change the output queue for a job. The user profile making the change must have authority to the new output queue.
• Any objects created, including spooled files, are owned by the user of the program or by the user’s group profile, not by the owner of the program.
• Adopted authority can be specified on either the command that creates the program (CRTxxxPGM) or on the Change Program (CHGPGM) command.
• If a program is created using REPLACE(*YES) on the CRTxxxPGM command, the new copy of the program has the same USRPRF, USEADPAUT, and AUT values as the replaced program. The USRPRF and AUT parameters specified on the CRTxxxPGM parameter are ignored.
• Only the owner of the program can specify REPLACE(*YES) on the CRTxxxPGM command when USRPRF(*OWNER) is specified on the original program.
• Only a user who owns the program or has *ALLOBJ and *SECADM special authorities can change the value of the USRPRF parameter.
• You must be signed on as a user with *ALLOBJ and *SECADM special authorities to transfer ownership of an object that adopts authority.
• If someone other than the program’s owner or a user with *ALLOBJ and *SECADM special authorities restores a program that adopts authority, all private and public authorities to the program are revoked to prevent a possible security exposure.

The Display Program (DSPPGM) and Display Service Program (DSPSRVPGM) commands show whether a program adopts authority (User profile prompt) and whether it uses adopted authority from previous programs in the program stack (Use adopted authority prompt). The Display Program Adopt (DSPPGMADP) command shows all the objects that adopt the authority of a specific user profile. The Print Adopting Objects (PRTADPOBJ) command provides a report with more information about objects that adopt authority. This command also provides an option to print a report for objects that changed since the last time the command was run.

Adopted Authority Risks and Recommendations: Allowing a program to run using adopted authority is an intentional release of control. You permit the user to have authority to objects, and possibly special authority, which the user would not normally have. Adopted authority provides an important tool for meeting diverse authority requirements, but it should be used with care:

• Adopt the minimum authority required to meet the application requirements. Adopting the authority of an application owner is preferable to adopting the authority of QSECOFR or a user with *ALLOBJ special authority.
• Carefully monitor the function provided by programs that adopt authority. Make sure these programs do not provide a means for the user to access objects outside the control of the program, such as command entry capability.
• Programs that adopt authority and call other programs must perform a library qualified call. Do not use the library list (*LIBL) on the call.
• Control which users are permitted to call programs that adopt authority. Use menu interfaces and library security to prevent these programs from being called without sufficient control.

The use adopted authority (USEADPAUT) parameter of a program determines whether the system uses the adopted authority of previous programs in the stack when checking authority for objects. When you create a program, the default is to use adopted authority from previous programs in the stack. If you do not want the program to use adopted authority, you can change the program with the Change Program (CHGPGM) command or Change Service Program (CHGSRVPGM) command to set the USEADPAUT parameter to *NO. If a program is created using REPLACE(*YES) on the CRTxxxPGM command, the new copy of the program has the same USRPRF, USEADPAUT, and AUT values as the replaced program.

An authority holder is a tool for keeping the authorities for a program-described database file that does not currently exist on the system. Its primary use is for System/36 environment applications, which often delete program-described files and create them again. An authority holder can be created for a file that already exists or for a file that does not exist, using the Create Authority Holder (CRTAUTHLR) command. The following applies to authority holders:

• Authority holders can only secure files in the system auxiliary storage pool (ASP) or a basic user ASP. They cannot secure files in an independent ASP.
• The authority holder is associated with a specific file and library. It has the same name as the file.
• Authority holders can be used only for program-described database files and logical files created in the S/36 environment.
• Once the authority holder is created, you add private authorities for it like a file. Use the commands to grant, revoke, and display object authorities, and specify object type *FILE. On the object authority displays, the authority holder is indistinguishable from the file itself. The displays do not indicate whether the file exists nor do they show that the file has an authority holder.
• If a file is associated with an authority holder, the authorities defined for the authority holder are used during authority checking. Any private authorities defined for the file are ignored.
• Use the Display Authority Holder (DSPAUTHLR) command to display or print all the authority holders on the system. You can also use it to create an output file (Outfile) for processing.
• If you create an authority holder for a file that exists:
  • The user creating the authority holder must have *ALL authority to the file.
  • The owner of the file becomes the owner of the authority holder regardless of the user creating the authority holder.
  • The public authority for the authority holder comes from the file. The public authority (AUT) parameter on the CRTAUTHLR command is ignored.
  • The existing file’s authority is copied to the authority holder.
• If you create a file and an authority holder for that file already exists:
  • The user creating the file must have *ALL authority to the authority holder.
  • The owner of the authority holder becomes the owner of the file regardless of the user creating the file.
  • The public authority for the file comes from the authority holder. The public authority (AUT) parameter on the CRTPF or CRTLF command is ignored.
  • The authority holder is linked to the file. The authority specified for the authority holder is used to secure the file.
• If an authority holder is deleted, the authority information is transferred to the file itself.
• If a file is renamed and the new file name matches an existing authority holder, the authority and ownership of the file are changed to match the authority holder. The user renaming the file needs *ALL authority to the authority holder.
• If a file is moved to a different library and an authority holder exists for that file name and the target library, the authority and ownership of the file are changed to match the authority holder. The user moving the file must have *ALL authority to the authority holder.
• Ownership of the authority holder and the file always match. If you change the ownership of the file, ownership of the authority holder also changes.
• When a file is restored, if an authority holder exists for that file name and the library to which it is being restored, it is linked to the authority holder.
• Authority holders cannot be created for files in these libraries: QSYS, QRCL, QRECOVERY, QSPL, QTEMP, and QSPL0002 – QSPL0032.

Authority Holders and System/36 Migration: The System/36 Migration Aid creates an authority holder for every file that is migrated. It also creates an authority holder for entries in the System/36 resource security file if no corresponding file exists on the System/36. You need authority holders only for files that are deleted and re-created by your applications. Use the Delete Authority Holder (DLTAUTHLR) command to delete any authority holders that you do not need.

Four displays show object authorities:

• Display Object Authority display
• Edit Object Authority display
• Display Authority display
• Work with Authority display

Several reports are available to help you monitor your security implementation. For example, you can monitor objects with *PUBLIC authority other than *EXCLUDE and objects with private authorities with the following commands:

• Print Public Authority (PRTPUBAUT)
• Print Private Authority (PRTPVTAUT)

Two parameters on the Create Library (CRTLIB) command affect authority:

• Authority (AUT): The AUT parameter can be used to specify either of the following:
  • The public authority for the library
  • The authorization list that secures the library.
  The AUT parameter applies to the library itself, not to the objects in the library. If you specify an authorization list name, the public authority for the library is set to *AUTL. If you do not specify AUT when you create a library, *LIBCRTAUT is the default. The system uses the CRTAUT value from the QSYS library, which is shipped as *SYSVAL.
• Create Authority (CRTAUT): The CRTAUT parameter determines the default authority for any new objects that are created in the library. CRTAUT can be set to one of the system-defined authorities (*ALL, *CHANGE, *USE, or *EXCLUDE), to *SYSVAL (the QCRTAUT system value), or to the name of an authorization list.
  Note: You can change the CRTAUT value for a library using the Change Library (CHGLIB) command.

To change the authority for an object you must have one of the following:

• *ALLOBJ authority or membership in a group profile that has *ALLOBJ special authority.
  Note: The group’s authority is not used if you have private authority to the object.
• Ownership of the object. If a group profile owns the object, any member of the group can act as the object owner, unless the member has been given specific authority that does not meet the requirements for changing the object’s authority.
• *OBJMGT authority to the object and any authorities being granted or revoked (except *EXCLUDE). Any user who is allowed to work with the object’s authority can grant or revoke *EXCLUDE authority.

The easiest way to change authority for an individual object is with the Edit Object Authority display. This display can be called directly by using the Edit Object Authority (EDTOBJAUT) command or selected as an option from the Work with Objects by Owner (WRKOBJOWN) or WRKOBJ (Work with Objects) display. You can also use these commands to change object authority:

• Change Authority (CHGAUT)
• Work with Authority (WRKAUT)
• Grant Object Authority (GRTOBJAUT)
• Revoke Object Authority (RVKOBJAUT)

To specify the generic authority subsets, such as Read/Write (*RX) or Write/Execute (*WX), you must use the CHGAUT or WRKAUT commands.

The Object Authority column on the Edit Object Authority display allows you to specify any of the system-defined sets of authorities (*ALL, *CHANGE, *USE, *EXCLUDE). If you want to specify authority that is not a system-defined set, use F11 (Display detail). To give authority to additional users, press F6 (Add new users) from the Edit Object Authority display. You see the Add New Users display, which allows you to define authority for multiple users.

You can remove a user’s authority using the Edit Object Authority display. Type blanks in the Object Authority field for the user and press the Enter key. The user is removed from the display. You can also use the Revoke Object Authority (RVKOBJAUT) command. Either revoke the specific authority the user has or revoke *ALL authority for the user.

The Edit Object Authority display allows you to interactively work with the authority for one object at a time. The Grant Object Authority (GRTOBJAUT) command allows you to make authority changes to more than one object at a time. You can use the GRTOBJAUT authority command interactively or in batch. You can also call it from a program. Following are examples of using the GRTOBJAUT command, showing the prompt display. When the command runs, you receive a message for each object indicating whether the change was made. Authority changes require an exclusive lock on the object and cannot be made when an object is in use. Print your job log for a record of changes attempted and made. To give all the objects in the TESTLIB library a public authority of *USE:

Grant Object Authority (GRTOBJAUT)

Type choices, press Enter. 
Object . . . . . . . . . . . . . *ALL 
Library . . . . . . . . . . . . . TESTLIB 
Object type . . . . . . . . . . *ALL
ASP device . . . . . . . . . . . * 
Users . . . . . . . . . . . . . *PUBLIC 
+ for more values 
Authority . . . . . . . . . . . *USE

This example for the GRTOBJAUT command gives the authority you specify, but it does not remove any authority that is greater than you specified. If some objects in the TESTLIB library have public authority *CHANGE, the command just shown would not reduce their public authority to *USE. To make sure that all objects in TESTLIB have a public authority of *USE, use the GRTOBJAUT command with the REPLACE parameter: GRTOBJAUT OBJ(TESTLIB/*ALL) OBJTYPE(*ALL) + USER(*PUBLIC) REPLACE(*YES)

To change ownership of an object, use one of the following:

• The Change Object Owner (CHGOBJOWN) command
• The Work with Objects by Owner (WRKOBJOWN) command
• The Change Owner (CHGOWN) command

The Work with Objects by Owner display shows all the objects owned by a profile. You can assign individual objects to a new owner. You can also change ownership for more than one object at a time by using the NEWOWN (new owner) parameter at the bottom of the display. When you change ownership using either method, you can choose to remove the previous owner’s authority to the object. The default for the CUROWNAUT (current owner authority) parameter is *REVOKE. To transfer ownership of an object, you must have:

• Object existence authority for the object
• *ALL authority or ownership, if the object is an authorization list
• Add authority for the new owner’s user profile
• Delete authority for the present owner’s user profile

You cannot delete a user profile that owns objects. The Work with Objects by Owner display includes integrated file system objects. For these objects, the Object column on the display shows the first 18 characters of the path name. If the path name is longer than 18 characters, a greater than symbol (>) appears at the end of the path name. To see the absolute path name, place your cursor anywhere on the path name and press the F22 key.

Authority means how someone is authorized to use an object. For example, you may have the authority to view information or to change information on the system. The system provides several different authority types. IBM^® groups these authority types into categories, called system-defined authorities, which meet the needs of most people. The table below lists the categories and tells how they apply to securing files and programs. To design simple resource security, try to plan security for entire libraries. To do this, you need to understand how the system-defined authorities apply to libraries, which the table below shows: You also need to understand how library and object authority work together. The table below gives examples of authorities that are required for both an object and the library: Directory authority is similar to library authority. You need authority to all the directories in the path name for an object in order to access the object.