Low Risk Authority Changes

For years, many people, including me, have harangued you to “get rid of PUBLIC” authority. Despite all of the pleading, however, there remains a large number of customers that still have PUBLIC authority set to *USE or higher. I suspect at least part of the reason is because many of us are afraid to monkey with PUBLIC authority for fear of breaking something major. This fear is understandable. Many administrators are responsible for applications that were written before they joined the workforce.

A fairly trivial technique that I call “alternative PUBLIC authority” takes the fear–and the risk–out of changing PUBLIC authority on libraries, programs, and data objects for virtually any application. The idea behind this technique is to create an environment that ensures nobody breaks while allowing you to make and test authority changes using selected user profiles. Alternative public authority will work for any environment where PUBLIC authority is something other than *EXCLUDE.

Implementing alternative public authority is straightforward and fairly easy. Just follow these steps:

1. Create a new user profile. For this tip we’ll call it “ALTPUBLIC”.
2. Make every user profile on the system (except those profiles that are already group profiles) a member of this group. I use a small CL program to automate this task.
3. For each library, program, and data object associated with the application that you want to fix, grant ALTPUBLIC the same authority that PUBLIC currently has to the object. In practice, I usually find that PUBLIC authority is the same for everything.
4. Change PUBLIC authority on the same objects as step 3 to *EXCLUDE. Again, I have a small CL utility that automates steps 3 and 4. The utility isn’t required; it just saves time.

You now have an environment that allows you to make and test all kinds of authority changes, including adopted authority, without fear of breaking any users. But you haven’t changed the security of your system one iota yet. You have only changed the way that you have guaranteed that no one will break. Ironically, the next task is to make the additional authority changes that allow you to get rid of ALTPUBLIC.

It’s easiest to use an example to describe how to get rid of ALTPUBLIC. We’ll assume that you have decided to employ application-only access (adopted authority) for your primary application. After setting up alternative public authority, you: a) created a user profile, APPOWNER; b) changed the libraries, programs, and data objects associated with the application to be owned by APPOWNER; c) changed the initial program to adopt APPOWNER. Of course, these changes did not affect any users of the application.

Now you want to find out what other changes you may need to make. For example, you may need to change programs that are submitted to batch to also adopt authority. But how do you find which programs these are? Easy. Select a user profile to use for testing. Remove that profile from the ALTPUBLIC group. Sign on as that user and run the application. This will find places in the application that need to be addressed further. Address the problems found. Now take another user profile out of the ALTPUBLIC group and repeat the testing. As your confidence in the changes increases you might remove the profiles for an entire department. Once you are completely confident in your changes, delete the ALTPUBLIC group profile.

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.

                     Post this story to del.icio.us
               Post this story to Digg
    Post this story to Slashdot