What does the CHECK_PROC_OWNER RACF Callable Service do

Products

• Top Secret

Issue/Introduction

What does the CHECK_PROC_OWNER RACF Callable Service do?

Environment

Release: TOPSEC00200-15-Top Secret-Security
Component:

Resolution

CHECK_PROC_OWNER checks to see if the calling process is the owner of a process being called. This is done in a few ways:

1) the user is superuser
2) the user's UID is same as PROCESS' real or saved UID
3) the user has access to resource SUPERUSER.PROCESS.KILL or
SUPERUSER.PROCESS.GETPSENT - depending on call being made - in the UNIXPRIV resource class.

8/8:4 on ck_process_owner really means the caller is not the owner of the process as specified on the call. The reason why the explanation is put as failing authorization for the callable service is that a superuser is always given return codes indicating that the caller is the owner, and the service is usually invoked by a superuser. But the technical meaning of the return codes is that the caller does not own the process being checked. For this call, the caller is considered a superuser if the uid (either the current or the real uid) is 0 or if the user has access to UNIXPRIV(SUPERUSER.PROCESS.GETPSENT).

Basically, the ck_process_owner call is trying to determine if the user is a superuser or has access to UNIXPRIV(SUPERUSER.PROCESS.GETPSENT). It's not really a violation. Its just trying to determine something. You may have gotten this in the past but not have noticed it.

In this case the resource the acid does not have access to is UNIXPRIV(SUPERUSER.PROCESS.GETPSENT). If you want to permit this to get rid of that event, you can, but I don't think this needs to be permitted. What is happening is the check process owner is being done to see if the calling process is the owner of the process being called. This is up to a 3 step process:

- The first is to see if the user is a superuser, which in this case it is not, so the second check is done.
- The second check is to see if the user's UID is same as the PROCESS' real or saved UID, which in this case it isn't, so the third check is done.
- The third check is an authorization check based on the request type.

In this case the request type is 3 (determined from the line: Signal code : Signal n/a for type 3 (getpsent) requests in the TSSOERPT event), so the check is done for UNIXPRIV(SUPERUSER.PROCESS.GETPSENT). If this check is successful, the caller is treated as a superuser.