In the JES2 Init deck, you can specify clear text passwords for RJE lines. That is a great reason for specifying UACC(NONE). 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 Farley, Peter x23353 Sent: Thursday, June 21, 2007 12:33 PM To: [email protected] Subject: Security vs knowledge [was: RE: how to list LE options] > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Mark Zelden > Sent: Thursday, June 21, 2007 10:44 AM > To: [email protected] > Subject: Re: how to list LE options <Snipped> > There are pros and cons like everything else. If you want or need > tight security controls, then "on a need to know basis" is a good approach. See, that's the attitude I am talking about. Hide the data and make people ask for it and justify asking for it. Why? Because some fool of an auditor doesn't understand mainframes? That's just BS IMHO. Fire the auditor for incompetence. > You picked a bad example. I don't want to handcuff anyone to keep > them from doing their jobs, but PARMLIB should definitely be > UACC(NONE) except to the sysprogs who need to update it. Again, why? What possible security exposure could result from application programmers browsing PARMLIB? AFAIK there aren't any passwords or any "secrets" stored there that would give any programmer the ability to bypass RACF or any other active security protocol. If that's true, why UACC(NONE)? Even if (to take an old and probably obsolete example) there are user SVC numbers listed in PARMLIB which when used would provide supervisor state and key zero, RACF and/or other active security in the SVC code itself should already prevent said programmer from actually using that SVC unless authorized to do so, so where is the harm is letting the SVC number be known? And if there is NOT security software protecting that privileged resource, why not? THAT would be the security exposure, not the availability of the information that it exists. > If you don't think that is proper... just ask any auditor. ;-) Do you > really think the APF list should be published?! Yes I do. Where is the harm? What is the exposure? If I am not authorized to write into any of the libraries in that list, what harm can I do knowing their names? > Seriously... have you ever been involved with a SAS70 audit? No, nor ever hope to be. But if I was, I would strenuously argue against hiding any non-security-exposure information. Knowing there IS a secured facility and being able to USE it are NOT the same thing. Knowing is not a security exposure, only the ability to use it is. > >The attitude I don't understand seems to be "If I hide it they won't > >find out how I do my job, or bother me about it, or try to show me a > >better way to get this business done than I know about". > > Unfortunately, that is probably the attitude many application > programmers have. "Hiding things" is more likely due to security / audit concerns. > Don't take it personally, it isn't a conspiracy to keep you from doing > your job (at least at the shops I've worked at). Well it certainly looks that way most of the time, because no one gives a good reason for hiding anything -- just "security" and "need to know". > >Good relations between sysprogs and application programmers are > >crucial to business success. Locking yourself and your data in a > >closet does not help. > > Agree. But having tight security doesn't preclude that. I am a phone > call, email or instant message away. Bad relations are more likely due > to the stereotypical grouchy sysprog who just shoves someone away > without helping or answers questions with a response of "RTFM" all the time. Possibly, or also possibly management that tells sysprogs to keep everyone else ignorant because they like it that way. I can only go by what I see. I do have and have had excellent relations with sysprogs, but still there are stupidities foisted on them and us as "security" requirements. That's my real beef. Thanks for listening. Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
