Do vendor's have access to the WLM implementation that allows TCB's to run on a zIIP? Since JAVA was implemented starting with z/OS 1.11, I suspect they may use SRB's otherwise they could have easily retrofitted it to earlier versions.
As for the risk, an SRB can use cross memory facilities. It can schedule an SRB to another address space and attach a subtask. These are all well documented, known and used. These alone would let you do file I/O and mimic any active user. Lesser know would be some of the key system addresses which can easily be replaced while running in key 0. This is exactly where a hacker would want to be in order to hide their tracks and do devious things without getting caught. Jon Perryman. >________________________________ > From: Itschak Mugzach <[email protected]> > > >SRB mode is only needed if you use IBM's supplied API to zIIP. WLM is the >part of z/os that schedules the TCB/SRB to the a proccessor and there is a >know-how to do this, and indead requires deep knowledge of mvs interfaces >and assembler coding. >THe SRBs scheduled on the zIIP (using IBM's supplied interfaces) are >running in the same address space, so it minimize the risk. SRB mode is >also disabled for IO, so you can't infect other libraries / files like a >virus. > >ITschak > > >On Sun, Nov 3, 2013 at 7:41 PM, Jon Perryman <[email protected]> wrote: > >> I suspect we need an SRB that is non-authorized and can never get into an >> authorized state. I hate giving auditors information with which they can >> abuse us but this probably needs to be discussed. By making zIIP so cheap, >> IBM and customers are strongly encouraging us to offload as much work as >> possible onto zIIP. Products that never needed APF authorization may be >> forced to become APF authorized. Some of our code that we ran in >> unauthorized tasks will probably move to SRB's. >> >> JAVA is a good example. IBM created "zAAP on zIIP" in z/OS 1.11. I believe >> that zAAP is accessed through a TCB which is not running authorized. With >> zAAP on zIIP, they must be using SRB's. Some of that JAVA program must be >> running in SRB mode (unless only interpretation occurs on the zIIP and >> execution is in the TCB).. A hacker can potentially create JAVA code that >> runs in SRB mode to take advantage of the authorized state. Something as >> simple as overlaying storage could create a security exposure and give them >> access to the authorized state. >> >> Jon Perryman. >> >> >> >> ----- Original Message ----- >> > From: Peter Relson <[email protected]> >> > >> >> SRB's are a big security exposure so customers are unlikely to open them >> >> to their programmers. >> > >> > SRBs are the same level of security exposure that APF-authorized tasks >> > are. So if an application is already APF-authorized, switching to enclave >> > SRBs is not intrinsically more of a security exposure than already >> > existed. It is true that SRBs are more likely to tend to be key 0 than >> > authorized tasks, but that is not a security exposure. That is a "greater >> > potential for screwing up a system due to overlay of something critical" >> > exposure. >> > >> >> Is the code that runs under the ZIP and ZAP >> >> process code that normally run without any privileges in a problem >> >> state? >> > >> > Only if the perpetrator is irresponsible. It is far from unheard of to >> > have to take an application written to be unauthorized and make it >> > authorized. But if anyone thinks it is as simple as changing the linkedit >> > characteristic to AC=1 and placing it in an APF-authorized library, then >> > they need to be re-educated (and quickly if they're the one responsible >> > for the implementation). >> >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: INFO IBM-MAIN >> > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected] with the message: INFO IBM-MAIN > > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
