My RAKF Notes

RAKF is an implementation of the ESG security system (ESG sources are on CBT tape 429 file 165) that has been back-ported to MVS3.8J by some of the VS2 hobbiests (see credits in the RAKF file).

The RAKF security system is packaged as an SMP install on CBT Tape 486 file 850 available from cbttape.org.

As MVS3.8J does not call security by default for datasets but relies on the RACF DSCB-1 indicator for a protected dataset being used the RAKF install files provide sample jobs for globally setting that flag for VSAM and Non-VSAM datasets that already exist on your system to allow dataset security to be flicked on. When RAKF is running any newly created datasets will be created with that flag set so the global change job needs to be run only once.

The bad news is RAKF completely replaces the SAF router module ICHSFR00 rather than being correctly implemented as ICHRTX00 which is only one of the exits that could be called by the router. There are three other exits I am aware of that are documented as being available from the SAF router but implementing RAKF obviously pevents those being used. RAKF may handle requests to those in its own internal code but it does prevent any further local customisations.
I am not sure why they took that approach, as I found implementing the SAF vector table and SAF router modules to pass requests to ichrtx00 fairly trivial (ok, a bit of work, but I did it) when playing with the ESG security system on which RAKF is based. The design of the mvs3.8j SAF system is to allow 'chaining' of modules through multiple handlers, and the router should of course route. The RAKF implementation just throws a big block in the middle of the path. But while it throws a spanner in the works it as implemnted does provide the security features expected from it.

RAKF from CBT tape 486 will enforce

• Dataset access rules work (once the dscb-1 protect flag is set)
• Tape Volume access (by volser name)
• Control user access to terminals in theory (personally I only tested that with ESG)
• It uses its own user/password tables (although because of MVS3.8J design the user must also be defined to the MVS UADS via ACCOUNT, the password set in the UADS file for the user is overriden by the RAKF settings however
• It allows users to change their RAKF passwords (tested at tso logon with oldpswd/newpswd, after rakfuser was run the new password was in the rakf user table and used for logon).
  The only issue is RAKFUSER needs to be run to update the user table so would have to be scheduled in a job scheduler to run on a regular basis
• Coding of the USER/PASSWORD fields on a jobs JOB card still works (which is important, see below batch notes)
• Has a special STCGROUP for started tasks (console 'S xx' jobs) that can be used to control what datasets thay can access, you should limit access to what this group can access
• enforces what groups of users can logon at what terminals
• and not necessarily good, but makes life easier; a password is no longer needed to make updates to the master catalog entres as permission to update that is also controlled by RAKF now, although turning the RACF DCB-1 indicator for that file off should revert to the orional password prompt on the console behaviour if you prefer that but it is best to leave everything under RAKF control

The bad is that due to limitations in MVS3.8J it must assign user/group PROD/PRDGROUP access to all batch jobs. As that is a wide open hole I recomend denying the default PRDGROUP access to anything and creating a seperate batch group as discussed below.

And what I personally consider an issue is the SAF chain addresses should chain, should keep following addresses down for other handlers. But the RAKF implementation just takes them as it's own which effectively disables any user customisation that hung off there in the first place. As I was playing in that space it's not hard to kick off a task from commnd00 to fix that after RAKF has started by simply initialising the addresses properly and making the RAKF pointers the first in the chain allowing me to insert handlers before or after it; but that should not have been necessary. Later releases of RAKF to the cbttape may correct that bad behaviour.

What RAKF does not (yet) enforce

This is most likely because the usefull IGGPRE00 user exit does not exist in OS/VS2 3.8... at least I cannot find a FMID that knows about it and am still trying to find what module(s) to zap to make it look for one.

• DASDVOL rules are not enforced, zaps/changes have not been provided to allow that to be enforced yet
• ALLOCAT rules are not enforced, so users can create datasets on any volume they want

My solution to the above two issues is to run a batch job every hour to move (by prefix) any datasets on incorrect volumes onto volumes users should have been using (see my mdmoveds program also available from this site to see how I do that).

What it has trouble enforcing, batch jobs

Basically started tasks and batch jobs are difficult to enforce due to the design of MVS3.8J; it was never really designed with security in mind.

Firstly userid propogation was never implemented in MVS3.8J, so for batch jobs submitted from TSO (or RPF) RAKF will assign them a default user/class of PROD/PRDGROUP within the RAKF security code as the userid is not passed downward. And of course batch jobs submitted via a card reader have nothing to propgate downward anyway.
If you want to use RAKF for security you need to deny all access to those defaults and ensure all batch jobs submitted via card reader use a userid/password plus For TSO SUBMIT (also used by RPF) the RAKF documentation recomends the IKJEFF10 exit on CBT tape 249 file 358 which will insert the user=/password= fields into jobs submitted from TSO or RPF. I have installed that and it works correctly..

My personal solution to this issue which I believe does enforce security was to do the below. You may want to take a different tack but this works for me. Basically I use the profile rules to give the default batch PROD/PRDBATCH group/user used by all batch jobs no access to anything. Then...

1. create a userid/password using normal tso 'account' for a batch user
2. add that user to a new 'batch' group in the RAKF user table
3. give the newly defined group access needed for production batch in the RAKF profile rules, update access only to the datasets I know it will update
4. give the new batch user(s) a TSO logon clist that just issues a logoff if that user is used to attempt to logon to TSO (actually when I tested that I discovered I had locked down the terminal rules so the 'batch' user was not authourised to use any terminals, even better)
5. and the key reason this worked for me was that all of my daily and on-demand batch at that the time I installed RAKF were submitted via a 'S JOBDECK,J=xxx' PROC that just used IEBGENER to copy/submit the jobs to INTRDR, I didn't want to hard code user=password= in all the batch jobs so I did the following to get things working with the new batch userid without having to modify any of my batch job decks
   • wrote a JOBCONT program that would append any parm passed as a continuation card to JOB cards, which in this case was the USER=/PASSWORD= fields needed for a batch job
   • changed the JOBDECK PROC to use JOBCONT instead of IEBGENER, and moved the JOBDECK PROC to a proclib RAKF would only allow STCGROUP read access to so only stcgroup (oh ok, and my admin group) could read the user/password data
   • and one day later... wrote a JOBCONT2, the same purpose and syntax but handles multiple jobcards in the input stream (I had a daily trigger that submitted multiple batch jobs using DD concatenation so had to allow for jobcards anywhere in the input stream instead of assuming only the first card was a job card)

Of course as the default batch class now has basically no access anymore it does mean that individual users wanting to submit jobs also have to now code their personal user/password on their JOB cards.
For TSO SUBMIT (also used by RPF) the RAKF documentation recomends the IKJEFF10 exit on CBT tape 249 file 358 which will insert the user=/password= fields into jobs submitted from TSO or RPF. I have installed that and it works correctly.
So only jobs submitted via INTRDR (which I can control via the steps above) or card readers which are uncontrolled need the user/password= coded on the job card as it is done magically for TSO users if you install the above exit.

Miscellaneous

MVS3.8J really was not designed for security, apart from the APF functionality to restrict who can make priviledged calls.

For example pretty much all my automation tools use SVC 34. I did briefly consider consolidating all the SVC 34 (issue console commands) issued from quite a few of my tools into one shared module that all my programs that use that functionality could share... and bung a racroute request for auth into it; until I realised (a) I would have to bundle that module into every application source file and (b) it wouldn't stop anybody writing APF code calling SVC 34 that didn't use that module anyway.
As RAKF can be used to control who can update files it's more effecient to just control access to SYS1.PARMLIB to stop users creating APF authorised files.

On the bright side

I have created a couple of test jobs to test "ALLOCAT" even though I cannot figure out which module to zap them into, and it does show that it is easy to create new resources in the RAKF profile and check for them.

Other options for security

I had started working on back-porting the ESG security system (ESG sources are on CBT tape 429 file 165) to MVS3.8J myself before RAKF became available on the CBT tape, as RAKF used to be only available from a closed yahoo group file section. Even though RAKF is based on the ESG code they took the approach of replacing the SAF router ICHSFR00 with the code that ESG had in the ICHRTX00 exit.

I was taking a different approach, I was trying to replace the entire chain of missing modules and exits (those in XA but just stubs or missing VS2), for example I implemented a ICHSFR00 router and used that to route to the ESG ICHRTX00 as ongoing I hoped to get all the other hooks also called from the SAF router working as well. But I only had it partially working, quite a few more months work in my spare time to get that completed (although I believe my only remaining issue was I did not realise you had to switch on the RACF protection flag on datasets for 'dataset security' to get involved). As RAKF does what I need and the install jobs do provide a batch job to turn the RACF protection flag on for every dataset I have stopped playing with my investigation of the ESG code and am using RAKF now.

The main difference between my work on the ESG code and RAKF is that my approach was that it loaded correctly by chaining into the SAF chain router path (admitedly I had to create the SAF vector table and the SAF router to get to the point of chaining to the security module ichrtx00, but I did it) rather than just replacing the saf router as rakf did (which is bad as the saf router is also intended to route to at least three other exits I am aware of other than just the security module ichrtx00), which also had the benefit that it could be cleanly unloaded as well. Now I am aware that it (and RAKF) can only manage datasets with the protection flag on I have a suspicion that being able to 'unload' from the SAF chain will cause access issues to datasets with the protection flag set on.
That does not mean I agree with the way RAKF was implemented to simply trash/replace the SAF router module ICHSFR00, as there are probably many applications on CBT tapes that expect the router to function and I was planning to chain in a few of my own (for logging etc of course, nothing nefarious), but the routing chain should exist and RAKF trashes it.

My last snapshot before I archived it is available it you want to play with it; I may revisit this in the (far) future as going forward I can make more enhancements here, but I have archived it for now.