On Sun, 25 Apr 2010 02:00:42 -0500 Chris Craddock <crashlu...@gmail.com> wrote:
:>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. Why is there a requirement that no authorized code could ever run in the address space afterwards? :>> >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). I don't know that it is possible to prevent (logical) APF when running in a system key. :> 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. I don't understand the insistence that the authorized program MUST use key 8 storage. Yes, some will be assigned by the system - but it need not be used. Return via SVC 3 rather than RETURN using the passed save area (which is in key8 and may have been altered). Getmain all working storage in 229/230. Etc. :>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. Not if written properly. For example, SVCs run all the time - and unauthorized code runs both before and after the SVCs do their stuff. :> 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. What would be your case? If the exits can be fooled by this, they can be fooled by other things. :> 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. If that is the case (that it is running under a special ID) then SVC screening should also be used to control the environment. :>> :>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? There is no reason to reenable APF. The code that requires authorization should already be in supervisor state thus APF is not needed. In general, there is no reason for an authorized routine to keep switching in and out of supervisor state. Yes, it should not run with key0 when not needed, but SUP state alone does not allow you to overwrite storage. -- Binyamin Dissen <bdis...@dissensoftware.com> 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
