Gerhard said that his client, the US f ederal entity acronym ed LUGA (Large Unnamed Government Agency), thought it was a security problem and eliminated the possibility that it could happen again when Gerhard showed how easy it was to do it.
Bill Fairchild Franklin, TN ----- Original Message ----- From: "Walt Farrell" <[email protected]> To: [email protected] Sent: Wednesday, May 8, 2013 7:37:40 AM Subject: Re: Duplicate Batch Job On Tue, 7 May 2013 12:49:32 -0500, Paul Gilmartin <[email protected]> wrote: >On Tue, 7 May 2013 13:34:07 -0400, Gerhard Postpischil wrote: > >>On 5/7/2013 5:02 AM, Lizette Koehler wrote: >>> The only way I can think of restricting is an exit in JES2. Or if this is >>> a >>> TSO User you may wish to look at IKJEFT10 exit. >> >>You'd be surprised how many "secure" installations permit a TSO user to >>allocate an internal reader and write a job to it. >> >Why is that a problem? I'm not sure why Gerhard thinks that is a security problem, gil. But certainy if users push jobs through the INTRDR directly (as opposed to via TSO/E SUBMIT or ISPF SUB) then you can't depend on any restrictions imposed by IKJEFF10; you would have to use JES or SMF exits. Actually, I'm not sure you can stop users from allocating an INTRDR and still allow them to submit jobs from TSO, since even SUBMIT goes through the INTRDR. So I've never believed in using IKJEFF10 to enforce installation restrictions on job content. > >Control resources, not tools. > Definitely! -- Walt ---------------------------------------------------------------------- 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
