Oh geez... On Fri, Apr 23, 2010 at 8:41 AM, Sam Siegel <[email protected]> wrote:
> On Fri, Apr 23, 2010 at 1:05 PM, Peter Relson <[email protected]> wrote: > > > By definition, the subject seems to me to be an oxymoron. > Yes exactly!!! > Yes ... I agree that the subject lines is not properly worded and is > technically incorrect ... I'm pretty sure that the intent was understood. > :) > 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. 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. > An authorized address space has JSCBAUTH on. There can be no unauthorized > > code running in such a situatino. > > Now, if you meant a space in which JSCBAUTH is not on (perhaps it was > on) > > and there are tasks that are supervisor state and/or system key and you > > want to give control to code that is problem state user key, then you > > should be using SYNCH(X). You might choose to SYNCH(X) to "yourself" and > > do a LINK(X) from there, or a LOAD / CALL or whatever. As I mentioned in > a > > post on the ADRNAPF topic, once JSCBAUTH has been turned off, you must > > never turn it back on. > > > > Yes ... SYNCH(X) this is what I'm doing after flipping the JSCBAUTH bit > off. I see your point about not turning it back on as the problem state > program may have ATTACHed new TCBs. If JSCBAUTH was turned back on then > the > TCB(s) initiated by the problem state program will suddendly find > themselves > in an authorized address space. > > Clearly this is a significant exposure. > It is really much worse than you think. There are only two cases of APF authorized address spaces (1) those with a system PSW key assigned via the PPT and (2) everything else gets the default key 8, or possibly key 9 (again via PPT). We can dismiss the first case out of hand. You CANNOT EVER run unauthorized code in an address space that has a system key because EVEN IF you are in problem state and JSCBAUTH is off, you are at most one SPKA instruction and a MODESET away from running in supervisor state. That is because each task has a PKM allowing a system key. As an editorial aside, the old trick of attaching a problem state subtask and giving it a key of 8 won't work either for a variety of reasons I can enumerate but for brevity, I won't. 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. 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. > 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. > > On a somewhat related note, although the cross-memory architecture > > supports authority-decreasing PCs, I believe it is the case that z/OS > does > > not. It cannot stop you from creating them, but you should not be doing > > so. > > > > > > Actually I was considering PC routines for the more standard perspective. > Put all of the authorized code in a separate address space and then provide > a PC routine to transfer data from a problem state program initiated in the > normal EXEC PGM= fashion. > > Or use a DATA SPACE and provide access to the ALETs via name/token service. > > Pretty much everyones advice has been to find an alternate design that does > not require loading code from an authorized library and running it in an > authorized address space. > <http://bama.ua.edu/archives/ibm-main.html> > If you keep the privileged part completely separate from the non-privileged part then you will still have quite a lot of work to do, but you are at least in with a shot of making it work out. Every other scheme that you (or anyone else) can come up with will fail. I promise. -- 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 [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
