Brief: Because security is highly integrated with OS/400, it is not surprising that V3R1 includes many changes to the security implementation. This article explores the security features that AS/400 administrators can put to work immediately and examines some additional functions designed to improve compatibility with other platforms.

An underlying theme for V3R1 of OS/400 is compatibility with open systems standards. Many of the security enhancements in the new release are consistent with this theme; however, even if you have no interest in open systems, there are substantial security features that you can apply right away.

This article examines the security enhancements primarily from the perspective of traditional AS/400 shops. Among the most important enhancements are changes to the group profile implementation, already one of the most useful features of OS/400 security.

You'll also find substantial new function with the addition of data authorities for logical files and object authorities that separate database management from security management. These refinements to object authorities give you better control over access to the AS/400 database.

System values that control password definitions are significantly improved to provide better compatibility with other systems-a fringe benefit for all AS/400 users. Finally, the changes to communications security improve the integrity of distributed systems, including, but not limited to, PCs, AS/400s, and UNIX systems.

Extensions for Group Profiles

V3R1 extends existing group profile support by allowing a user to be a member of up to 16 group profiles. An individual user profile gets both special and object authorities from the group profiles. Two different rules are used for the accumulation of authority.

1. Special authority accumulates from the user profile and all group profiles.

2. Object authority of the individual user profile overrides the group profile.

If there is no individual authority, the authority of all group profiles is accumulated.

1 illustrates how the user accumulates the object authority from the group profile (GRPPRF) and supplemental group profiles (SUPGRPPRF). Like the current AS/400 implementation, specific authority granted to the user profile overrides any object authority from group profiles. The first entry in 1 illustrates this principle: although supplemental group profile 2 has *ALL authority to the object, the user only has *CHANGE authority. If the individual user profile has no authority to an object, the user gets the combined access of the group profiles. For this purpose, you can consider GRPPRF and the 15 possible entries in SUPGRPPRF as group profiles 1-16. The user accumulates the maximum possible authority as shown in the second entry in 1.

Figure 1 illustrates how the user accumulates the object authority from the group profile (GRPPRF) and supplemental group profiles (SUPGRPPRF). Like the current AS/400 implementation, specific authority granted to the user profile overrides any object authority from group profiles. The first entry in Figure 1 illustrates this principle: although supplemental group profile 2 has *ALL authority to the object, the user only has *CHANGE authority. If the individual user profile has no authority to an object, the user gets the combined access of the group profiles. For this purpose, you can consider GRPPRF and the 15 possible entries in SUPGRPPRF as group profiles 1-16. The user accumulates the maximum possible authority as shown in the second entry in Figure 1.

2 shows the order of the object authority search for a user with multiple group profiles. If the user profile has no private authority to the object, the search starts with GRPRPF and continues through each of the supplemental group profiles until adequate authorization is found.

Figure 2 shows the order of the object authority search for a user with multiple group profiles. If the user profile has no private authority to the object, the search starts with GRPRPF and continues through each of the supplemental group profiles until adequate authorization is found.

You should use multiple group profiles with discretion because they can affect performance. Searching additional profiles increases the number of authority lookup operations. To minimize the impact on performance.

1. Minimize the number of supplemental group profiles.

2. Within each user profile, list the supplemental group profiles in order from most authority to least authority. This increases the possibility that object access will be authorized with the minimum number of checks.

The only difference between a user profile designated as GRPPRF and the additional user profiles designated in SUPGRPPRF is how object ownership is transferred from the user profile to the group profile. The AS/400 automatically transfers ownership of objects created by a group member to the group profile if OWNER(*GRPPRF) is specified for the user profile definition; ownership is not transferred to any supplemental group profiles. The reason for this constraint should be obvious-an object cannot have multiple owners.

Primary Group Profile

Another new feature in V3R1 lets you designate primary group profile (PGP) authorities for objects. This improves performance because the primary group profile authority is stored in the object header along with *PUBLIC authority and the owner's authority to the object. (For an explanation of the relationship between performance and security information stored in the object header see "Security Design for Performance," MC, August 1993.) IBM uses the letters PGP to mean primary group profile authority, but I think of PGP as pretty good performance.

PGP is part of IBM's ongoing effort to position the AS/400 as an open system. UNIX applications define access permissions (authority) for the owner, group, and world. Adding PGP authority to the object header optimizes the performance of UNIX applications. 3 shows mapping of UNIX permissions to AS/400 authorities.

PGP is part of IBM's ongoing effort to position the AS/400 as an open system. UNIX applications define access permissions (authority) for the owner, group, and world. Adding PGP authority to the object header optimizes the performance of UNIX applications. Figure 3 shows mapping of UNIX permissions to AS/400 authorities.

Existing AS/400 applications can establish PGP authority in two ways.

o Use V3R1's new command, Change Object Primary Group (CHGOBJPGP), to set the PGP authority for an object. o Specify *PGP for the GRPAUTTYP attribute of a user profile to store PGP authority in the object header of all new objects that are created by a user profile and that are not owned by the group profile. There is no reason to use this attribute if the group profile owns the objects created by the user profile. In this case, the owner's authority to an object is already stored in the object header.

Since PGP authority improves performance, I change all of the user profiles to use GRPAUTTYP(*PGP) as shown in 4. The IBM default is GRPAUTTYP(*PRIVATE) which is compatible with previous releases but not the best for performance. I recommend changing the default for the Create User Profile (CRTUSRPRF) command to use GRPAUTTYP(*PGP) using the following command:

Since PGP authority improves performance, I change all of the user profiles to use GRPAUTTYP(*PGP) as shown in Figure 4. The IBM default is GRPAUTTYP(*PRIVATE) which is compatible with previous releases but not the best for performance. I recommend changing the default for the Create User Profile (CRTUSRPRF) command to use GRPAUTTYP(*PGP) using the following command:

 
 CHGCMDDFT CMD(QSYS/CRTUSRPRF) + 
   NEWDFT('GRPAUTTYP(*PGP)') 

When a user with a group profile creates an object, the user can transfer ownership to the group profile. I recommend this option because it simplifies the deletion of individual profiles. However, if the user profile specifies OWNER(*USRPRF), the individual user profile retains ownership of the object. When the creator retains ownership of the new object, you can give specific authority to the group profile by specifying the group authority (GRPAUT) attribute in the owner's user profile.

Prior to V3R1, GRPAUT was a private authority that could not be determined from the object header. With V3R1, if the user profile specifies OWNER(*GRPPRF) and GRPAUTTYP (*PGP), the system selects *PGP for new objects. The interaction among the parameters is shown in the following examples:

 
 o User profile USER1 has the following parameters: 
  GRPPRF(MC_EDITORIAL)   GRPAUT(*CHANGE) 
 GRPAUTTYP(*PGP) OWNER(*USRPRF) 

When USER1 creates an object, the object will have a *PGP of MC_EDITORIAL and PGP authority of *CHANGE. The owner of the object will be user profile USER1.

o User profile USER2 has the following parameters:

 
  GRPPRF(MC_PROGRAM) 
 GRPAUT(*USE)    GRPAUTTYP(*PRIVATE) OWNER(*USRPRF) 

When USER2 creates an object, the group profile MC_PROGRAM will have a private authority of *USE. The owner of the object will be user profile USER2.

o User profile USER3 has the following parameters:

 
  GRPPRF(MC_STAFF) 
 GRPAUT(*USE) GRPAUTTYP(*PGP) OWNER(*GRPPRF) 

When USER3 creates an object, the group profile MC_STAFF will be the owner (object owner's authority is stored in the object header) and will have *ALL authority. When OWNER(*GRPPRF) is specified, the GRPAUT and GRPAUTTYP information is ignored.

If group profiles have private authority to objects, you can improve performance by converting the private authority to PGP authority. The program in 5 converts any private authority for a user profile into PGP authority.

If group profiles have private authority to objects, you can improve performance by converting the private authority to PGP authority. The program in Figure 5 converts any private authority for a user profile into PGP authority.

Data Authorities for Logical Files

The V3R1 database has many new features. (See "Referential Integrity & Triggers in DB2/400," MC, November 1994 for details of the new database features.) The new database functions are reflected in new data authorities for logical files and two new object authorities.

Data authorities for logical files give you better control over access to specific data within a file. Prior to V3R1, the authority to read, add, update, and delete records for logical files was determined by authority to the physical file. You were forced to give the users as much authority to the physical file as they needed for any of its logical files.

To illustrate how the new logical file authorities work in 6, I have defined a physical file with three fields: NAME, ADDRESS, and SALARY. USER1 does not have *OBJOPER authority to the physical file, so he cannot open the physical file and manipulate the data directly. As in previous releases, authority to the physical file limits the user's ability to add or delete records.

To illustrate how the new logical file authorities work in Figure 6, I have defined a physical file with three fields: NAME, ADDRESS, and SALARY. USER1 does not have *OBJOPER authority to the physical file, so he cannot open the physical file and manipulate the data directly. As in previous releases, authority to the physical file limits the user's ability to add or delete records.

I have defined two logical files to give USER1 the ability to modify or view specific fields within the physical file. Logical File 1 contains the NAME and ADDRESS fields from the physical file. USER1 has *USE authority to this file giving him read-only access to the name and address data. Logical File 2 includes only the NAME field. I've given USER1 *CHANGE authority to Logical File 2, allowing him to read and modify the NAME field. As 6 illustrates, USER1 has only *READ and *UPD authority to the physical file preventing USER1 from adding or deleting any records.

I have defined two logical files to give USER1 the ability to modify or view specific fields within the physical file. Logical File 1 contains the NAME and ADDRESS fields from the physical file. USER1 has *USE authority to this file giving him read-only access to the name and address data. Logical File 2 includes only the NAME field. I've given USER1 *CHANGE authority to Logical File 2, allowing him to read and modify the NAME field. As Figure 6 illustrates, USER1 has only *READ and *UPD authority to the physical file preventing USER1 from adding or deleting any records.

V3R1 converts logical files on first open. The conversion grants all data authorities to the logical files because there were no data authorities assigned to logical files prior to V3R1. The data authorities of the physical file limit the operations a user can perform, so your existing security controls are not affected by this change. When V3R1 is installed, every logical file will be converted to replace the existing *OBJOPR authority with *OBJOPR, *READ, *UPD, *ADD, *DLT, and *EXECUTE authority. Once a logical file is converted, you can change the authority of the logical file to meet your requirements. This new feature expands your control of data on a field-by-field basis.

Object Authorities for New Database Functions

The new capabilities of DB2/400 raise security concerns that I'll cover in more detail in an upcoming article. In the specific arena of database authorities, two of the new functions-referential integrity and triggers-can be assigned only by a user who has the appropriate authority to the affected physical file. The new object authorities that apply to database physical files are described in 7.

The new capabilities of DB2/400 raise security concerns that I'll cover in more detail in an upcoming article. In the specific arena of database authorities, two of the new functions-referential integrity and triggers-can be assigned only by a user who has the appropriate authority to the affected physical file. The new object authorities that apply to database physical files are described in Figure 7.

Referential integrity constraints define conditions that must be preserved in relationships between physical files. For example, referential integrity prevents the addition of an order record if there is no associated customer master record. A user must have object reference (*OBJREF ) authority to the physical file to define or remove referential integrity constraints.

Triggers on a physical file cause the execution of a program when a specified condition is detected. For example, a trigger program might notify the Accounts Receivable department when the balance of an account exceeds the credit limit. You must have object alter (*OBJALTER) authority to the physical file to define or remove triggers.

Prior to V3R1, operations such as adding, clearing, and reorganizing members required *OBJMGT authority. However, *OBJMGT authority allows the user to authorize other users to the file as well. The addition of *OBJALTER authority in V3R1 allows users to perform member-level operations (add, clear, initialize, and reorganize) without giving the user *OBJMGT authority. You can use *OBJALTER authority rather than *OBJMGT authority to allow database management operations while preventing the user from changing the authority to the file. 8 shows the operations allowed by the object authorities. Users with *OBJMGT authority will have authority for security management and for database file management.

Prior to V3R1, operations such as adding, clearing, and reorganizing members required *OBJMGT authority. However, *OBJMGT authority allows the user to authorize other users to the file as well. The addition of *OBJALTER authority in V3R1 allows users to perform member-level operations (add, clear, initialize, and reorganize) without giving the user *OBJMGT authority. You can use *OBJALTER authority rather than *OBJMGT authority to allow database management operations while preventing the user from changing the authority to the file. Figure 8 shows the operations allowed by the object authorities. Users with *OBJMGT authority will have authority for security management and for database file management.

System Values

V3R1 expands the options of two password system values giving installations more flexibility in defining the rules for repetition of passwords and repetition of characters in passwords.

Prior to V3R1, the system value QPWDRQDDIF allowed only two options: setting QPWDRQDDIF to zero to allow users to repeat any password or setting this system value to one to prevent users from repeating any of their past 32 passwords. V3R1 allows more flexibility in the number of passwords checked for duplicates. I recommend setting QPWDRQDDIF to a value between one and five. These values require a minimum of 10 unique passwords.

The QPWDLMTREP system value controls repeating characters in a password. This system value prevents trivial passwords, such as YYYYY. V3R1 adds an option that allows repeated nonadjacent characters making passwords such as TOPDOG valid. (The option would reject BETTY as a password because of duplicate adjacent characters.) I recommend setting QPWDLMTREP to two to take advantage of this new option. This prevents trivial passwords while allowing users to select a password without difficulty.

A new system value, QALWOBJRST, controls whether security-sensitive objects may be restored. This system value can prevent anyone from restoring a system-state object or an object that adopts authority. Valid values for the QALWOBJ-RST system value are shown in 9.

A new system value, QALWOBJRST, controls whether security-sensitive objects may be restored. This system value can prevent anyone from restoring a system-state object or an object that adopts authority. Valid values for the QALWOBJ-RST system value are shown in Figure 9.

When V3R1 is installed, the QALWOBJ-RST system value is set to *ALL. This is equivalent to the existing restore capability. Installations requiring improved security should set this system value to *ALWPGMADP, which allows programs that adopt authority to be restored. However, the system value must be set to *ALL before performing some system activities, such as

o Applying PTFs. o Recovering your system.

This system value is intended for installations that have rigorous security controls and want to limit restore operations. Most installations should leave the default *ALL for QALWOBJRST.

Communications Security

There are four changes in V3R1 security related to communications: a new special authority, special passwords for program start requests, improvements to Client Access/400 (PC Support), and a new registration facility for exit programs.

V3R1 defines a new special authority, *IOSYSCFG, that allows a user to con- figure parts of the system. A user must have *IOSYSCFG special authority to create or modify the new communication protocol interfaces: sockets and TCP/IP. Unfortunately, *IOSYSCFG omits many of the existing configuration commands. Although IBM has indicated that it may add this support in the future, I feel that it should have been included in V3R1.

Another change to communications security involves security of sign-on information. Prior to V3R1, when the AS/400 issued a request to start a program on another system, the user profile name and password were transmitted in clear text. It was possible to monitor the communications line and observe the password for a user profile.

In V3R1, the AS/400 sends a password token rather than the password itself if the receiving system supports password substitution. Consequently, monitoring the communication line does not disclose the password of the user. In V3R1, the AS/400 accepts password tokens on program start requests. 10 illustrates the difference in the program start requests.

In V3R1, the AS/400 sends a password token rather than the password itself if the receiving system supports password substitution. Consequently, monitoring the communication line does not disclose the password of the user. In V3R1, the AS/400 accepts password tokens on program start requests. Figure 10 illustrates the difference in the program start requests.

Although tokenized passwords are an improvement, this solution has a fairly limited scope. Tokenized passwords can be passed only from an intelligent workstation such as a PC to an AS/400, or between systems that each support password substitution. For a PC-to-AS/400 connection to take advantage of this security feature, you must bypass the sign-on screen. Any password entered on the AS/400 sign-on screen from either a nonprogrammable terminal or a PC is transmitted as clear text. Although this is not a major concern in a local environment, it becomes an important issue if sign-on information is transmitted over the telephone network.

To avoid disclosure of passwords, allow Client Access/400 (PC Support/400) sign-on and Display Station Pass-Through (DSPT) to bypass the sign-on screen. Even with these precautions, both user IDs and passwords are transmitted in the clear if the target system is not an AS/400.

Client Access/400 contains another important security change. Prior to V3R1, if the user profile used to start the router had an expired password, the user was not notified. Client Access prompts the user to change the user profile password when the password expires.

The final communications security enhancement for V3R1 concerns the use of exit programs. Many installations use exit programs to control the operations that can be performed from PC support. The V3R1 exit program capabilities of Client Access have been extended. The network attribute that specifies how Client Access requests are handled, PCSACC, has a new option, *REGFAC, which indicates that the system's registration facility determines which exit program to run. With the registration facility, you can designate an exit program for specific Client Access functions. The exit programs are called only when the user performs the operation.

The Work with Registration Information (WRKREGINF) command allows you to designate the exit program for specific functions. The panel in 11 from the WRKREGINF command lists the available exit points. Option 8 from this screen can be used to designate an exit program for the specific function. The command is similar to the Retrieve Exit Information (QUSRTVEI) Application Programming Interface (API).

The Work with Registration Information (WRKREGINF) command allows you to designate the exit program for specific functions. The panel in Figure 11 from the WRKREGINF command lists the available exit points. Option 8 from this screen can be used to designate an exit program for the specific function. The command is similar to the Retrieve Exit Information (QUSRTVEI) Application Programming Interface (API).

Open Systems Compatibility

V3R1 has added a number of features to aid in the conversion of UNIX applications. Many network and client/server platforms require that users be identified by a unique number. Two new-user profile parameters, UID and GID, provide this support. The UID and GID are simply unique numbers used in place of the user profile name for these applications. When you install V3R1, the system generates a unique UID for each user profile on your system. Group profiles are assigned both a UID and a unique GID.

Starting with V3R1, *EXECUTE authority to an object library is required to execute a program or search a library for an object. In versions earlier than V3R1, most operations required *READ authority to the library containing an object. When you upgrade to V3R1, the system converts the authority for the objects on your system. 12 shows that *EXECUTE authority is included in the system-defined authority for *ALL, *CHANGE, and *USE. This allows most existing applications to operate without modification if they grant users *ALL, *CHANGE or *USE access. Applications that granted or checked for the individual authorities of *OBJOPR and *READ must be changed to use the new *EXECUTE authority for programs and libraries.

Starting with V3R1, *EXECUTE authority to an object library is required to execute a program or search a library for an object. In versions earlier than V3R1, most operations required *READ authority to the library containing an object. When you upgrade to V3R1, the system converts the authority for the objects on your system. Figure 12 shows that *EXECUTE authority is included in the system-defined authority for *ALL, *CHANGE, and *USE. This allows most existing applications to operate without modification if they grant users *ALL, *CHANGE or *USE access. Applications that granted or checked for the individual authorities of *OBJOPR and *READ must be changed to use the new *EXECUTE authority for programs and libraries.

The Integrated File System (IFS) provides alternative methods of storing data, including nested directory support used by many PC and UNIX applications (for more information see "V3R1 Announcement Follow-up: The Integrated File System," MC, July 1994). When you prompt one of the IFS commands, you don't enter a 10- character object and library name; you enter the object name and qualifiers in a single field. 13 shows the IFS commands for security. The corresponding native command appears on the right side of the table. You can use either command to reference AS/400 objects, but most AS/400 users will find the existing native commands more desirable. The IFS commands use the following authority terminology: R=Read, W=Write, and X=eXecute. The IFS authorities are mapped to the object authorities as shown in 14.

The Integrated File System (IFS) provides alternative methods of storing data, including nested directory support used by many PC and UNIX applications (for more information see "V3R1 Announcement Follow-up: The Integrated File System," MC, July 1994). When you prompt one of the IFS commands, you don't enter a 10- character object and library name; you enter the object name and qualifiers in a single field. Figure 13 shows the IFS commands for security. The corresponding native command appears on the right side of the table. You can use either command to reference AS/400 objects, but most AS/400 users will find the existing native commands more desirable. The IFS commands use the following authority terminology: R=Read, W=Write, and X=eXecute. The IFS authorities are mapped to the object authorities as shown in Figure 14.

A new user profile parameter, Home Directory (HOMEDIR), can be used to designate the default directory for a user in IFS.

Miscellaneous

When you install V3R1, you will notice several changes to the panels showing authority for an object. The three new object authorities and the names of group profiles require space. As a result, the V3R1 authority displays are presented on two panels. The F11 key is used to switch between the object and data authorities.

You can view authority information on a single panel if you are willing to sacrifice the column headings as shown in 15. Use the following command to change your user profile to use *EXPERT mode:

You can view authority information on a single panel if you are willing to sacrifice the column headings as shown in Figure 15. Use the following command to change your user profile to use *EXPERT mode:

 
 CHGUSRPRF USRPRF(your_profile) + 
    USROPT(*EXPERT) 

There are no changes to the procedure used to select action and object auditing in V3R1. However, more than 20 new audit events have been added to represent the new object types and expanded network security. (For more information on object auditing, see "Powerful Audit Functions Enhance V2R3 Security," MC, February 1994.)

The Check Object Integrity (CHK-OBJITG) command scans objects for alterations. Only installations with the highest security requirements will find this command of any value. An altered object is usually an indication that someone is attempting to tamper with the system. The CHKOBJITG program requires *AUDIT special authority and may take a long time to run because of the scans and calculations it performs. You should run it at a time when your system is not busy.

In prior releases, IBM shipped a number of user profiles with passwords that were the same as the user profile. These profiles pose a potential security exposure unless the passwords are changed. In V3R1, the only user profile shipped with a password is the user profile QSECOFR-all other IBM-supplied passwords are set to *NONE. This will not change the password on existing systems.

Approach Cautiously

The security features added to increase the AS/400's affinity for other platforms are valuable to existing AS/400 installations. Now that V3R1 is generally available, I recommend that established users exercise a cautious approach to the installation of V3R1. The changes in OS/400 have the potential to introduce problems. It is best not to be on the bleeding edge of this release.

Wayne O. Evans is an AS/400 security consultant and a frequent speaker on security topics. During his 27 years with IBM Corporation, he was involved with AS/400 security design issues. Prior to working on security, Wayne was the team leader and designer for the command definition and CL language on the S/38.

V3R1 Security Enhancements

Figure 1 Authority for User with Supplemental Profiles

 
 
 
                                     Supplemental   Supplemental   Effective 
  User Profile     Group Profile     Group Profile  Group Profile  Authority for 
  Authority        Authority         1 Authority    2 Authority    User 
 
  *CHANGE          *USE                             *ALL           *CHANGE 
                   *EXCLUDE          *READ          *ADD           *READ+*ADD 
                   *CHANGE                                         *CHANGE 
  *USE             *CHANGE                                         *USE 
                                     *READ                         *READ 
                                     *READ          *ADD           *READ+*ADD 
 
  V3R1 Security Enhancements
 
 Figure   2 Object Authority Search Logic
 
 
            UNABLE TO REPRODUCE GRAPHICS 
 
  V3R1 Security Enhancements
 
 Figure   3 Relationship of UNIX Authority to AS/400 Authority
 
 
            UNABLE TO REPRODUCE GRAPHICS 
 
  V3R1 Security Enhancements
 
 Figure   4 Changing User Profiles to Group Authority
 
 
  /*===============================================================*/ 
  /* To compile:                                                   */ 
  /*                                                               */ 
  /*           CRTCLPGM   PGM(XXX/CHGUSRPGP) SRCFILE(XXX/QCLSRC)   */ 
  /*                                                               */ 
  /*===============================================================*/ 
     PGM 
 
     DCLF FILE(QADSPOBJ) 
     DSPOBJD OBJ(QSYS/*ALL) OBJTYPE(*USRPRF) OUTPUT(*OUTFILE) + 
        OUTFILE(QTEMP/USRPRF) 
     OVRDBF FILE(QADSPOBJ) TOFILE(QTEMP/USRPRF) 
 
  READ: + 
     RCVF 
     MONMSG MSGID(CPF0864) EXEC(GOTO CMDLBL(EOF)) 
     CHGUSRPRF USRPRF(&ODOBNM) GRPAUTTYP(*PGP) 
     MONMSG MSGID(CPF0000) EXEC(GOTO CMDLBL(READ)) 
     GOTO CMDLBL(READ) 
 
  EOF: + 
     ENDPGM 
 
  V3R1 Security Enhancements
 
 Figure   5 Converting Private Authority to PGP Authority
 
 
  /*===============================================================*/ 
  /* To compile:                                                   */ 
  /*                                                               */ 
  /*           CRTCLPGM   PGM(XXX/CHGOBJPGM) SRCFILE(XXX/QCLSRC)   */ 
  /*                                                               */ 
  /*===============================================================*/ 
     PGM PARM(&GRPPRF) 
 
     DCL VAR(&GRPPRF)     TYPE(*CHAR) LEN(10) 
     DCL VAR(&GID)        TYPE(*DEC)  LEN(10 0) 
     DCL VAR(&AUT)        TYPE(*CHAR) LEN(150) 
     DCL VAR(&CMD)        TYPE(*CHAR) LEN(256) 
     DCLF FILE(QADSPUPA) 
 
     RTVUSRPRF USRPRF(&GRPPRF) GID(&GID) 
     IF COND(&GID = 0) THEN(SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) + 
        MSGDTA('The profile specified is not a group profile.') + 
        MSGTYPE(*ESCAPE)) 
     DSPUSRPRF USRPRF(&GRPPRF) TYPE(*OBJAUT) OUTPUT(*OUTFILE) + 
        OUTFILE(QTEMP/OBJAUT) 
     OVRDBF FILE(QADSPUPA) TOFILE(QTEMP/OBJAUT) 
 
  READ: + 
     RCVF 
     MONMSG MSGID(CPF0864) EXEC(GOTO CMDLBL(EOF)) 
     IF COND(&OAPGRP *NE '*NONE' *AND &OAPGRP *NE &GRPPRF) THEN(GOTO + 
        CMDLBL(READ)) 
     IF COND(&OAEXCL = 'X') THEN(DO) 
        CHGVAR VAR(&AUT) VALUE('*EXCLUDE ') 
     ENDDO 
     ELSE CMD(DO) 
        CHGVAR VAR(&AUT) VALUE(' ') 
        IF COND(&OAOPR = 'X') THEN(CHGVAR VAR(&AUT) VALUE(&AUT *BCAT + 
           '*OBJOPR')) 
        IF COND(&OAOMGT = 'X') THEN(CHGVAR VAR(&AUT) VALUE(&AUT *BCAT + 
           '*OBJMGT')) 
        IF COND(&OAEXS = 'X') THEN(CHGVAR VAR(&AUT) VALUE(&AUT *BCAT + 
           '*OBJEXIST')) 
        IF COND(&OAALT = 'X') THEN(CHGVAR VAR(&AUT) VALUE(&AUT *BCAT + 
           '*OBJALTER')) 
        IF COND(&OAREF = 'X') THEN(CHGVAR VAR(&AUT) VALUE(&AUT *BCAT + 
           '*OBJREF')) 
        IF COND(&OAREAD = 'X') THEN(CHGVAR VAR(&AUT) VALUE(&AUT *BCAT + 
           '*READ')) 
        IF COND(&OAADD = 'X') THEN(CHGVAR VAR(&AUT) VALUE(&AUT *BCAT + 
           '*ADD')) 
        IF COND(&OADLT = 'X') THEN(CHGVAR VAR(&AUT) VALUE(&AUT *BCAT + 
           '*DLT')) 
        IF COND(&OAUPD = 'X') THEN(CHGVAR VAR(&AUT) VALUE(&AUT *BCAT + 
           '*UPD')) 
        IF COND(&OAEXEC = 'X') THEN(CHGVAR VAR(&AUT) VALUE(&AUT *BCAT + 
           '*EXECUTE')) 
     ENDDO 
     IF COND(&OATYPE *NE *AUTL) THEN(DO) 
        RVKOBJAUT OBJ(&OALIB/&OAOBJ) OBJTYPE(&OATYPE) USER(&OAUSR) + 
           AUT(*ALL) 
        MONMSG MSGID(CPF2211) EXEC(GOTO CMDLBL(READ)) 
        CHGVAR VAR(&CMD) VALUE('GRTOBJAUT  OBJ(' *CAT &OALIB *TCAT + 
           '/' *CAT &OAOBJ *CAT ') OBJTYPE(' *CAT &OATYPE *CAT ') + 
           USER(' *CAT &OAUSR *CAT ') AUT(' *CAT &AUT *CAT ')') 
     ENDDO 
     ELSE CMD(DO) 
        IF COND(&OAAMGT = 'X') THEN(CHGVAR VAR(&AUT) VALUE(&AUT *BCAT + 
           '*AUTLMGT')) 
        RMVAUTLE AUTL(&OAOBJ) USER(&OAUSR) 
        MONMSG MSGID(CPF2211) EXEC(GOTO CMDLBL(READ)) 
        CHGVAR VAR(&CMD) VALUE('CHGAUTLE  AUTL(' *CAT &OAOBJ *CAT ') + 
           USER(' *CAT &OAUSR *CAT ') AUT(' *CAT &AUT *CAT ')') 
     ENDDO 
     CHGOBJPGP OBJ(&OALIB/&OAOBJ) OBJTYPE(&OATYPE) NEWPGP(&OAUSR) + 
        PGPAUT(*EXCLUDE) RVKOLDAUT(*NO) 
     MONMSG MSGID(CPF2211) EXEC(GOTO CMDLBL(READ)) 
     CALL PGM(QCMDEXC) PARM(&CMD 256) 
     MONMSG MSGID(CPF2211) EXEC(GOTO CMDLBL(READ)) 
     GOTO CMDLBL(READ) 
 
  EOF: + 
     ENDPGM 
 
  V3R1 Security Enhancements
 
 Figure   6 Logical File Authority Example
 
 
            UNABLE TO REPRODUCE GRAPHICS 
 
  V3R1 Security Enhancements
 
 Figure   7 New Authorities For Database Files
 
 
            UNABLE TO REPRODUCE GRAPHICS 
 
  V3R1 Security Enhancements
 
 Figure   8 Definition of Object Authorities
 
 
  Authority      Description      Functions 
 
  *OBJALTER      Object Alter     Add, clear, initialize, and reorganize members 
                                  of database files. Add and remove triggers. 
                                  Alter and add attributes of database files; 
                                  change the attributes of SQL packages. 
 
  *OBJREF        Object           Add and remove referential integrity 
                 Reference        constraints. 
 
  *OBJMGT        Object           Specify the security for the object. 
                 Management       Move or rename the object; includes all 
                                  functions defined for *OBJALTER and *OBJREF 
 
  V3R1 Security Enhancements
 
 Figure   9 QALWOBJRST Values for Restore Operations
 
 
 
  Value        Description 
 
  *ALL         Any object may be restored by a user with the proper authority. 
  *NONE        Security-sensitive objects, such as system state programs or 
               programs that adopt authority, may not be restored to the system. 
  *ALWSYSST    System state objects may be restored to the system. 
  *ALWPGMADP   Objects that adopt authority may be restored to the system. 
 
  V3R1 Security Enhancements
 
 Figure  10 Changes to Program Start Requests
 
 
            UNABLE TO REPRODUCE GRAPHICS 
 
  V3R1 Security Enhancements
 
 Figure  11 Work with Registration Information
 
 
                        Work with Registration Information 
 
   Type options, press Enter. 
     5=Display exit point   8=Work with exit programs 
 
                              Exit 
        Exit                  Point 
   Opt  Point                 Format    Registered  Text 
    _   QIBM_QGW_NJEOUTBOUND  NJEO0100     *YES     Network Job Entry outbound 
  ex* 
    _   QIBM_QHQ_DTAQ         DTAQ0100     *YES     Original Data Queue Server 
    _   QIBM_QLZP_LICENSE     LICM0100     *YES     Original License Mgmt Server 
    _   QIBM_QMF_MESSAGE      MESS0100     *YES     Original Message Server 
    _   QIBM_QNPS_ENTRY       ENTR0100     *YES     Network Print Server - entry 
    _   QIBM_QNPS_SPLF        SPLF0100     *YES     Network Print Server - spool 
    _   QIBM_QNS_CRADDACT     ADDA0100     *YES     Add CRQ description activity 
    _   QIBM_QNS_CRCHGACT     CHGA0100     *YES     Change CRQ description activi 
    _   QIBM_QNS_CRDLTSBMCRQ  DLTA0100     *YES     Delete submitted CRQ 
    _   QIBM_QNS_CRDSPACT     DSPA0100     *YES     Display CRQ description activ 
    _   QIBM_QNS_CREXCACT     EXCA0100     *YES     Run CRQ activity 
                                                                          More... 
   Command 
 
   ===> _________________________________________________________________________ 
   F3=Exit   F4=Prompt   F9=Retrieve   F12=Cancel 
 
  V3R1 Security Enhancements
 
 Figure  12 Converting Authority
 
 
 
  Object Authorities 
 
  Authority      *ALL      *CHANGE      *USE     *EXCLUDE 
  *OBJOPR          X          X          X 
  *OBJMGT          X 
  *OBJEXIST        X 
  *OBJALTER        X 
  *OBJREF          X 
  *AUTLMGT 
 
  Data Authorities 
  Authority      *ALL      *CHANGE      *USE     *EXCLUDE 
  *READ            X          X          X 
  *ADD             X          X 
  *UPD             X          X 
  *DLT             X          X 
  *EXECUTE         X          X          X 
 
  V3R1 Security Enhancements
 
 Figure  13 IFS Authority Commands and Corresponding Native Co
 
 
 
  INTEGRATED FILE SYSTEM COMMANDS       NATIVE COMMANDS 
  Command    Description                Command          Description 
  CHGAUD     Change Auditing Value      CHGOBJAUD        Change Object Auditing 
  CHGAUT     Change Authority           GRTOBJAUT        Grant Object Authority 
                                        RVKOBJAUT        Revoke Object Authority 
  CHGOWN     Change Owner               CHGOBJOWN        Charge Object Owner 
  CHGPGP     Change Primary             CHGOBJPGP        Change Object Primary 
             Group                                       Group 
  DSPAUT     Display Authority          DSPOBJAUT        Display Object Authority 
  WRKAUT     Work with Authority        EDTOBJAUT        Edit Object Authority 
 
  V3R1 Security Enhancements
 
 Figure  14 Integrated File System Authorities
 
 
 
  Authority    *RWX     *RW      *RX      *R       *WX      *W       *X 
                read     read     read     read     write    write    execute 
                write    write    execute           execute 
                execute  execute 
 
  Object Authorities 
  *OBJOPR       X        X        X        X        X        X        X 
  *OBJMGT 
  *OBJEXIST 
  *OBJALTER 
  *OBJREF 
  *AUTLMGT 
 
  Data Authorities 
  *READ         X        X        X        X 
  *ADD          X        X                          X        X 
  *UPD          X        X                          X        X 
  *DLT          X        X                          X        X 
  *EXECUTE      X                 X                 X                 X 
 
  V3R1 Security Enhancements
 
 Figure  15 New Edit Object Authority Panel
 
 
            UNABLE TO REPRODUCE GRAPHICS