On Sun, Apr 25, 2010 at 2:56 AM, Binyamin Dissen <bdis...@dissensoftware.com > 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. > 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. > 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. > 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. > :>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. 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. > :> 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. > > 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. > :>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) 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. 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. -- 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
