Admin Alert: Limiting *PUBLIC Access to i5/OS Objects, Part 1

i5, iSeries, and AS/400 machines have always featured best-in-class security. But that security doesn’t mean much if users can add, update, and delete records at will or if a user can execute a program he should be restricted from running. To prevent these kinds of security violations, it’s worth examining how i5/OS provides default library and object access to public users (*PUBLIC) and the problems those defaults present. These problems include undermining system security and the risk of exposing sensitive data and programs to unwanted access.

Note: This article is the first in a two-part series describing how i5/OS and OS/400 assign *PUBLIC authority to newly created objects on the system. This week, I’ll describe how i5/OS default security settings allow *PUBLIC users to modify data and run programs on an i5, iSeries, or AS/400 machine. Part 2 will describe ways to change these settings and the pitfalls you may run into as you make the changes. Also note that this scenario is in place not only for the i5/OS operating system used in newer i5 hardware, but it is also enabled in earlier versions of the OS/400 operating system that are installed on iSeries and AS/400 machines.

Meeting the *PUBLIC

When users request access to an object, the operating system goes through at least seven authority checks to determine whether or not they can use that object. These checks include comparing individual user profiles against the object’s authority settings as well as checking any groups or authorization lists that these users belong to against the authority settings. If i5/OS finds a match based on one of these criteria, it either allows or denies access to the object. For a complete description of how i5/OS performs object authority checking for a user, see Admin Alert: The Seven Levels of OS/400 Authority Checking.

Once the system has exhausted all authority checking against the users, the groups, and the authorization lists that they belong to, i5/OS performs one final check to see if the users can access the object as a *PUBLIC user. The *PUBLIC user is a catch-all bucket for an object that tells the system what access users can get if they are not explicitly authorized to the object through any other technique. By default, i5/OS will provide open data and object execution access to newly created objects in a library. That makes it important to understand what access *PUBLIC users have to new objects and how that access is initially set up. And once you understand how the *PUBLIC authorization process occurs, you can take steps to modify it to better serve your environment.

The Global *Public

With i5/OS security settings, the Create Default Public Authority system value (QCRTAUT) is critical to setting *PUBLIC access for new objects. QCRTAUT specifies the default *PUBLIC authority that is assigned to new objects as they are created in a library. By default, QCRTAUT is set to *CHANGE, which means that for any new objects that reference QCRTAUT for their *PUBLIC user authorities the *PUBLIC user can perform any data operations on that object (including reading, adding, changing, and deleting data as well as executing objects) but cannot perform any operations that physically alter the object itself (such as changing or deleting the object).

If desired, you can also change QCRTAUT to *ALL (which allows *PUBLIC users to perform any operation on a new object), *USE (which only allows a user to read data in an object or to execute a program object), or *EXCLUDE (which restricts the user from doing anything with the object). But for the purposes of this article, I’ll only discuss the implications that occur when QCRTAUT is set to its default value of *CHANGE.

Your partition’s QCRTAUT value can have a big effect on what *PUBLIC users can access in your system. The QCRTAUT system value affects *PUBLIC access in a round-about way, traveling from system value to library to object, and you need to understand how that process works before you can make any intelligent decisions about if or how you should change your QCRTAUT setting.

The *PUBLIC Library

QCRTAUT doesn’t set *PUBLIC authorities for newly created objects by itself. It has to be accessed whenever a library or an object is created. The first step in using QCRTAUT for determining *PUBLIC access authority in new objects occurs when a library is created.

In i5/OS and OS/400, libraries are created on the green screen by using the Create Library command (CRTLIB). Most administrators and software packages create libraries by running the CRTLIB command like this:

CRTLIB LIB(libname) TYPE(*TEST or *PROD) TEXT(‘text description‘)

However, due to CRTLIB defaults, the command is actually run with these parameters:

CRTLIB LIB(libname) TYPE(*TEST or *PROD) TEXT(‘text description‘) AUT(*LIBCRTAUT) CRTAUT(*SYSVAL) CRTOBJAUD(*SYSVAL)

The significant setting here is the Create Authority parameter (CRTAUT), which is set to *SYSVAL by default. The CRTAUT value helps i5/OS determine what *PUBLIC authority should be set for any new object that is created in this library, provided that the command creating the new object references the library’s CRTAUT parameter (which most of the significant Create commands do).

If you want to see what a particular library’s CRTAUT parameter is set to, you can run the Display Library Description command (DSPLIBD), like this.

DSPLIBD LIB(library_name)

The disturbing thing about this is that if a library’s CRTAUT parameter is set to its default setting of *SYSVAL, whenever a green-screen Create command queries its target library to determine what authorities should be assigned to *PUBLIC users for the object being created, the library setting will tell i5/OS to provide the *PUBLIC user with *CHANGE authority to the new object. It does this by referencing the QCRTAUT system value which, by default, is set to *CHANGE.

The mechanism that kicks all this off is the Authority parameter (AUT) that is present in almost all of the i5/OS Create commands (CRTRPGPGM, CRTPF, CRTCLMOD, etc). By default, the AUT parameter is automatically set to *LIBCRTAUT in these commands, which tells i5/OS to retrieve the *PUBLIC user authority from the CRTAUT setting in the library where the object is being created. So for most new objects that are created from green screen commands, i5/OS sets *PUBLIC authority for that object by running the following sequence.

1.  It checks the Authority parameter (AUT) on the Create command that is used to create the object. If AUT is not equal to *LIBCRTAUT, it assigns *PUBLIC authority to the object based on the command’s AUT value (either *ALL, *CHANGE, *EXCLUDE, or *USE) and ends the process.

2.  If the Create command’s AUT parameter is set to *LIBCRTAUT (the default for most commands), i5/OS will check the value contained in the Create Authority (CRTAUT) setting of the library the object is being created in.

3.  If the library’s CRTAUT value is set to *ALL, *CHANGE, *EXCLUDE, or *USE, the *PUBLIC user is assigned that authority for the new object and the process ends.

4.  If the library’s CRTAUT value is set to *SYSVAL, i5/OS will retrieve the value stored in the Create Default Public Authority system value (QCRTAUT) and it uses that setting as the default *PUBLIC user authority for the new object.

What this sequence means is that, if you go with i5/OS defaults for these values, most of the new objects on your system will have a default *PUBLIC authority of *CHANGE. This, in turn, means that most system users without explicit authority to the new object can read, add, change, or delete data contained in the object. This can be dangerous if the *PUBLIC users are able to access data through ODBC, OLE DB, or JDBC drivers using SQL. It also means that *PUBLIC users will be able to run most newly compiled programs if your menu security does not restrict the user from executing them. By default, i5/OS will let users access, modify, and run any newly created object on the system, if you don’t change *PUBLIC authorities on those objects that you don’t want them to access.

Where the Problem Ends

This problem is in effect for objects created by using Create commands in i5/OS and libraries that access the QCRTAUT system value for default *PUBLIC authority. If you change the CRTAUT parameter for a library to stop referencing QCRTAUT, it will not automatically change the *PUBLIC authorities on already created objects in that library. Once *PUBLIC authority is set for an object, the only way to change it is by manually changing the object’s authority list. In Part 2, I’ll discuss several ways to reverse the effects of this default security configuration, and the benefits and pitfalls each solution provides to your shop.

RELATED STORIES

Admin Alert: The Seven Levels of OS/400 Authority Checking