On Fri, 23 Apr 2010 11:37:28 -0500 Chris Craddock <[email protected]> wrote:
:>Actually I am not sure that the intent is understood. Peter is correct. :>Unauthorized code MUST NEVER be allowed to run within an authorized address :>space. *ALL* of the schemes being thrown around that involving turning off :>JSCBAUTH and SYNCHing or ATTACHing the unauthorized code will DEFINITELY :>fail the integrity rules. So you believe that CICS fails the integrity rules? :> There is no way to dance around it or pretend :>otherwise. The only way you could avoid the exposure would be to guarantee :>that no authorized code code could ever run within the address space after :>you have allowed the unauthorized code to run. There is no way to guarantee :>that in general and in any case, it would effectively eliminate the value of :>that address space as a server for hosting this function. Why this requirement? :>The only case that leaves open is a garden variety key 8 APF authorized :>address space. If you turn off JSCBAUTH before invoking the unauthorized :>code, then it is true that code would NOT be able to MODESET to a system key :>or get into supervisor state while it is running, however that isn't the :>only exposure. While they are running, they can easily diddle with the data :>belonging to the other tasks providing the privileged application :>functionality in that space. Most of the system owned data areas will be key :>0, 1 or 5 (and thus whey would be safe) but most of the areas owned by the :>worker tasks will be in key 8. All of those areas would be susceptible to :>modification by your unauthorized code when it runs. If such a modification :>occurred and ANY privileged code continued to run, their data would :>potentially be invalid and that is an integrity violation in and of itself. :>Beyond that, a little creativity would get your unauthorized code back in :>control in a privileged condition - thus violating integrity. Why must the authorized work areas be in key 8? :>Removing authorization must therefore be a complete one-way trip :>because other tasks in the address space may have already switched into :>supervisor state and be running independently of your unauthorized code. I :>am deadly serious about this. If you (knew enough to) "do the thought :>experiment" you would soon realize that there is literally no way to prevent :>these exposures. Abandon hope. False. :> Abandon hope. It won't be easy. :>> Now a question about TCB creation. After control is returned from the :>> problem state program to the caller, it should be possible to see if it :>> ATTACHed any new TCBs. If new TCBs were created, I could abend the entire :>> process instead of flipping the JSCBAUTH bit back on. This would ensure :>> that when the user exit returned to the caller, none of the problem state :>> program code was running. :>> If this was true, would it be acceptable to turn the JSCBAUTH bit back on? :>No. Not ever. Just abandon hope. This idea is just wrong. All of the :>integrity corner cases have been studied for decades. There is just no way :>to do it safely without making a one-way trip and guaranteeing that no :>privileged code ever runs again. That I agree with. You cannot safely reenable APF (and there should never be a reason to). -- Binyamin Dissen <[email protected]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
