You may have heard that IBM included an interesting new security-related enhancement in the V7.3 release. Called authority collection, it provides information intended to help security administrators minimize the amount of authority to objects granted to users on a system.
Authority collection will prove to be a useful addition to your information security management tool chest. This is the good news.
The bad news is that the new function is far from a silver bullet. That’s not the fault of the function.
However, I think authority collection will further the mistaken notion that user profiles require authority to any object in order for an application to perform actions on those objects!
This invalid assumption is one of the main reasons access control has been so poorly managed in so many shops in the first place.
But before I go there, let’s talk about the new function.
How It Works
Authority collection information is gathered on a profile-by-profile basis. The STRAUTCOL command tells the system to begin collecting authority information for a specified user profile and objects. Objects can be specified based on library, path, name, and type.
After telling the system to start collecting authority information for a specific user, any time that user touches any of the specified objects – with some exceptions, including for certain components of the operating system – the OS creates an entry on the system. Each entry contains a slew of information related to authorization including, but definitely not limited to:
- User name,
- Group name,
- If multiple groups were used to satisfy the required authority,
- Required authority,
- Current authority,
- Source of the authority (whether or not it was sufficient),
- If adopted authority was used,
- Source of adopted authority,
- Authorization list name,
- Name of authorization list used to secure the object.
This information is collected until the ENDAUTCOL command for the specified user is executed.
You use SQL queries to analyze the collected information. The OS provides the QSYS2.AUTHORITY_COLLECTION view, which allows you to query authority information for multiple users and or objects.
The Good
Authority collection provides valuable information for the administrator. Having this information provides several benefits.
Make Authority Changes While Limiting Breakage Risk
Information generated by the authority collection function tells you exactly how much authority a user needs to which objects. This has the potential to eliminate the “I can’t make this authority change because I don’t know what it will break” statement from the lexicon of the administrator. This is a hugely valuable benefit!
One obvious way to use the tool becomes apparent.
On the STRAUTCOL command, select a single “representative” user of a specific application. Select some or all of the objects in some or all of the libraries associated with the application. Have that user perform all of the application tasks they normally do throughout the business cycle. When those tasks are completed, query the authority collection view looking for the required authority and the current authority.
If you find objects where the required authority is less than the current authority, you may be able to reduce the required authority for that user and all the users for which that user is “representative.” Of course, you’ll want to look at the source of the user’s authority to determine how to reduce the required authority. For example, reduce the user’s private authority to the object or to the authorization list that secures the object; reduce the authority of a group(s) in which the user is a member; etc.
You’ll probably want to run this tool on an application-by-application basis.
Here’s the command help for STRAUTCOL from the IBM Knowledge Center
STRAUTCOL for ISV Applications
Authority collection will be especially useful with ISV applications. Many ISVs — too many — either leave access control to the customer or only test with PUBLIC authority being *CHANGE or *ALL. I’ve even seen ISV documentation that says if you change this it invalidates your support contract!
Authority collection will give administrators the information they need to at least limit access to application objects to those users that actually use the application; not all users on the system.
STRAUTCOL for the Root File System
Authority collection will be useful for applications that use resources in the IFS root (i.e. “/”) directory. Many administrators don’t understand how authority works in the IFS. In addition, adopted authority is not considered when accessing resources in the IFS.
Since the IFS was introduced (V3R1M0), IBM has shipped the root file system with PUBLIC *RWX (essentially *ALL). This was not the best choice, but once made IBM felt it had to live with it. Depending on which interfaces are used to create directories within the root file system, the new directory inherits its parent’s authority. Therefore, *ALL tends to get propagated throughout the IFS directory structure.
Nowhere is this more evident than in the web application-related resources directories typically stored in the /www/* directory structure. I typically find that these resources are PUBLIC *CHANGE or *ALL. Most of the files in those directories need only be authorized to end users of the application with PUBLIC being *EXCLUDE. Many applications run under a service profile, QTMHHTTP for example. Only the service profile needs authority to anything in the directory structure containing the resources for that application. PUBLIC can and should be *EXCLUDE!
Authority collection can be used to find and verify the objects associated with a web-application and whether only a service profile needs authority to those objects.
For more information about the function, see Chapter 10 of the V7.3 Security reference manual.
The Caveat
To make the best use of the tool you need to understand the ins and outs of all of the access control mechanisms in the IBM i OS. As such, it will be difficult for the average IBM i system administrator to exploit the information generated by it.
The Bad
At the beginning of the article, I said that the authority collection function isn’t a silver bullet and that this isn’t a problem with the function itself. Now I’m going to explain what I meant.
Any End User Authority Is Bad
Any time an end user is authorized to an object, the user can access that object through any interface. When a user runs the payroll application, for example, the application will need to read the employee salary file. You can configure access control such that the end user has *USE to this file and you will be certain that the payroll application will not fail due to insufficient authority.
End User Authority is one way to be certain applications won’t fail. It is, however, the riskiest way.
If you use the “end user authorization” approach, in order to prevent end users from actually seeing everyone’s salary you have to figure out how to prevent them from using any and all of a myriad of different system interfaces, both local and remote.
This is a ton of extra work and requires in-depth knowledge of all interfaces, both previously existing and new. Ultimately, most administrators decide that this is too much work. They accept the fact that anyone authorized to run the payroll application is capable of seeing everyone’s salary.
If this were the only way to ensure that appropriate end users can successfully run the payroll application, organizations would have to accept this risk. But consider these facts:
- End users don’t need direct authority to objects that are accessed by applications they run.
- Most end users should access objects ONLY via applications they use.
- Revoking explicit and PUBLIC authority to application objects is the only foolproof way to ensure that end users can only access objects indirectly through the applications they use.
So, my concern is that the STRAUTCOL function indirectly reinforces the invalid assumption that end users must have authority to application objects. This assumption causes organizations to accept more risk than they need to.
Why End Users Don’t Need Authority to Application Objects
Whenever we talk about authority we usually say something like “the user needs to have authority.” But this isn’t really how the system determines whether an attempt to perform an action on an object should be allowed.
It’s not the user who starts a job that needs authority; it’s the job itself that needs authority!
This may seem like a small distinction, but it isn’t.
A job derives its authority to an object from the authority of a (potentially numerous) number of user and group profiles associated with the job that may have authority to the object. In addition, the object’s default (i.e. PUBLIC) authority is also available to every job on the system.
A user or group profile has some amount of authority to an object if the profile has *ALLOBJ special authority or if it is:
- The object’s owning user profile.
- The object’s primary group.
- A user profile for which a private authority to the object has been granted.
- A user profile for which a private authority to the authorization list that secures the object has been granted.
- A group profile(s) for which a private authority to the object has been granted to the object
- A group profile(s) for which a private authority to the authorization list that secures the object has been granted
The job’s derived authority is compared against the authority required to perform the requested operation on the object.
The system uses an algorithm that looks – in a very specific order – for any authority these profiles may have to the specified object. If any of the non-adopted profiles has any type of authority to the object, the system compares the authority it found to the authority required to perform the requested operation. If the found authority is equal to or greater than the authority required to perform the operation, the system continues with the operation. If not, the system checks if any of the adopted user profiles has sufficient authority. If so, the system continues with the operation. If not, the system issues an authority failure and does not perform the requested operation.
Home Grown Verses ISV Applications
Practically speaking, the ability to remove all authority to application objects is only available to home grown applications. While the technical ability exists for end users to change an ISV application to use adopted authority, it is highly unlikely that administrators will know enough about the architecture of the application to make these changes without possibly affecting the explicit application level authorization checking.
This limitation doesn’t exist for home grown applications. The best case scenario is for the development team to learn about and exploit adopted authority and/or user and group profile manipulation within the job. Developers know the details about the architecture and are thus able to do the implementation much faster. Administrators can take the lead, but it will probably take them longer to implement the changes because of the need for development input.
What Administrators Should Focus On
What all this means is that user profiles for the majority of end users don’t need any authority to objects manipulated by applications.
Administrators should instead focus on how to make sure the JOB has the appropriate authority rather than end users.
Adopted authority works for non-IFS objects and can be managed by the administrator with little or no input from developers. There are several APIs that developers can use to manipulate the user and group profiles in the job. The APIs work for both IFS and non-IFS objects and require much less effort to use than leaving it to the administrator.
For more detail on why and how jobs can control authority to objects, read Access Control: What Most Developers Don’t Know Can Compromise Security and its companion piece Howdy, Partner! The Role of Application Developers in IT Security.
Other Reasons Authority Collection Isn’t a Silver Bullet
IBM appears to have done a great job implementing the new authority collection function. There are a few limitations and drawbacks, though.
According to the V7.3 Security Reference manual, authority collection has the potential to significantly impact performance on a production machine. If authority is collected for too many users or too many objects at one time, performance on the production systems could become an issue. At this point, it’s not clear if there is any way to estimate the magnitude of the impact. Therefore, IBM suggests running the tool on a test partition. Of course, not every shop has a test partition or can quickly and cheaply create one.
[04/19/2016 Update from Jeff Uehling IBM i Chief Security Architect:]
For a specific user, the performance impact will be only in the 2%-3% range. This testing was done on large and small systems on a CPU with 90% utilization testing and a very large workload.
Similarly, the Security Reference manual warns that authority collection can potentially use up a lot of disk space. Again, it’s not clear how one can estimate the amount of disk space that might be used. Some administrators will not take the chance of using too much disk space, even though diligent monitoring of space being used can help you reduce the risk of running out of disk.
[04/19/2016 Update from Jeff Uehling IBM i Chief Security Architect:]
Once information is collected for a single user, the amount of disk space used by authority collection for that user stays fairly constant (using DETAIL(*OBJINF) parameter, the default on the STRAUTCOL command) even if the user runs the same application over and over.
The Security Reference manual is, perhaps, a bit too pessimistic in its warnings to consider using a test partition. But it does cover IBM’s butt. The message is “don’t turn on authority collection for all users for all objects at one time!” Be a bit judicial in the selection of the objects for which you collect data. Run STRAUTCOL against a single user that represent a group or class of users who all need the same authority. Delete the authority collection information (DLTAUTCOL command) once you have analyzed it. Consider moving the authority collection information to another system before analyzing the data. Do this by copying the information to a regular *FILE. For example:
CREATE TABLE MYLIB.MYFILE AS
(SELECT * FROM AUTHORITY_COLLECTION) WITH DATA
You can then move the data to another system for analysis.
IBM introduced the authority collection function in V7.3. It has the potential to be a great tool to help security administrators manage access control for objects on their systems.
The people who will be able to exploit the function to the greatest extent are those who understand the authority-checking algorithm and the notion that a job requires authority to objects accessed within that job. They’ll be able to use authority collection to implement, debug, and verify access control schemes that minimize the authority required to ISV application objects, and eliminate authority to home grown application objects.
I fear, however, that because the authority collection function tells you “how much authority” is required for an end user to access an object, many organizations will continue to be unaware of the option to potentially eliminate authority to the employee payroll file.
