Radaslow, Actually, an APF authorized program may be able to be "directly" invoked, ie via a LINK or ATTACH service, but it will NOT be APF authorized in this case. In order for an address space to be authorized via z/OS integrity rules, ALL of the following must be true: 1 - The jobstep program must be link-edited AC(1). 2 - The entire STEPLIB for the jobstream (if there is one) must consist SOLELY of APF authorized load libraries, if NO steplib, the program must reside in LPA (always authorized) or LINKLIST.
Note that in 1 it is the jobstep program (and only the jobstep program) that should and must be linked with AC(1). The only VALID way that the JSCBAUTH bit will be set for a job step TCB is if the above requirements are met when the INITIATOR issues the attach of the jobstep program. There is no way for an unauthorized program to attach a module linked AC(1) and have the JSCBAUTH bit set for the job step TCB. In addition, when a job step TCB is running with the JSCBAUTH bit set, the system will NOT allow the loading of program from a library that is NOT APF authorized, which is why the list of users with update authority to your APF libs must be limited to trusted personel. Now contrast that with an SVC. The SVC is loaded into LPA at IPL time. All a program needs to know is the SVC number, and the parm format. The former can be learned in various ways, even for "secret" SVC's, and the latter can be learned by poking around at the SVC code using tools such as TSO test. As mentioned, in the past, may sites had these "magic" SVC's that would flip the JSCBAUTH bit and return to the caller. Thus making anything that runs under the jobstep TCB APF authorized. Now this does limit the ability to load non-authorized programs from that point, until the JSCBAUTH bit is reset, but all you need to do is to load the programs before issuing the "magic" SVC. As to your point about DSS like programs with a "ADMIN" type keyword. If the product documents something like this, it should contain support to secure these functions via an ESM, much like DSS and the use of FACILITY class IRR.STGADMIN (from memory) profiles. A final point. While "magic" SVC's are watched closely, and very dangerous, another point of concern could be programs which need to be placed in the IKJTSOxx member of parmlib in the AUTHTSF list. When these programs are invoked via the TSO Service Facility will run APF authorized in a parellel TMP task, within the TSO address space. The design of the TSO Service Facility will STOP all other TCB's in the non-authorized TMP for the duration of the running of the parellel TMP, but there still are ways to compomise system security in these programs. Hope this helps. Wayne Driscoll Product Developer JME Software LLC NOTE: All opinions are strictly my own. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of R.S. Sent: Friday, June 22, 2007 1:21 AM To: [email protected] Subject: Re: SVC vs APF and other 'privileged' code First, I want to THANK YOU for clarification. Now it's more clear for me. However both code - APF and SVC can be poor. Both can be invoked, APF program can be invoked directly - it is still a risk it could accept 'magic parameters' and do something wrong. For example I imagine DSS program clone which accept ADMIN keyword without further authorization. In other words - both kinds of code can be dangerous when poorly written or contain 'backdoors'. Regards -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl ---------------------------------------------------------------------- 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
