We all know about special authorities, right? Defined by the IBM i operating system, they include *ALLOBJ, *AUDIT, *JOBCTL, *IOSYSCFG, *SAVSYS, *SERVICE, *SECADM and *SPLCTL.
A few months ago I wrote about a set of IBM i APIs and commands that allow you to define ad hoc special authorities in your programs. That post focused on the actual commands and APIs, and you might have been left thinking “Yeah, but why would I want to do it that way?”
There are several advantages to using “system-supported” special authorities, primarily due to the fact that the operating system does a lot of the work for you and provides administrative interfaces so system administrators can assign and revoke authorities.
Traditional DIY Special Authorities
Applications have been defining their own special authorities on IBM i for years. It’s typically accomplished by developers defining a table with rows of users and columns representing different functions provided by the application. Some sort of menu-based interface is usually provided to system administrators to grant and revoke the ability for a user to the various functions. Underneath the covers, granting the special authority is represented by a ‘1’, or ‘*YES’ and revoking or the absence of the special authority is represented by blank, ‘0’ or ‘*NO’. The column description, in effect, is the name of the special authority being managed. Once the table exists, developers use standard database programming interfaces to check if a user should or should not be allowed to execute a given function of the application.
While this model isn’t completely horrible with respect to security, it does have some real disadvantages.
Security
Since this model implements an important security function, you would rather the system provided standard interfaces for managing it. When this function is implemented at the application layer, the data is accessible by user state programs. This makes it easier for attackers to avoid detection when manipulating those values. Unless you have object auditing turned on and are closely watching the audit journal, you are unlikely to detect these attacks.
If you rely on the system to implement this function, the data is stored in system domain; only system-provided interfaces can be used to manipulate these values, and that provides a higher level of protection against attackers.
Auditability
In addition, when this function is implemented at the user application level, system auditing does not specifically audit the security function. It can only audit operations on the file and the data, making it harder for a non-developer to ascertain who made which changes for which user. If the operating system implemented these functions, it would provide a full audit trail for all operations associated with creating, managing, and checking for ad hoc special authorities.
Efficiency
Another problem with the DIY model is its inefficiency. Developers must implement this same capability for each new application.
All of these problems are addressed by “Function Usage,” the system-supported Special Authority capability provided by IBM i beginning around V4R3 or so.
How System-Supported Special Authorities Work
To show you how to “define your own special authorities,” I’ll first describe it in terms of ad hoc special authorities without naming the actual APIs and administrative command interfaces. As before, I’ll use a simple, fictitious banking application as the example to describe what developers need to do and what system administrators need to do – and WHY.
In our example, tellers can accept deposits and make withdrawals for amounts less than $10,000. Only teller supervisors can perform these transactions for amounts of $10,000 or greater.
Developers define two ad hoc special authorities to control this: banking-app-teller, and banking-app-teller-supervisor.
The bank’s security officer also wants to make it harder for system administrators (who have *ALLOBJ special authority) to use the banking application without management authorization — and easier to detect if they do. Developers identify a new ad hoc special authority for this called banking-app-user.
The security officer is aware that someone with *ALLOBJ authority can easily grant themselves banking-app-user, but because the system’s GR audit journal entry tracks all ad hoc special authority operations — administrative and operational — in the GR audit record, she feels that it will be easier to detect a system administrator attempting to use the banking application without management approval.
Early in application development, developers use the create ad hoc special authority API to define the ad hoc special authorities to be used by the application. In our example, these are:
- banking-app-user
- banking-app-teller
- banking-app-teller-supervisor
In each separate program of the banking application, including the initial program, developers use the ad hoc special authority check API to check if the user profile attempting to run it has “banking-app-user” special authority. If not, the program exits — and perhaps sends an email to the security officer that someone who shouldn’t be using the banking application is trying to. Doing this in each program prevents an attacker from bypassing the initial program by calling a different program directly.
Included in the top level menu of the application is the “Teller” menu item. Only tellers are allowed to select this option. Selecting the option produces a new menu list containing various teller options including “Deposits < $10,000” “Deposits >= $10,000” and similar options for withdrawals.
The initial program controls the initial menu for the application. When the code detects that a user has selected the “Teller” menu item, the developers use the ad hoc special authority check API to determine if the user has “banking-app-teller” special authority. If they do, the initial program calls the TellerOps program which manages the Teller menu options; otherwise control is returned to the initial application and the user must select another menu item.
In addition to checking if the user has “banking-app-user” special authority, the TellerOps program also checks if the user has “banking-app-teller” special authority, to prevent a non-teller authorized user from getting into the teller app options by calling the TellerOps program directly. The TellerOps program displays a list of menu options including those for deposits and withdrawals less than or greater than $10,000. For those options greater than or equal to $10,000, the developers again use the ad hoc special authority check API to determine whether the user has “banking-app-teller-supervisor” special authority. If not, the code ignores the selection and forces the user to select a different option.
The system administrator for the bank has decided to use group user profiles to manage the banking application and its application defined special authorities. For tellers, she creates two group profiles: tellers and tellersups. She assigns membership in these groups to the appropriate user profiles defined on the system. Then she uses the “change ad hoc special authority” command to grant “banking-app-user” and “banking-app-teller” to both groups and also grants “banking-app-teller-supervisor” to tellersups group profile only. In addition, for each of these ad hoc special authorities, she uses the “work with ad hoc special authorities” command to ensure that each of them is configured to tell the system to “not consider *ALLOBJ special authority” when it is asked to check if a user has been granted one of these ad hoc special authorities.
That’s it. The ad hoc special authorities for our example application have been created, checked, and appropriately managed.
Documentation for the System Interfaces
Now it’s time to identify the system interfaces that actually perform each of these functions:
- Ad hoc special authority
IBM calls these “function identifiers.”
There are several places to read more about Function Usage. Google “IBM i function usage” and you’ll get a list to start with. - Create ad hoc special authority API
Register Function (QSYRGFN, QsyReigsterFunction) API - Ad hoc special authority check API
Check User Function Usage (QSYCKUFU, QsyCheckUserFunctionUsage) API - Work with ad hoc special authorities / Display function usage
Work with Function Usage (WRKFCNUSG) command
Shows a list of function identifiers (e.g. “banking-app-user”) from which you can choose to display or change the attributes of the function identifier. It allows generic names so you can use:
……….WRKFCNUSG banking-app*
to display all of the function IDs/ad hoc special authorities associated with your application. - Change ad hoc special authority command
Change Function Usage (CHGFCNUSG) command
This command can be used to:- Grant and revoke “ad hoc special authority” for a specified user
- Manage whether all users on the system have or don’t have the specified “ad hoc special authority” by default
- Manage whether *ALLOBJ special authority is “used” or “not used” when the system checks if a given user has the “ad hoc special authority.”
- Display ad hoc special authority command
Display Function Usage (DSPFCNUSG) command
This command can display a list of function identifiers – much like the WRKFCNUSG command – or it can show the detailed information for a specific function identifier.
