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
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online