Security typically operates so that users who are not granted authority have no authority. IBM i security, however, has a unique concept known as *PUBLIC. This is a default authority that is assigned to a user that has no specific authority of their own, and it often leads to unexpected access to objects. It’s critical that this authority be clearly understood to ensure that the environment is well-secured.
Many people shy away from implementing an object-level security model due to the confusion that occurs when a user is “mysteriously” denied access to an object. In reality, the operating system determines authority using a decision flowchart. Assuming that the user does not have *ALLOBJ special authority, then the checking progresses in search of any specific (private) authority—either authorizing or preventing access if such authority is found. If no specific authority exists for a user the operating system checks the user’s group profiles for *ALLOBJ and private authority. If none of these are satisfied then the public authority is used.
I would recommend downloading the IBM i Security Reference Manual for more information regarding the decision flowchart, or send me an e-mail and I’ll send you a one-page .pdf version of it. While a good understanding of the entire flowchart is important, today’s focus is on the final allocation of *PUBLIC authority in a native (Qsys.lib) environment, and where that authority comes from.
Public authority is assigned every time a new object is created. Create commands have an authority (AUT) parameter which designates the authority that *PUBLIC will be given. Four standard authority templates are available: *EXCLUDE, *USE, *CHANGE, or *ALL, plus a special value of *LIBCRTAUT. An example can be seen in the screen shot below:
Granting *EXCLUDE authority might seem counter-intuitive, but it’s often necessary to facilitate a user or group being controlled more tightly than *PUBLIC. However, best practices mandate that a deny-by-default model be adopted, which entails *PUBLIC having the least privileges. Only users with a demonstrated business requirement to access objects should be granted permission.
The create commands default to a special value of *LIBCRTAUT which instructs IBM i to defer to an authority attribute on the library where the object is being created. The library’s authority (AUT) parameter permits designation of the same four authority templates as the create commands. A special value of *SYSVAL instructs IBM i to defer again; this time to the QCRTAUT system value. An example of this library attribute is shown in the screen shot below:
The system value is the final referral point and permits the administrator to specify one of the four authority templates. The main controversy with *PUBLIC authority comes from the fact that IBM ships the QCRTAUT system value with a value of *CHANGE. This is sufficient to invoke a program and to read, update, and delete data in a file.
I recommend that the create commands remain at their default value of *LIBCRTAUT to defer the decision to the library. Then, rather than deferring to the system value, each library should be given the appropriate authority that will be granted to any new objects. This permits each library to maintain its setting appropriate to the type of objects and application that it contains. While auditors may still focus their attention on the QRTAUT system value, this will only be pertinent to libraries that do not have their own specific authority value.
If every new hire in a corporate environment was handed a key to the human resources filing cabinets, we would all remark what a ridiculous scenario it was. But, when a new user is given credentials to a server that has open *PUBLIC authority, we are basically doing that very thing. Objects should be created with very limited—if any—public authority, and then access should be granted privately to the appropriate users or group profiles.
Permissive public authority can expose data to users with access to network-initiated interfaces, such as FTP and ODBC, as well as users with command line access and the ability to use powerful utilities such as SQL and DFU. As previously mentioned, public authority should be very tightly controlled and authorized users granted the necessary permission. Establishing the correct level of public authority now can prevent data breaches later.
Cheers!
—rt