Learn To Debug Authority Failures, Part 1
September 14, 2011 Patrick Botz
|
It is truly amazing how many IBM i administrators and programmers do not understand how to debug authority failures. When a user they support encounters an authority failure, many typically do one of two things:
Attacking authority failures in this way results in huge security holes. And this practice is almost certainly non-compliant with the organization’s written or unwritten security policy. Further, when the change happens to fix the authority failure, they assume that “it has to be this way, or the application breaks”. Over time the entire system becomes wide open, and everyone is afraid to change anything because nobody really understands when or why authority failures occur. But it just doesn’t have to be this way! With a basic understanding of how the system does authority checking and by gathering and analyzing necessary data about the failure–before making any changes–you can make appropriate changes that are compliant with your security policies and that don’t make the system less secure. The intent of this article, and the two that will follow, is to provide you with the information and tools you need to rationally, efficiently, and effectively debug and fix authority failures. This article describes how the operating system performs authority checking. The next article will describe what information you need to debug authority failures and where and how to find it. The third article will describe how to use the information to make appropriate authorization changes to solve authority failures in a way that is compliant with your security policy. Authority Checking Algorithm Description You need to have certain information about an authority failure in order to make sure you understand why it occurred in the first place. If you don’t understand why the failure happened, you cannot possibly identify a rational change that fixes the problem and that doesn’t unnecessarily, unknowingly, and significantly weaken the security of your application and system. Armed with the proper information, fixing the problem requires you to understand surprisingly little about the internals of the application or interface encountering the failure. Way more often than not, little or no further analysis is required to fix the failure. The necessary information can typically be gathered and the fix made within a couple of minutes–assuming you are using operating system tools correctly. A good grasp of how IBM i determines whether a requested access of an object should be allowed will help you understand what debugging data is needed and why. The following is a very short description of the authority checking process. See the Security manual in the IBM Information Center for much more detailed information. In an abstract sense, all authority checking comes down to determining if an entity is allowed to perform a requested operation on a specified object. This means the operating system needs to know:
So where does the operating system get all of this information? For starters, the “who” information is defined in the data structures representing an executing job. Who’s Asking? Associated with each job on the system is a user profile, an optional group profile, and an optional list of supplemental groups. The job is said “to be running under the authority of” these profiles. At the time a job is created, these values are set to the user profile that started the job and the group and supplemental profiles, if any, defined in that user profile. Programs that adopt authority can add additional user profiles to the list of profiles under which a job is running. When a job loads a program that adopts authority, the user profile of the owner of the program is added to that job step and to subsequent job steps. Adopted user profiles are not added to job steps prior to the one that loaded the adopting program. Together, all of these profiles constitute the list of “profiles under which a job is executing.” In other words, all of these profiles collectively represent the “who” making a request to access and object. It is important to note that executing programs can use system APIs to dynamically change or modify the user, group, and/or list of supplemental group profiles under which a job is executing. You cannot blindly assume that a job is running under the profile, primary group, and supplemental groups of the user that created the job. So now we know how the system establishes “who” is making a request to perform some operation on an object. How does it determine if the requested operation on the object should be allowed? To do this, the system has to determine which profiles are allowed to perform what kinds of operations on the object. What Operation Do They Want To Perform? System interfaces define how much authority to an object is required in order for the system to allow the operation to be performed. For our purposes, the terms “operation” and “authority” are interchangeable. Operation is typically used when referring to the authority required to an object. Authority is normally used to refer to the authority a user profile has been granted to an object by an administrator. The operations a user can perform on (or the authority a user can be granted to) an object are one of *ALL, *CHANGE, *USE, *EXCLUDE. These operations are hierarchical in that if a profile is allowed to perform *ALL operations, it is allowed to perform *CHANGE and *USE operations. Similarly, if a profile is allowed to perform *CHANGE operations on an object it also allowed to perform *USE. *EXCLUDE means that a user profile is explicitly not allowed to perform any operations on an object. It is an authority, but the authority is that the user profile is specifically not allowed to do anything to the object. This may seem a little strange, but it makes sense in terms of the authority checking algorithm the operating system uses. One of the rules of authority checking is that when any authority is found, the authority checking algorithm is short-circuited. Therefore *EXCLUDE is very different from merely not having any specific authority. What Operations Are The Users Authorized To Perform? Administrators are responsible for defining how much, if any, authority all user profiles have to each object on the system. This is done by granting authority to user or group profiles to objects. There are four ways an administrator can specify the user profile(s) to which they are granting authority:
PUBLIC authority is also sometimes referred to as the default authority. It literally means “all of the other profiles on the system that are not the owner or primary group of the object nor specified in any of the private authorities to the object.” The owner, primary group, and PUBLIC are attributes associated with each object on the system. Administrators grant authority to the entities represented by these attributes. Objects also have a list (possibly empty) of private authorities. A private authority includes the name of a user profile and the authority that user profile has to that particular object. Should The Operation Be Allowed? During execution of a job, the operating system compares the authority required to perform the requested operation to an object against the authority the user profile(s) under which the job is running has/have to the object. There is a well defined algorithm for the order in which the operating system does this comparison for each of the profiles under which the job is currently running. Essentially, however, it looks at the job’s current user profile, then the job’s group, followed by each of the job’s supplemental groups. (*ALLOBJ special authority–really a privilege–is a way to short-circuit the authority checking algorithm. For purposes of this article, it is not necessary to describe how this fits in to the authority checking algorithm.) It is very important to understand that it doesn’t matter whether the necessary authority comes from the owner, primary group, supplemental groups, or from PUBLIC authority. I am often told by administrators that “PUBLIC has to be *CHANGE on this object” or the application fails. This is NEVER a valid statement. It doesn’t matter whether PUBLIC is *CHANGE, or the user profile under which the job is running is the owner, primary group, or one of the supplemental groups. It is only valid to say that the profile(s) under which the job is running must have *CHANGE to the object. For example, let’s say that object A is a file member. To clear a file, you have to have *CHANGE to it. Further, let’s say that a job that executes the clear file member command is running under user profile FRED. User profile FRED is a member of group profile FOO. FOO is the primary group of the object and it has been granted *ALL authority to file A. PUBLIC authority is *EXCLUDE. The job will be allowed to clear the file, even though PUBLIC is exclude because FOO is one of the profiles under which the job is currently running and FOO has *CHANGE authority to the object. The fact that the job gets an authority failure when PUBLIC is not *CHANGE does not mean that granting PUBLIC *CHANGE is the only way to prevent the job from receiving an authority failure for users who should be authorized. Summary In this article, I have defined how the operating system determines whether to allow a requested operation to be performed on an object by the user profile(s) making the request. I have also described where the operating system finds this information. An understanding of the authority checking algorithm and the data used is needed in order to debug authority checking failures. In the next article, I will describe the specific information you need in order to determine why an authority failure occurred. Patrick Botz is the principal consultant and founder of Botz & Associates Inc. He is also president of Valid Technologies, LLC, a biometric middleware ISV. Pat spent nearly 20 years working at IBM in various security roles including lead IBM i security architect, IBM eServer security team, and the head of IBM Lab Services Security Consulting practice. Check out his Website at www.botzandassociates.com. Send your questions or comments for Patrick to Ted Holt via the IT Jungle Contact page.
|
