Something about some road paved with good intentions? Good war story. Dr. Murphy is indeed a busy fellow. And an amazing teacher as most of us remember his lessons well.
Thanks for sharing that one. Linda Sent from my iPhone > On Aug 22, 2015, at 8:04 PM, J O Skip Robinson <[email protected]> > wrote: > > The moral of the following war story is that no amount of monitoring or > tracing or testing can save you from Dr. Murphy. > > Some idiot in our shop once misunderstood or misremembered something he > thought he had heard. He overrode the built-in (default) PPT entry for JES2 > to remove the blessed attributes. Things worked fine for 10 years until > someone else innocently created a generic RACF profile that happened to > encompass JES2 checkpoint and spool. At the next IPL, JES2 got S913 on his > own data sets. It had been so long since the errant PPT entry that even the > idiot had no clue it was his fault. The idiot should have been fired, but I'm > still here. > > . > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 626-302-7535 Office > 323-715-0595 Mobile > [email protected] > > -----Original Message----- > From: RACF Discussion List [mailto:[email protected]] On Behalf Of Stu > Henderson > Sent: Friday, August 21, 2015 12:48 PM > To: [email protected] > Subject: Re: TRUSTED attribute for IBM tasks > > Joel, Your comments make sense. It would be useful to us all if someone > would monitor the logging produced by TRUSTED to see which STCs actually use > it and why. It would also be useful if IBM (and other > vendor) doc. would provide substantiation, describing the reasoning around > statements that some STC needs TRUSTED. And maybe possible work arounds. And > maybe why effective change control on the configuration files for these STCs > is important. It strikes me that any security weakness in web facing started > tasks with TRUSTED would break IBM's Integrity Statement for MVS, since > TRUSTED would give access to the > FACILITY class rules named CSVAPF..... Best regards, Stu > > >> On 8/21/2015 2:23 PM, Tilton, Joel wrote: >> Juan, >> Well no offense to IBM but I've reached a new level of paranoia with them >> recommending TRUSTED. >> >> Why? I'm glad you asked. :-) >> >> Optionally TRUSTED means exactly that and in my experience IXGLOGR, GPMSERVE >> and even the Netivew UNIX STC can function without TRUSTED. >> >> Of course it's much less work to give an STC TRUSTED. If something is >> "optional" then I question the "requirement" to give it TRUSTED. >> If I were an auditor I would not want a task having this kind of high >> powered access just because IBM says its "optional." >> >> Be cautious if you give TRUSTED to anything when you're using SERVAUTH to >> secure networks and ports. >> You've just given the task total access to any ports and network zones it >> wants; just because it is an STC does not mean it should be entitled to such >> high level of access to your network. >> >> I think TRUSTED should really be reserved for core z/OS components like JES >> or XCF, for example, but certainly not tasks that provide service to end >> users or listen on ports. >> >> My two cents. Hope this helps. >> >> Your mileage may vary. >> >> Joel Tilton >> Senior Security Engineer >> EC Mainframe Security Engineering >> DTCC Tampa >> [email protected] >> +1 813-470-2160 >> >> Visit us at www.dtcc.com or follow us on Twitter @The_DTCC and on LinkedIn. >> To learn about career opportunities at DTCC, please visit dtcc.com/careers. >> >> Classification: DTCC Non-Confidential (WHITE) >> >> The views I have expressed in this email are my own personal views, and are >> not endorsed or supported by, and do not necessarily express or reflect, the >> views, positions or strategies of my employer. >> >> -----Original Message----- >> From: RACF Discussion List [mailto:[email protected]] On Behalf >> Of Mautalen Juan Guillermo >> Sent: Friday, August 21, 2015 10:13 AM >> To: [email protected] >> Subject: TRUSTED attribute for IBM tasks >> >> Hi! >> >> In the "MVS Initialization and Tuning Reference" book, there is a valuable >> list of STC that IBM recommends defining as TRUSTED. I always follow this >> recommendation (even for the OPTIONAL ones). >> We are currently at z/OS 1.13. However, I was looking at the z/OS 2.1 >> version of this list, and I see some additions (compared with 1.13 list). >> For instance: SMSPDSE1, WLM, ZFS. >> I was wondering whether to change them to TRUSTED right now (when still in >> 1.13), or wait until migration (that will not happen very soon, and will >> probably be to 2.2, by the way). Of course, no harm will be done to a task >> by marking it TRUSTED, but I don't know whether it is indeed a good idea to >> do it in advance, when we are not yet running the z/OS version suggesting it. >> >> What do you think? >> >> Thanks in advance, >> >> Juan G. Mautalen > > ---------------------------------------------------------------------- > 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
