Object Authority Settings

Object authority settings are often derived from the default Library authority. The default Object authority describes what authority the public (*PUBLIC) will have to newly created objects inside a library. When a new object is created via any of the IBM create commands, the parameter that determines the public's initial authority is normally set to be equal to the Library Create authority of the library that the object was created in. A typical example would be:

CRTPF FILE(PAYLIB/PAYROLL) SRCFILE(PAYLIB/QDDSSRC) AUT(*LIBCRTAUT)

In this case, the AUT(*LIBCRTAUT) parameter instructs the CRTPF command to give *PUBLIC the authority that is specified in the library's CRTAUT parameter. Because most customer’s libraries have the CRTAUT set to *SYSVAL, and the system value for QCRTAUT is set to *CHANGE, all new objects created on the system will, be default, be set to *CHANGE authority.

Note: According to the PowerTech System i Security Study, 86% of libraries reviewed had the Default Create Authority set to *CHANGE.)

You may want to consider changing this value to a more restrictive setting, *USE, or even *EXCLUDE, and then using a change management product such as Turnover (from Soft Landing Systems) to regulate the authority of newly created objects. *CHANGE authority is certain to be too permissive for some objects (programs, print files, display files, etc.) and too restrictive for other objects (certain data files, message queues, data queues, etc.)

STATIC (Program) OBJECTS

On a library by library basis, the customer should determine what the default authority should be for object types. For libraries that contain only programs and other static objects, the authority for any user (let alone *PUBLIC) need be no higher than *USE. The reasoning behind this is quite clear, usually no one other than the owner of the object, or the Production Systems Administrator would ever need to do anything other than use a program, job description, or subsystem description.  

Additionally, if the data itself is secured properly, even giving *PUBLIC use authority to a program does not normally create a security risk because it is data (not programs) that we are most interested in protecting.

The following is a list of objects that typically can be restricted to *USE (or less) authority:

Purpose

The AUT parameter on all of the IBM create commands (CRTxxx) defines what the *PUBLIC's authority will be to new objects. This value can and should be set at the library level. Where program objects are stored together in a library, the default library authority should be set to no higher than *USE.

Risks and Concerns

Setting this parameter to *USE will prevent accidental modification by end users. It will also preclude programs from being put into debug mode without any special authorization. For Static (Program type) objects, *USE is sufficient in all but the very rarest of cases.

DYNAMIC (File) OBJECTS

For some, but certainly not all, data objects *USE authority is too little authority. End users usually need *CHANGE authority to files that they propose to modify (add orders, update customer records, etc.). In better than 95% of the cases, you would want your users to have  *CHANGE authority to the data. The other 5% would have to be manually reviewed to determine whether the data object required more or less than *CHANGE authority.

Purpose

The AUT parameter on all of the IBM create commands (CRTxxx) defines what the *PUBLIC's authority will be to new objects. This value can and should be set at the library level.

Risks and Concerns

While setting this parameter to merely *CHANGE will prevent accidental deletion by users, for a few selected objects the customer will likely find that *CHANGE authority is too little (for example: files that are "cleared" or deleted by end users). Further, for certain sensitive files, *CHANGE authority will likely be too much authority and keep open that file at risk of disclosure or even corruption from network interfaces. An exit program package can help secure ultra sensitive objects, but objects that require heightened levels of authority will require individual identification.

About Object Ownership Settings

Object ownership on the AS/400 confers powerful rights to not only the owning profile, but if the owner of an object is a group profile, any member of that group also receives ownership rights. The owner of an object (and any group members) by default will have complete authority to the object.  This includes the ability to see all of the contents of the object, change any attribute or data element in the object, move, rename, specify security for, and/or delete the object.  

For obvious reasons, ownership of production objects by end users is not desirable. The ideal scenario is to have an owner profile that owns all objects within an application. That owner profile would not be a group profile, and would not be capable of signing on the system. The purpose of owner profiles is to own application objects, and under limited circumstances, use adopted authority to convey those ownership rights to authorized users and functions. Many of the third party packages on your system use this "Owner Profile" authority scheme.

Third Party Application Owners should not assign ownership of objects to IBM profiles such as QPGMR, QUSER, QDFTOWN, and QSECOFR. When a vendor does this they put their customers at risk of the fallout of any changes IBM may make to those profiles. Also, there are several well known hacks for acquiring the authority of QUSER, and QPGMR. Having those profiles own application objects puts those objects at risk of those hacks.

Note: The following involves reviewing the PowerTech Compliance Monitor 'Group Profiles Report' to determine what group profiles are used on the system, and then cross referencing that to the PowerTech Security Audit "Report of Object Authorities" in library QSYS.

Areas of special attention and concern

The OBJOWNR profile is both the owner of all application objects and the group profile that all application users belong to. This gives every application user ownership rights over every application object. This security scheme results in a system that may be safe as long as all users are captured in the application menu system, but is terribly exposed to any access from the outside such as commands, network access (FTP, ODBC, etc.), and desktop decision support tools.

Ownership of objects by default IBM profiles such as QPGMR, QDFTOWN, and QSECOFR. This can occur either because of direct use of those profiles at the customer site, or it can be imposed on you by a third party software vendor who inappropriately uses the IBM profile to manage their own security. Use of default IBM profiles is dangerous not only because of the ease in which some of these profiles can be used by any system user, but also because the application is depending on IBM to not substantially change the way that these profiles operate. A third concern is that if two different applications both use QPGMR as their owning and authorizing profile, neither application will be able to prevent users of the other from accessing it's data.

Purpose

Every object must have an owner, and the owner by default has extraordinary rights (including delete rights) to the objects created. The owner profile should be a profile that is not used to signon. Only under rare circumstances would the object owner's authority be conferred to another system user.

Risks and Concerns

Changing object ownership is relatively low risk because it is rare for users to attain authority directly from the object owner. Additionally, the *PUBLIC's authority to most objects is already set to *CHANGE, which all but eliminates any risk of users being not authorized to objects. The only area of potential concern is where programs adopt their owner's authority for a specific purpose.