On Sun, 15 Mar 2015 13:19:13 -0700 Sam Siegel <[email protected]> wrote:
:>Look at the SYNC(X) macro. It provides a way to invoke a program in a :>non-authorized fashion when running authorized. Does nothing in an APF environment as the exit can issue MODESET - used as an exit from an SVC. :>On Sun, Mar 15, 2015 at 12:58 PM, Charles Mills <[email protected]> wrote: :> :>> Agree with Gil's last comment 100%. Or give me an option: program Y does :>> not need authorization any more than it would if called natively. Why can't :>> I have the option to LINK to it APF=NO? :>> :>> FWIW, 'Y' will be hard-coded, and the user does not pass addresses, only :>> character strings, which I pass unmodified to Y. :>> :>> But I have no way of knowing "how safe" Y really is. Frankly, I suspect :>> based on my historical knowledge that it was one of IBM's more hasty :>> efforts. I will certainly LINK to it user key and problem state, so it is :>> unlikely it will cause problems by accident. I suppose it is fairly safe to :>> assume a lack of malice on the part of IBM's programmers, and therefore to :>> assume they do not do a TESTAUTH and if authorized do a MODESET KEY=ZERO, :>> ... :>> :>> It's in an APF library, so it is the customer's responsibility to keep :>> someone from patching Y maliciously. If Bobby Badguy has write access to an :>> APF library, all bets are off anyway. :>> :>> Charles :>> :>> -----Original Message----- :>> From: IBM Mainframe Discussion List [mailto:[email protected]] On :>> Behalf Of Paul Gilmartin :>> Sent: Sunday, March 15, 2015 12:27 PM :>> To: [email protected] :>> Subject: Re: APF-authorized calling non-authorized :>> :>> On Sun, 15 Mar 2015 13:40:54 -0400, Shmuel Metz (Seymour J.) wrote: :>> :>> > on 03/15/2015 at 06:43 PM, Binyamin Dissen said: :>> > :>> >>Since it is placed in an APF library, the installation (or IBM) has :>> >>declared that it will not create an exposure. :>> > :>> >Not even close. All that IBM has declared is that none of the AC(1) :>> >routines will call anything that cannot safely run authorized. An :>> >AC(0) routine in an authorized library that is never called from an :>> >AC(1) routine does not create a security exposure. IB< has declared :>> >that if you write an AC(1) routine it is your responsibility to only :>> >call things that you know are safe. :>> > :>> More precisely, I believe that it is the responsibility of an AC(1) :>> routine to call an AC(0) routine only in a fashion known to be safe. For :>> example, if the caller passes the address of a reply buffer, that buffer :>> must not overlay storage in a way that threatens integrity. It is the :>> responsibility of an AC(0) routine residing in an authorized library, then, :>> to perform only documented actions, lest no side effect threatens system :>> integrity. :>> :>> It is widely suspected that this requirement is the basis for the :>> five-year old rule that a high level of RACF authorization is needed to use :>> SMP/E: SMP/E, AC(1) in an authorized library, invokes many utilities (in :>> fact selectable by the programmer) marked AC(0). It's unrealistic to :>> expect SMP/E to ensure the integrity of everything it calls, so the :>> responsibility (or at least any blame) is shifted to the programmer using :>> SMP/E. :>> :>> Is the name of subroutine "Y" hardcoded in Charles's "X", or is the end :>> user of "X" allowed to select "Y" as a parameter? :>> :>> Naive design of z/OS -- it would be better if such utilities could be :>> invoked in a fenced environment, such as a separate address space, so they :>> could do no harm. :>> :>> ---------------------------------------------------------------------- :>> 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 -- Binyamin Dissen <[email protected]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
