OR….. How Jobs Get Authority to Objects
Words have consequences. Saying things like “we’re going to tighten security” or “we’re going to remove public (or default) authority” or “we’re going to remove direct access to data” will almost invariably lead to someone concluding that they will not be able to do their job.
When you talk in terms of “locking down the system,” users tend to assume that the changes you make will prevent them from doing their jobs. Their thinking goes something like this:
- “They” are going to eliminate my authority to data!
- If they eliminate my authority to data, I can’t run the applications that I currently run or do the operations I currently do against the data!
- If I can’t run the applications or do the operations I currently do, I can’t do my job!
- Therefore, I cannot allow these changes to be made. I must tell my manager these changes will prevent me from doing my job!!!
This logic is based on a single invalid assumption – a user must have authority to an object in order to perform operations on that object.
How can this be an invalid assumption when this is how we describe authorization in system administration 101?
The truth is that it isn’t the user profile per se that must have authority, it’s the job in which the access is being attempted that must have the authority!
Read the previous sentence several times. It’s important.
Give the Job Authority
One way a job can have authority to an object is for the user profile under which the job is currently running to be authorized to the object. But this is only one of the ways in which a job can get authority to an object.
So where does a job’s authority come from? Jobs get authority from one or more of the profiles associated with the job or the current call stack entry in the job. Profiles associated with a job are:
- Current user profile,
- Current group profile,
- Zero or more supplemental group profiles,
- Zero or more adopted profiles in call stack entries associated with a job.
If none of the profiles associated with the job have any authority to the object being accessed by the job, the default or PUBLIC authority assigned to the object itself becomes the job’s authority. The system compares the job’s authority against the authority required to perform the operation being attempted by the job. If the job’s authority is sufficient the operation is performed.
Current User, Group and Supplemental Group Profiles
How do user profiles become associated with a job?
At the time a job starts the current user profile is set to the user profile that started the job (or that was specified on the SBMJOB command). The current group profile, and the supplemental groups are set to those defined in the current user profile at the time the job is started.
Another common — and also invalid — assumption is that the current user and group profiles of a job are those of the user under which the job was started.
The current user and group profiles can be changed by using certain APIs in a program. There are APIs that will change all of the profiles associated with a job except for adopted profile. There are APIs that will change just the current user profile or just the current group (note that the user part of the job name will remain the original user profile under which the job started even though the current user profile is changed).. And there are APIs that will let you manipulate the supplemental group list by adding or removing some or all of the groups in the list. When these profiles are changed, they are changed for the entire job, not just the program in which the change was made.
Adopted Authority
Adopting authority is yet another way a user profile can be associated with job. Adopted authority means that the user profile that owns a program is added to the list of profiles associated with a job. Unlike changes to the current user, group, and supplemental groups, adopted authority is only valid while the program that adopts authority remains on the call stack. When a program completes, its call stack entry is removed along with its adopted user profile.
More Secure, Flexible and Easier to Manage
So there are many ways that a job can have authority to an object….. even if the user that started that job has no authority whatsoever to the object. Therefore, taking away a user’s authority to objects does not in any way mean that the user will not be able to continue to do their job.
When you think about authority in terms of the job instead of the user, you’ll have much greater flexibility in managing authority and you’ll avoid misunderstandings based on invalid assumptions about the need for a user to be directly authorized to objects.
In addition, you’ll actually improve security. Authorizing a job to an object is much more secure than giving everyone (i.e., PUBLIC authority) *USE or higher. When you grant a user authority directly to an object, you are granting them that authority independent of whether they access that object from within a program, a command, or remote interface such as FTP. They have authority all of the time. But, the vast majority of users will only access data through an application. Therefore, those users should only be able to access data through that application. By ensuring that the job has authority — rather than the end user — end users authority only exists when job itself exists and goes away when the job ends. Even if they attempt to use a command line or a remote command or SQL, they will be not be authorized to the object.
Managing a job’s authority to objects is also much cheaper than managing individual users’ (or groups’) access directly to objects. There are inherently more data objects than application objects (i.e., programs) on a given system. The overwhelming majority of users on a system only need *USE authority to programs. Due to the nature of adopted authority and the ability of programs to change the user profiles associated with a job, users need *USE authority to only a relatively small subset of total number of programs. It is certainly cheaper to manage *USE authority to a subset of programs rather than various authorities for various users to a large number of data objects.
What You Say Matters!
Instead of ensuring that users have authority, we need to think in terms of ensuing that jobs have authority. And we need to communicate this to our users in a positive way so they understand that you’re taking nothing “away” from them that they need to do their job!
That’s why whenever I start a security remediation project with a new customer, I first define ground rules for how we talk about the project with everyone else in the organization. I tell my customers to talk in terms of ensuring that everyone can continue to do their jobs while removing the capability to do things that they probably aren’t doing and wouldn’t be authorized to do anyway based on their job description.
And if anyone throws out the “If you take away my authority, I can’t do my job” objection, we tell them that we will make sure they can do their job by ensuring that their job has authority to do their job. If nothing else, it confuses the heck the out them!
