
It is possible to submit jobs to batch that will run for another user profile by using the User parameter in the Submit Job command, SBMJOB. For example:
SBMJOB CMD(DLTF FILE(MYLIB/INVHIST)) JOB(TEST) USER(SIMON1) |
The above shows that the current job is trying to submit a job to run with the SIMON1 user profile. I would consider to be a security risk. If SIMON1 has more authority than the current user, let's say that is NOTSIMON, then NOTSIMON can submit jobs that perform tasks they are not authorized to do, or do something bad that they will not be blamed for.
Fortunately in most cases NOTSIMON would receive the message:
SBMJOB CMD(DLTF FILE(MYLIB/INVHIST)) JOB(TEST) USER(SIMON1) Not authorized to user profile SIMON1. |
I have encountered various companies where all the SBMJOB commands in their programs would use a "special" user profile for batch jobs, that had more authority than the average user. In this scenario when NOTSIMON ran a program that SBMJOB, and I looked at the calling job's job log I would see something like:
SBMJOB CMD(DLTF FILE(MYLIB/INVHIST)) JOB(TEST) USER(SIMON1) Job 818168/SIMON1/TEST submitted to job queue QBATCH in library QGPL. |
The job is only successfully submitted when NOTSIMON has authority to use the SIMON1 profile.
I can check who has authority to the user profile SIMON1 using the OBJECT_PRIVILEGES table function:
01 SELECT OBJECT_NAME AS "Object", 02 OBJECT_TYPE AS "Obj type", 03 AUTHORIZATION_NAME AS "User", 04 OBJECT_AUTHORITY AS "Authority" 05 FROM TABLE(QSYS2.OBJECT_PRIVILEGES( 06 SYSTEM_OBJECT_SCHEMA => 'QSYS', 07 SYSTEM_OBJECT_NAME => 'SIMON1', 08 OBJECT_TYPE => '*USRPRF')) |
Lines 1 – 4: I think the columns' name explain what is in each column. I have added column headings to make the results more easily to fit on this page.
Lines 6 – 8: These are the parameters of the OBJECT_PRIVILEGES table function. I have passed to it the library where user profiles are located, QSYS, the name of the user profile, and the object type I am looking for is a user profile.
This returns:
Object Obj type User Authority -------- -------- -------- --------- SIMON1 *USRPRF *PUBLIC *EXCLUDE SIMON1 *USRPRF SIMON1 USER DEFINED SIMON1 *USRPRF NOTSIMON *USE |
The last result show that NOTSIMON has the authority to use the profile SIMON1, which is enough to use SIMON1 when using SBMJOB. Having found this, I would remove NOTSIMON's authority to use SIMON1. But, if this change had gone unnoticed, NOTSIMON could wreak havoc on this partition.
In IBM i 7.6 a new function usage, QIBM_RUN_UNDER_USER_NO_AUTH, was created to deny anyone from using a given user profile in this way. Its default is to allow an user profile to submit a job for another, if it has at least use authority to the second user profile.
I can check which profile are blocked as denied by using the FUNCTION_USAGE view:
01 SELECT * 02 FROM QSYS2.FUNCTION_USAGE 03 WHERE FUNCTION_ID = 'QIBM_RUN_UNDER_USER_NO_AUTH' |
There results are:
FUNCTION_ID USER_NAME USAGE USER_TYPE --------------------------- ------------ ------ --------- |
With no entries this means there is no blocking.
I use the Change Function Usage command, CHGFCNUSG, to add an entry for SIMON1:
01 CHGFCNUSG FCNID(QIBM_RUN_UNDER_USER_NO_AUTH) + 02 USER(SIMON1) + 03 USAGE(*DENIED) |
Line 2: User profile SIMON1...
Line 3: Will be denied by QIBM_RUN_UNDER_USER_NO_AUTH, which means that no-one else can SBMJOB using this user profile.
I want to check that this entry was added:
01 SELECT * 02 FROM QSYS2.FUNCTION_USAGE 03 WHERE FUNCTION_ID = 'QIBM_RUN_UNDER_USER_NO_AUTH' |
It was added successfully, see below.
FUNCTION_ID USER_NAME USAGE USER_TYPE --------------------------- ------------ ------ --------- QIBM_RUN_UNDER_USER_NO_AUTH SIMON1 DENIED USER |
After this when NOTSIMON tries to SBMJOB with SIMON1 I will see the following in NOTSIMON job's job log:
SBMJOB CMD(DLTF FILE(MYLIB/INVHIST)) JOB(TEST) USER(SIMON1) Operation not allowed for user profile SIMON1. Not authorized to user profile SIMON1. |
The first of those messages is new with the addition of this function usage. When I look at the message's details I see:
Additional Message Information Message ID . . . . . . : CPF4AF1 Severity . . . . . . . : 40 Message type . . . . . : Diagnostic Date sent . . . . . . : DD/DD/DD Time sent . . . . . . : TT:TT:TT Message . . . . : Operation not allowed for user profile SIMON1. Cause . . . . . : User profile SIMON1 is denied access to the QIBM_RUN_UNDER_USER_NO_AUTH function usage ID. The user profile is not allowed to be the target user for the requested operation. Recovery . . . : Use an alternate operation that does not require access to the function usage ID or remove the user profile from the QIBM_RUN_UNDER_USER_NO_AUTH function usage list and retry the request. |
Having discovered this I have added my own profile to QIBM_RUN_UNDER_USER_NO_AUTH, as denied, on the partition I am using to write these posts, to ensure that no-one else can use it. This is another excellent addition to the security enhancements of IBM i 7.6 .
You can learn more about the QIBM_RUN_UNDER_USER_NO_AUTH function usage from the IBM website here.
This article was written for IBM i 7.6, and will not work on any earlier releases or TR.
No comments:
Post a Comment
To prevent "comment spam" all comments are moderated.
Learn about this website's comments policy here.
Some people have reported that they cannot post a comment using certain computers and browsers. If this is you feel free to use the Contact Form to send me the comment and I will post it for you, please include the title of the post so I know which one to post the comment to.