Replying to my own post. ;-( So I would like to come to bejeesus on this subject. In trying to compare the IBM default PPT entries with whatever we may have specified, I'm stuck because the new (2.1) D PPT displays first all the Parmlib Values followed by the remaining IBM default values. It seems that a default value overridden by a parmlib entry is not displayed. In other words, I can't see both a default value and a corresponding parmlib value on the same system.
I'm disinclined to IPL with no parmlib entries at all just to see what IBM would provide. Does anyone know a straightforward way to compare and contrast installation values with default values? . . . 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: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of J O Skip Robinson Sent: Saturday, August 22, 2015 8:05 PM To: [email protected] Subject: Re: TRUSTED attribute for IBM tasks 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
