> -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Knutson, Sam > Sent: Monday, August 21, 2006 10:09 AM > To: [email protected] > Subject: Re: Back Doors > > Hi Rick, > > I agree with the premise "Good tight security DEMANDS both technical and > managerial participation.". > > I don't know any of the major software vendors that would be willing to > supply source code for OCO parts including SVC's and if they did of what > use it would be? Auditing and understanding the authorized parts of > large OEM products would quickly become a career perhaps even an > adventure ... "You are in a maze of twisty little passages, all alike" > :-) Escrow agreements are one thing forking over the family jewels for > inspection by persons unknown at a customer site is another. As an > aside escrow for authorized vendors tools of any size is IMHO a waste of > time since the escrowed code doesn't come with a fully staffed > development lab, tools, build and test environment it is just a tourist > postcard not worth much in the real world.
I've seen authorized ISV code violate basic system security principles. Example: an ISV user SVC routine that looks at the caller's register R0 for a magic value and the PSW return address pointing into common storage; the SVC sets the caller's RB to supervisor state and returns. There is also extreme misuse of secondary address space mode, because most developers are completely unaware or uncaring about the IBM rules for cross memory addressability. The ASN-and-LX-Reuse facility may help to identify some problems, but certainly not all. When I point out gross errors like that to the "product author", the response is: (1) they didn't understand exposure, and (2) their product was too far into development to change it, and (3) if the customer doesn't know about it then it won't hurt them. > Most vendor code today > requires only an APF library and dynamically install mechanisms perhaps > PC routine(s) to provide entry into the vendors authorized services. > Private SVC's are not much of a consideration and SVC's can be installed > dynamically (and are) without your explicit permission or configuration. As indicated a few weeks ago by another poster, unless an SVC is needed by all address spaces, then it may be better to use a set of PC routines with limited address space connections. > ISV's dynamic hooking practices have been the subject of discussion here > before. Dynamic hooking of system services by several ISV products indicates a general need for front-end/back-end processing that should be formalized by IBM. > The good news is that generally the folks providing these parts > are old and capable hands. The bad news is this is not always true and > some irresponsible choices have been made by some vendors in order to > ship new function or save development costs which would be incurred to > implement infrastructure properly. If customers had access to the authorized source code and knew what they were looking it, then most of the time they would be appalled. The really sad part is that the developers that write that kind of code either don't know or don't care about the security issues. > > The bottom line is that you place as much trust in any vendor as in IBM > once you install their products in an APF library. There are few guidelines from IBM on how to write a secure authorized routine. The chapter in the authorized programming guide about user SVC routines just scratches the surface, and its remarks are not replicated over in the discussion on PC routines, which are outpacing user SVC routines. > It is hard enough to properly secure z/OS and harder still with just a > limited set of IBM core components. It takes a small miracle to hold > the line on security and integrity after throwing in a hundred vendor > products which run APF. The tome "Close Look at MVS Systems: > Mechanisms, Performance and Security" by Ronald Paans suggested that it > was not possible to fully secure an MVS system with OEM monitor tools > and development tools installed on it. It may be possible but I venture > to say it is not accomplished completely by many who think they have > accomplished it. > > Best Regards, > > Sam Knutson, GEICO /snip/ Jeffrey D. Smith Principal Product Architect Farsight Systems Corporation 700 KEN PRATT BLVD. #204-159 LONGMONT, CO 80501-6452 303-774-9381 direct 303-484-6170 FAX http://www.farsight-systems.com/ ---------------------------------------------------------------------- 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
