ESG Security, CBT tape 429 file 165 - archived project
I was trying to get the ESG security system from CBT tape 429, file 165, ported backlevel to the VS2 (MVS38J) level. It isn't easy, it seems to have been written for MVS/XA or above.
Since I started working on this RAKF (the VS2 security implementation that was previously locked away so only registered users of the yahoo groups hercules os390 section) was placed on the latest CBTtape. So I have stopped work on my solution and implemented RAKF instead. So my work here is only if anyone wants to see my last known state.
The main purpose of this page is just to archive the current state I managed to get to in case I need to revisit this code later... I learned a lot more about how things hang together than just installing RAKF would have, so I guess I was lucky RAKF was unavailable for such a long time :-).
My only complaint about RAKF is that instead of implementing ICHRTX00
to be called via ICHSFR00 as it should be it just replaces ICHSFR00
with the functions that ICHRTX00 should provide, that may limit
extention of functions; I was trying to build the entire chain
of calls that should be there (the SAF vector table as designed
allows the SAF router to call three other exits as well as ICHRTX00
so any additional functions will have to be implemented directly
into the RAKF ICHSFR00 (which is the modified for MVS3.8J ESG ICHRTX00)).
But RAKF works now, so I have implemented that.
You should as well if you want a working security product.
Current ESG functionality provided so far by my mucking about
- TSO logons use the userid/password combination provided by the esg system, sys1.uads is ignored
- Authorised terminals, TSO logons can be restricted so users (or groups of users) can only logon using specific CUU unit addresses
- TAPEVOL restrictions are in place. Groups can only use specific tapes.
- DATASET rules do not work yet.
Dataset open,scratch,rename all seem to take different paths through (or bypass) the security chain (See the issues section below).
Also protect by default was never an option for VS2 so new datasets created do not have the RACF protect flag set. - DASDVOL restrictions are not implemented (thats in the really hard basket, not even RAKF provides this)
Future changes planned in this space
As RAKF does provide most of the functionality I need the only additional code that may be linked from this page one day is
- implement the SAF vector table ICHSEC00 and the router ICHSFR00 again and chain to RAKF modules via ICHRTX00 as that is the correct way of implementing it, and will once again allow me to link my own modules into the chain (RAKF replaces ICHSFR00 with the code that should reside in ICHRTX00, preventing any other security product hooks may seem more secure but it is not how the OS was designed)
- get the DASDVOL rule working one day, a long term project. My last attempt resulted in NIP (nucleus initialisation program) being able to load the OS, highly irritating is that most of the OS modules used for I-O are required to be used before the OS is in a state where it can even report that RAKF is not yet initialised which results in such oopsies
Major changes required to get ESG working on VS2
Well I said it was very time consuming, this is what has been done so far.
- VS2 without RACF does not initialise the SAF vector table, ICHSEC00 is basically a dummy iefbr14. Have written my own ICHSEC00 program (it will prompt for Y/N to proceed so a N will leave you with a normal VS2 system) which will create and initialise the SAF vector table if the required modules are in LPA (MLPA). We will not discuss the time I spent researching how to make sure a module was in LPA instead of just being able to be located on disk via a linklist chain; OK it took a while, but done. This module is complete.
- VS2 does not implement the SAF router ICHSFR00, so I wrote one. It is definately not bug free (but will not crash) in that if it is triggered without a SAFP work area provided to it, it will getmain a dummy one to pass to ICHRTX00 (and of course free it afterward) which allows the routines to keep working. But I think I may have to investigate if list format passes different pointers to whatever that other format was. See the current issues section below.
- Dummy RACF pre/post exits have been implemented. Not sure if they are being invoked but put in there anyway.
- All the ESG code to install modules via SVCUPDTE (which does not exist in VS2) have been assembled as standalone modules installed into the SVC tables via the MLPA option
-
The ESG code installed a RCVT and hung mempory chains (UIDS/PROF)
off it with no way apart from IPL of getting rid of it...
I have implemented a started task program to create the RCVT table. The origional CJYRPROF/CJYRUIDS programs can still happily build there memory chains off this RCVT. My modifications here, that I think are essential are simply that when the STC is shutdown it will follow the 'CJYR' chains and delete all allocated memory for those, plus delete the RCVT memory (and of course revert all the system pointers to their origional values). Or simply put, if it all goes bad security can be cleanly removed.
As an aside, when I forgot to code time=1440 on my STC and it abended with time limit exceeded, I just modified the program so on a restart it will reclaim the RCVT chain and still be able to do all the memory releasing needed; security can always be shutdown at any time when it all goes horribly wrong :-), I think I still had a todo to keep a dummy chain active so all requests are approved when I shut it down as that would be needed when diskfile flags were flicked to require security, I didn't get that far (under RAKF I have a fallback profile to allow all access which is not quite as clean but works).
Currently working with this archived solution
- user logons via TSO can be restricted to specific terminals
- The USER/PASSWORD fields if coded on JCL are being verified
- STCs are tracked as the STC user and batch tracked as the PROD user (unfortunately batch is tracked as the PROD user even if USER/PASSWORD are used on the jobcard)
- TAPEVOL rules are working to restrict access to tape volumes
Current issues with this archived solution
- TSO logon does a pre-processing step (before the user is prompted for a password) that logs a deny message; but when the password is entered logon is allowed correctly. Not a stray message to clean up, something I need to detect/handle (note:also seen intermittently with RAKF)
- Cannot find where IGGPRE00 (if it even exists in 3.8J) lives or any equivalent yet; I'm pretty sure I need something like that to make RACHECK calls for DASDVOL and ALLOCAT functions
- The PROGRAM facility is not available in VS2, not much can be done about that as VS2 just doesn't support it
- Coding PROTECT=YES when creating a new dataset has found another bug in ICHRTX00, the message triggered when tried from a batch job is unknown resource for INIT/APPL/binary-junk which is obviously wrong
-
With the RACF/protection flag set on a dataset
open requests are ignored (always allowed even
is access is set to none) and on dataset scratch it is
reported as an undefined resource
'ICHRTX00B SYSPROG /SYSPROG / -spaces- /MARK.TES'
instead of a dataset resource; so dataset handling is not
being invoked correctly... hmm
'SYSPROG/SYSPROG/DATASET/MARK.SRB.SAMPLE[.Z]' reported
PROF INVALID on renames (so renames trigger (incorrectly)
a rule but scratches do not ??)... but that was after
security was shutdown... repeatable, when the RCVT
has been deleted ICHRTX00 is still invoked...
so renames are not sent through ICHSFR00 to locate ICHRTX00
but must lookup the SAF router entry and branch directly to ICHRTX00
for rename functions, bugger when I shutdown security I
will have to update the SAF vector table to point to a
'dummy' in lpa module.
Good old IBM, implement a SAF router which all security requests are expected to go through, then code their own OS to ignore it in random cases, great. - a note on dataset checks most of my issues on dataset checks were probably because I did not realise that every dataset needed the protection flag set on. Of course if every dayaset has the protection flag set on then my brilliant idea of being able to unload all the modules as needed would all datasets to be inaccesable, so switching it off would need to become a 'allow all for every resource' rule rather than unloading the modules.
Current snapshot
My current source test code is available as an AWS tape image. Running @MIDASM will compile the load modules but refer to the @MIDDOC member on creating the required entries in SYS1.PARMLIB(IEALPA00) to actually use them.
Sample JCL to download my current snapshot is here for your convenience. Change the HLQ on SYSUT2 (and of course unit/volser). Also the assembly steps refer to INSTALL.ESGSEC.SRC so you will have to globally change references to the file in @MIDASM before you run it (read @MIDDOC, the assembly job will replace the existing dummy ICHSEC00 provided with VS2 (in TK3) so back it up (or rename it) first as you will need to move it back when you have finished playing (i really should smp the install step).
//STEPA EXEC PGM=IEBCOPY
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DSN=INSTALL.ESGSEC.SRC,DISP=OLD,
// VOL=SER=MARK28,UNIT=TAPE,LABEL=(1,SL)
//SYSUT2 DD DSN=INSTALL.ESGSEC.SRC,DISP=(NEW,CATLG,DELETE),
// UNIT=3350,VOL=SER=SRCMD1,SPACE=(TRK,(50,10,20)),
// DCB=(DSORG=PO,RECFM=FB,LRECL=80,BLKSIZE=5600)
//SYSIN DD *
COPY INDD=SYSUT1,OUTDD=SYSUT2
/*
//