Live Security Related Webcasts and Training for IBM i

March Events

Live Hands-On - IBM i, iSeries System Operations Workshop
with Dan Riehl
Training Workshop - Mar 6 - 8 - Presented by The 400 School, Inc.
Dan Riehl presents this 3-Day Live Online Hands-on Workshop.
More Information and Register to Attend

Live Hands-On - IBM i, iSeries System Administration and Control Workshop
with Dan Riehl
Training Workshop - Mar 13-17 - Presented by The 400 School, Inc.
Dan Riehl presents this 5-Day Live Online Hands-on Workshop.
More Information and Register to Attend

Live Hands-On - IBM i, iSeries Concepts and CL Programming Workshop
with Dan Riehl
Training Workshop - Mar 20-24 - Presented by The 400 School, Inc.
Dan Riehl presents this 5-Day Live Online Hands-on Workshop.
More Information and Register to Attend

Live Hands-On - IBM i, iSeries Expanded Security Workshop
with Dan Riehl
Training Workshop - Mar 27-30 - Presented by The 400 School, Inc.
Dan Riehl presents this 5-Day Live Online Hands-on Workshop.
More Information and Register to Attend

April Events

Live Hands-On - IBM i, iSeries System Administration and Control Workshop
with Dan Riehl
Training Workshop - Apr 24-28 - Presented by The 400 School, Inc.
Dan Riehl presents this 5-Day Live Online Hands-on Workshop.
More Information and Register to Attend

May Events

Live Hands-On - IBM i (iSeries, AS/400) Security Audit
                               and Vulnerability Assessment Workshop
with Dan Riehl
Training Workshop - May 9-12 - Presented by The 400 School, Inc.
Dan Riehl presents this 4-Day Live Online Hands-on Workshop.
More Information and Register to Attend

Security Shorts

Gain Flexibility with Authorization Lists

By Dan Riehl

The Feature Article in this issue of the SecureMyi Newsletter discusses the topic of Authorization Lists, and how they are often misunderstood. I did not mention that additional flexibility can be gained by securing libraries and other objects with an authorization list rather than with a list of private and *PUBLIC authorities.

In a recent case, a customer wanted to change the *PUBLIC authorization on certain production libraries from *CHANGE, to the more restrictive *USE. This needed to be done in order to keep users from adding new objects into the production libraries. If a user has *CHANGE authority to a library, the user can add new objects to the library. But, if the user has only *USE authority to the library, they cannot add new objects.

The problem in this case, was that the private and *PUBLIC authorities to the production libraries could not be changed while the system was up and running. Since users have these production libraries on the user portion of their job's library lists, a *SHRRD(Shared for read) lock is placed on the library object, prohibiting the authorities from being changed while the system is up and the users logged on.

Since this is a 24x7 uptime shop, we needed to wait for several weeks to get clearance for a scheduled outage so we could make the change to *PUBLIC AUT(*USE).

Since I wanted to make sure we had flexibility for any future authorization changes to these libraries, the decision was made to use the scheduled outage to change the authorization method for the libraries. Instead of simply changing the *PUBLIC authority from *CHANGE to *USE, we would create an authorization list for each "in-scope" library, and then during the outage, we would change the libraries to be secured by the associated authorization list. Which we did.

One of the big advantages of using an authorization list, is that they can typically be changed on-the-fly, during system uptime. This flexibility will come in very handy the next time an authorization change needs to be made to any of these production libraries, Next time, we will not need an outage, we can simply change the authorization list.

Some of you are pondering a very good question right now. That is: "Using the new Authorization list scheme, won't you break something when you change the production library authorities on the fly?". The answer is: As long as the change that is being made is not creating a new restriction, nothing will break. If the change to the authorization list is creating a new restriction, that type of change may require an outage.

(Note: The System Value QLIBLCKLVL can be used to specify that libraries are NOT locked by a job simply because they are on the job's library list. For more information, see the IBM Information Center discussion on the System Value QLIBLCKLVL.