RACF Security Violation by non-super user

[harryseldon]

I have a developer who's testing code that will allow him to test sftp connections and processes with his own key pair before going to production and using our official keys. For some reason, every time he tries to run a job he gets several security violations for a dataset that isn't referenced in his job or in my config files:

ICH408I USER(devuserid ) GROUP(groupname ) NAME(dev's name )
UNRELATED.DATA.SET CL(DATASET ) VOL(volume)
INSUFFICIENT ACCESS AUTHORITY
FROM UNRELATED.DATA.SET.** (G)
ACCESS INTENT(READ ) ACCESS ALLOWED(NONE )
IEC150I 913-38,IFG0194E,R0000992,*OMVSEX,SYS00001,2491,volume,UNRELATED.DATA.SET
IEA995I SYMPTOM DUMP OUTPUT
SYSTEM COMPLETION CODE=913 REASON CODE=00000038

As near as I can tell, the UNRELATED.DATA.SET is being called by COZ.LOADLIB(COZBATCH). The UNRELATED.DATA.SET is APF-authorized and also located in the linklist. I don't know why COZBATCH would be trying to call it. It's a load library for a database application we use. Since this read fails the process is given a 0255 completion code. From the logs is looks like cozsftp runs and attempts to connect but it fails to authenticate stating that the private key identity doesn't exist:

debug1: Trying private key: /u/devuserid/.ssh/id_rsa

debug3: no such identity: /u/devuserid/.ssh/id_rsa

even though the key exists and is located where the process thinks it is. I'm not sure if these are connected issues but I'm concerned about the process hitting UNRELATED.DATA.SET without any clear indication as to why. We get the error three times whenever the job is run. Does it have something to do with how I installed the product?

[dovetail]

It is difficult to tell specifically from this information which job is getting the 913-38 abend. It appears to be a z/OS Unix forked job (since the step name is *OMVSEX). So, likely the job is the IBM Ported Tools "/bin/ssh" process which is forked by Co:Z SFTP. Another hint will be if these IEC150I error messages do not appear in the COZBATCH job log (since they don't belong to that job).

If I had to guess, I would say that there is something that isn't setup correctly in your z/OS Unix or RACF(?) configuration. z/OS Unix executables are often zFS files that have a sticky bit set, so that the real executable is in LPA or Lnklst. So I am guessing that someting is opening your LNKLST concatenation, looking for a matching z/OS Unix library program, and since you have a library in LNKLST that can't be opened by this userid, you get this abend.

Since you are seeing the error three times, it could be that the error occurs when IBM Ported Tools ssh trys to run your _SSH_ASKPASS program. IBM ssh does this using /bin/sh (the shell), which has a sticky bit pointing to a LPA/LNKLST program, causing a search of LNKLST.

Get a dump for this particular ABEND (you may need to set a slip for this userid), and see what program is executing when the ABEND is issued.

As far as the key problem:

debug3: no such identity: /u/devuserid/.ssh/id_rsa

This message indicates that the current z/OS user can't open this file for reading.

Does the z/OS Userid have its own OMVS segment? and its own UID and home directory? Test that this z/OS userid can open this file:

more /u/devuserid/.ssh/id_rsa (from a z/OS shell, using the same z/OS userid).

If you run the job with -vvv, you can email us the following information and we will take a look:
- your input JCL and COZBATCH input shell script
- all of the job output
- related messages from syslog

[dovetail]

Re: z/OS Unix RACF configuration:

check "Preparing RACF" in z/OS UNIX System Services Planning (Ch 4)

[harryseldon]

I emailed a typical log your way and I have our RACF administrator investigating this as well. He said he’s not sure why the linklist is being searched when we have the Co:Z loadlib in a steplib statement in our proc. Any insight would be appreciated. It doesn’t appear that the errors are preventing the sftp client from working; I’ve had two successful tests this afternoon using password authentication. As for the keyring problems, the permissions are correct and the owner is the devid attempting to run the job so I'm not sure what's happening. Tomorrow I'm planning on testing out the RACF keystore. It should meet our need to allow developers to submit personal jobs during testing and be more secure than the ssh keys we're currently using if I can get it working. So if you can help us figure out why the linklist is being invoked with the steplib configured I think we'd be ok and could continue testing.

[dovetail]

it turns out that the problem was that the library was exported as a STEPLIB via:

export STEPLIB=xxx.yyyy

in the system login profile (/etc/profile). COZBATCH runs your script under a login profile, so it will automatically run /etc/profile and the user's ~/.profile if it exists. Since the library was in STEPLIB, it was being searched/read by z/OS Unix programs, causing the violation.

It is preferable to do this if you don't need additional STEPLIBs for your z/OS Unix scripts or programs:

export STEPLIB=none