Oh My!

I am flabbergasted by the large number of customers that either don't manage access control at the library and object level or use an open access control model. Many customers just use the system defaults for PUBLIC authority, which means all users have *CHANGE authority to most application data. Some ISVs have never tested with anything other than the system default access control and therefore don't officially support any other configurations.

I don't believe it is possible to correctly implement even the most basic of security policies today without more tightly managing library and object access control--even with third-party vendor exit point solutions. Don't get me wrong, exit point products provide lots of value in terms of allowing you to implement more stringent or granular access control to the interfaces. If you fall into one of the scenarios described above and don't have an exit point solution installed, run--don't walk--to an exit point security vendor.

But exit point solutions only protect access to interfaces. They do not protect access to the data. And today, too many different interfaces can potentially be used to access a single piece of data. It is difficult to ensure that a specific exit point solution covers all of the interfaces you need covered. Exit points don't exist for every possible means of access data on your system. For example, the Apache Web Server does not have an exit point. Sure, you can build a custom Apache mod_auth module, but how many exit point vendors provide one today? Finally, vendor applications tend to be at least one release behind the most current, and most are further behind than that. If IBM adds a new interface--even if it has an exit point--how long will it be before the exit point vendors catch up?

Again, exit point solutions provide a great amount of value with or without a proper access control strategy. If you aren't already tightly managing access control on libraries and objects, they provide a higher level of security than you already have and should be used while you implement an adequate access control model. They are not, in my opinion, an alternative to proper access control.

When I discuss the need for a tighter access control policy with customers, many respond that they have "always run the system this way" and now have hundreds or thousands of libraries and objects. They can't even begin to comprehend where they would start to implement a reasonable access control mechanism. It appears to be the proverbial "you can't there from here" problem to most people.

My goal for this and the next article is to convince you otherwise!

Getting There from Where You Are Today

First and foremost, understand that moving to a reasonable access control model will truly be a journey for most customers, not a Star Trek transporter experience in which you are in the Enterprise one moment and on some unheard-of planet the next.

The journey consists of a number of independent objectives that you can achieve individually rather than all at once. In our travel analogy, we are at point A. Our goal is to get to point D. But there is no known route directly from A to D (or there's a direct route, but a mountain range is in the way). Instead, we'll start from where you are now, point A, and head toward some intermediate points before arriving at our final destination, point D. Each point along the way will either make it easier to get to the next point or get you closer to the goal.

Remember, the ultimate goal of having no users with any direct authority to application data is one step beyond what will be covered in these two articles. Our goal, point D, is for you to implement an exclusionary access control model. Once you have accomplished this, then you can whittle away at minimizing the amount of authority users have to application data.
Our goal, then, is to move your system from an open access control model to an exclusionary access control model, which defaults the PUBLIC authority on newly created objects to *EXCLUDE unless explicitly set to something else. In an open access control model, PUBLIC is defaulted to *USE or higher on newly created objects unless explicitly told to do otherwise.

It's Too Complicated!

Most customers find the prospect of moving to an exclusionary access control model overwhelming. But it doesn't have to be! With the approach defined in this article, you can move your entire system to an exclusionary model on an application-by-application basis, on your time schedule, while minimizing the potential for disrupting your production system. You don't have to change every application at once.

To change the access control model on your terms, rather than the system's, you first have to understand how the system derives the default PUBLIC authority. Armed with this understanding, you can change each application to derive PUBLIC authority at the application level rather than the system level.

Deriving PUBLIC authority at the application level allows you to work with each application individually and independently of other applications. For example, change one application this month and another next month, and eventually you will have moved the entire system to an exclusionary access control model--while still having time to accomplish all the other tasks for which you're responsible.

Using this approach also minimizes the risk of disrupting mission-critical production applications.

To understand why and how this approach works so well, you need to understand how the system decides what the public authority of an object or library should be when you don't explicitly tell the system what to set it to.

How Default PUBLIC Authority Is Derived

"Default PUBLIC Authority" refers to the PUBLIC authority assigned by the system to a newly created library or object when that authority is not explicitly specified by the AUT parameter of the CRTxxx command that creates the object.

Most people (including me) would respond to the question "How does the system determine the value it assigns as the PUBLIC authority for objects created on the system?" with something like this: "It depends on the current setting of the QCRTAUT system value." While this answer will generally correctly predict the value the system ultimately assigns to a new object, it's not the correct answer to the question!

This inaccurate mental model--that the value of QCRTAUT directly controls the default value of PUBLIC authority of newly created objects--is what makes the idea of changing to an exclusionary model seem so utterly unattainable.

So how does it really work? It's simple and complex at the same time.

PUBLIC Authority to Objects

If you don't explicitly tell the system what the PUBLIC authority of an object should be when you create it, the system will use the "PUBLIC authority policy" for the library into which it is created. That's it. That's what you really need to understand.

Library PUBLIC Authority Policy

Ok. So what's the PUBLIC authority policy for a library? The value of the CRTAUT library attribute is the PUBLIC authority policy for that library.

This is where it starts to get a little complicated. A library's PUBLIC authority policy is entirely independent of the authority PUBLIC is granted to the library itself. The former is a policy that is applied to objects created in the library. The latter is the authority PUBLIC has to the library. Both of these are set at the time a library is created.

PUBLIC Authority to Libraries

PUBLIC authority to a library is also derived from policy. You just have to remember that, with respect to PUBLIC authority to the library, libraries are assumed to be created in library QSYS. Therefore, it is derived from the policy in effect for library QSYS.

Library PUBLIC Authority Policy vs. PUBLIC Authority to Libraries

If you don't explicitly tell the system what the PUBLIC authority policy of a library is, the policy will be to use the system's PUBLIC authority policy in effect at the time an object is created in the library. Note that this is distinctly different from setting the library policy to be whatever system policy is in effect at the time the library is created! While the policy itself is set at the time the library is created, the value of that policy is determined at the time an object is created in the library.

Like all policies, there are often exceptions. For example, even though the policy for objects created in a library is *EXCLUDE, there may be one or more objects in the library to which PUBLIC has been granted some higher level of authority. A useful rule of thumb is that the PUBLIC authority policy for a given library should reflect the value required by the majority of objects in the library.

Valid System and Library PUBLIC Authority Policies

The system's PUBLIC authority policy can be one of the following: *ALL, *CHANGE, *USE, *EXCLUDE.

A library's PUBLIC authority policy can also be any one of these values. However, there are two additional options: *SYSVAL or the name of an authorization list. *SYSVAL indicates that the PUBLIC authority policy of the library is the system policy in effect at the time an object is created into the library. Unless you indicate otherwise, the system assumes that you want *SYSVAL to be the value of the library's PUBLIC authority policy (i.e., *SYSVAL).

Now you have an accurate conceptual model of how the system derives PUBLIC authority for new objects when it is not explicitly specified when the object is created.

Let's briefly discuss how this behavior is enforced on the system.

Default Policies

QCRTAUT, which specifies the system's PUBLIC authority policy, is set to *CHANGE by default. The policy can be changed with the CHGSYSVAL command.

IBM sets the policy for library QSYS to *SYSVAL by default. It tells the system to apply the system policy in effect at the time an object or library is created in the QSYS library. You can change this with the CHGLIB command.

The CRTLIB command's CRTAUT parameter also defaults to *SYSVAL. User-created libraries will have the same policy as library QSYS. You can change the command default for CRTAUT to something else. You can also use the CHGLIB command to change the value of CRTAUT after the library is created.

Default PUBLIC Access

The AUT parameter on all CRTxxx commands specifies the authority the system should grant PUBLIC to the object being created. This applies to libraries as well as objects created in them. By default, this value is set to *LIBCRTAUT. It tells the system to apply the policy of the library into which the object is being created (i.e., the value of AUT = the value of the library's CRTAUT attribute = *SYSVAL = the value of QCRTAUT).

Now you have an accurate model of how the system derives PUBLIC authority for newly created objects on the system. In the next article, I'll describe a process for moving your system to an exclusionary access control policy over time--not all at once--in a way that minimizes the potential of disrupting production applications.