On Sun, 25 Apr 2010 14:38:14 -0500 Chris Craddock <[email protected]> wrote:
:>On Sun, Apr 25, 2010 at 2:56 AM, Binyamin Dissen <[email protected] :>> wrote: :>> Why is there a requirement that no authorized code could ever run in the :>> address space afterwards? :>Because the unauthorized code could have modified storage and/or code :>belonging to the authorized code. Non-reentrant code (if any) will be loaded :>in job step key (8) and any data areas that are not specifically requested :>in another key will also be in key 8. Once those have been "exposed" to :>unauthorized code there's no going back. Only if the authorized section is badly written, i.e., not written for this case. That is not to say that an APF program, in general, should be aware of this - but if it is expected to run in this environment it must make sure all programs and data are in a system key. :>> I don't know that it is possible to prevent (logical) APF when running in a :>> system key. :>It isn't possible. In fact, being in a system key is considered to be :>privileged, even if you're running in problem state and with JSCBAUTH off. :>You can MODESET to sup stat in that condition. Thus that is not an option. :>> I don't understand the insistence that the authorized program MUST use key :>> 8 :>> storage. :>I'm not insisting that it must use key 8!!!! I am merely observing that that :>is the default and you can't assume that all of the code running in that :>address space will be clued in on what you're up to. If you're writing the :>mainline application code you can certainly run in a system key for :>everything you do, but running in a key that is different than the job step :>key requires exception vigilance in the choice of storage keys and subpools :>and EVEN WITH that level of vigilance, there are a lot of things that just :>don't work out. For example, any externally called code (e.g. access :>methods, home grown exits, ISV code... etc etc) that mindlessly assumes that :>it is running in a completely unprivileged environment will potentially fail :>in a variety of ways. You can't predict what assumptions that code may make :>that would be ok in a true APF environment and in a non-APF environment, but :>not both at the same time. I am curious about this exit or ISV code (that gets control authorized) will use a key8 storage area. That is an exposure by itself. :>> 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. :>Once again true in the abstract, but you can't assume everyone else is in on :>the secret. If you're mixing auth/sup code and unauth code in the same :>address space you're begging for trouble. We are discussing a case where it is designed for that. I am not suggesting moving an arbitrary APF program into this environment. :>> :>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. :>Sorry you're missing the point entirely. There is a huge difference between :>an SVC that is being called out of mainline task code maintaining integrity :>over the narrow function that it is performing and having the mainline task :>code maintain integrity over whatever it does during the life of the :>application. The SVC (or PC) is encapsulated from the rest of the logic and :>it follows the rules to the letter. It receives control in sup state and key :>zero from the OS or the hardware and it remains that way throughout. Inputs :>are checked and moved to fetch protected key zero storage, results are moved :>back to the caller's storage using the caller's PSW key (not zero) etc. It :>is a closed and bounded environment. If it needs to do something :>non-privileged, it will SYNCH to a new RB that runs that work and the system :>returns control to the SVC/PC in the same state it left. So if the SVC/PC is :>done right, the unauthorized code can't "touch" anything that its caller :>doesn't allow it to. There may be other tasks running concurrently, so it must make sure that all of its data and code are in system key. Just like this application. :>In contrast to that, the code that runs from initial startup through :>mainline operation in an arbitrary task is not closed or bounded. With :>exceptional diligence you might make it so, but even then you would likely :>be undone by assumptions made by code that you did not write that you ended :>up calling, e.g. library routines, or by other system services, exits, ISV :>code etc. etc. that you don't control and can't predict what it is going to :>do. Sorry for my lack of imagination, but I do not see the case. :>> :> 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. :>How many times does the question come up here on ibm-main about choice of :>subpools for exits, or whether exit code has to be reentrant? There are a :>huge variety of ways that authorized code can be spoofed if it makes :>assumptions about the environment that are invalid because somebody is :>trying to do something fundamentally stupid like running privileged and :>unprivileged work alongside each other within the same address space. The exit should not be making assumptions that it can safely use key8 storage if called by a supervisor state routine. That is an exposure by itself. :>> > 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. :>Maybe so, but my point is that the amount of work a developer would have to :>go through to make an application like this safe (FSVO "safe") is just :>enormous. Experienced developers will take short cuts because "it's too hard :>and it will take too long". Inexperienced developers won't even know what :>the potential problems are. Which leads me back to my original contention; :>the chances of a mixed mode application like this being done correctly are :>essentially zero. I am not disagreeing as to whether this is the best approach for a non-master programmer. I agree that this is a difficult design and you would need all sorts of weird conditions to make it be the best choice. But that does not make it impossible. :>> :>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. :>well here again you're splitting a hair that shouldn't be split. Yes, once :>you've switched into supervisor state you no longer need APF. But if you ran :>in sup state and key 8 your unauthorized code could simply find one of your :>save areas and futz with it. So you would have no choice but to make your :>privileged worker tasks run entirely in a system key (not necessarily zero) :>and as I already pointed out, running in a key other than the job step key :>causes lots of things to fail (often spectacularly) Such as? :>My bottom line and my final word on this: contemplating running mainline :>auth/sup state tasks along side of unauthorized tasks within the same :>address space will inevitably result in integrity violations. I don't care :>how clever the developer is. Arguing about all of the ways to close off all :>of the potential exposures is futile. There will be more than you can think :>of and the OP who was proposing to do this doesn't have the experience (yet) :>to even know there are exposures. Only for some values of "inevitable". :>The only rational answer is to separate the privileged functions into their :>own address space. There will still be work to do, but it will be vastly :>safer and less work than trying to anticipate and design around each :>exposure one at a time. Now I'm done on this topic. I do agree that there most likely is a better design. -- 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
