On Fri, 19 May 2017 14:32:27 +0700, Robin Atwood <[email protected]> wrote:
>The situation would be that the client routes a command to the server on the >host which routes it to a dependent ASID. The DA gets the ACEE of the user and >executes the command via IJKEFTSR. The command is one of a suite of >Rexx execs in a library allocated to the DA which executes ISPF services (eg, >to copy some members). Without wilful >collaboration of a sysprog I am struggling to see how this could be subverted >by a malicious user. However, if you can see something >please let me know! It all comes down to the fine (and unknown to us) details of how your dependent ASID initializes, what storage key the initiator ATTACHes it in, what storage keys it uses, and how you plan to remove authorization (JSCBAUTH) before invoking IKJEFTSR. (And that you never restore authorization (JSCBAUTH) once you've removed it.) Ideally you would not run the dependent ASID authorized at all. There are at least two ways you could do that, I believe: (1) z/OS provides services via WLM that (if I remember correctly) allow an authorized server to route requests to an unauthorized servant, with z/OS managing the identity that is used for each request. (2) Using UNIX functions you could fork() a new address space to handle the request, switch the identity while still running authorized, and then execmvs() a new unauthorized program to run the request, return the results, and terminate. This does have the dependent ASID running authorized briefly, but the execmvs() takes care of cleaning things up so unauthorized code can then run safely. In any case, if you have not been running REXX execs and TSO or ISPF functions before in your dependent address spaces, you will probably have some major redesign to do in order to run them safely. And if you're going to do some major redesign you should start afresh with something that is architecturally safer, such as (1) or (2) above. -- Walt ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
