On Sat, Apr 24, 2010 at 2:17 PM, Binyamin Dissen <bdis...@dissensoftware.com > wrote:
> :> 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? It is fairly clear that it is a requirement for the OP's proposed application - else why bother with the elaborate schemes to temporarily remove authorization? He wants to run his authorized code and his client's unauthorized "exit" code within the same address space, presumably without restarting his server address space each time he gets a new client request. And since that can't be done safely, there's no point. > >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? It isn't that they MUST be. Merely that the (initially APF-authorized) application running within the address space WILL get key 8 storage for every task or step-owned low private subpool allocation UNLESS it goes out of its way to run in a system key and use only key-selectable subpools (kind of an odd exercise given they chose not to have a system key assigned via PPT, but I'll play along). However, even if it did attempt to avoid using task-key storage there would still potentially be an unknowable number of task or step owned data areas laying around in key 8. That's the deal breaker. If you let unauthorized code run within that same address space, you cannot guarantee that the unauthorized code won't be able inspect or modify the authorized application's data. In fact, it is guaranteed that the unauthorized code could do exactly that, which is by definition an integrity exposure just on its own merit. But even worse, if any of the APF application's tasks had already switched to supervisor state and continued to run during or after when the unauthorized code had been allowed to run, then there's a very high likelihood that the unauthorized code could fool that supervisor state code into violating integrity. You could do it. I could do it. There just isn't any safe way to avoid that in general. There are too many moving parts in a typical address space and not all of those parts (e.g. home grown exits and/or ISV code) are going to be in on the secret of what's supposed to be going on. Disagree if you like but you would be flying in the face of literally decades of integrity studies. While we're at it, let's not forget that (again, unless the authorized application goes out of its way) the unauthorized code is going to get control with the security identity of the server where it is running (usually some sort of production ID) Of course, that can be handled too, but the number of things that have to go just right in order for the OP's idea to work out is enormous and it only takes one slip for the whole house of cards to fall down. > :>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). Ok, then I must be dense. If you agree with this, how can you disagree with the preceding argument? -- This email might be from the artist formerly known as CC (or not) You be the judge. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
