This started as me being surprised that Cobol and PL/I now support Dynalloc because of the security risks. I satisfied that it exists and for whatever reason, it is no longer considered a security exposure. My apologies for allowing this to drag into a discussion about security theory in this group. Most security breaches need multiple exploits on MVS. Often, eliminating a single exploit is enough to to stop that particular breach. SAF (RACF) secures resources but there will be always be exposures (e.g. A security admin can't possibly analyze every single resourse - more often it's a best estimate and experience). Open for dynalloc datasets is the same as a permanent dataset. This is not the exposure I'll try to explain it again for those who are interested. Here are the attributes of the exposure again:1. You must be an employee because you need inside information. (They know many things processes and general security to avoid getting caught).2. The dataset is protected where they can't get read the file. Or they want information from a database that is protected. They cannot get to it from their userid.3. The first thing to exploit is run the program under a different userid that has authority. This is easily accomplished by moving it to production or having another employee run it (there are many easy methods to do this).4. The program has read access but how does the employee see that data? Writing to any of the permanent allocations are usually restricted and writing to these datasets will normally cause problems. The program is useless to the employee at this point.5. The program must use dynalloc to a dataset the employee can access. In cobol & pl/I, this is now easily accomplished by specifying a dataset in the program.6. Most employee's have full control for their datasets and allow anyone to allocate and write them. Or the dataset could be another production dataset. People are clever and will find ways to abuse things if they are motivated. Dynalloc can easily be exploited. It's not exploited because no one has been motivated to exploit it. Regards, Jon.
On Friday, December 22, 2017 4:54 PM, "Farley, Peter x23353" <peter.far...@broadridge.com> wrote: I think our confusion (or at least my confusion) with your statements is that in the z/OS environment (including z/OS Unix), access to ALL files is subject to SAF restrictions. Allocation by DYNALLOC may in fact succeed, but OPEN will fail if the running user ID is denied access by whichever SAF is running. Where is the security exposure then? I do assume complete and correct SAF definitions here. If your SAF isn't well set up for data safety then all bets are off. I am also assuming that the running user ID for production jobs is NOT any ordinary user's TSO ID, but the unique user ID(s) allowed only to the production scheduler software.
