Re: Unix Security
In [EMAIL PROTECTED], on 11/13/2006 at 09:55 AM, Klavon John R [EMAIL PROTECTED] said: Does anyone have a good suggestion for setting up (Superuser id or UID(0) for individuals that require the access. Yes - check whether they really need it. The last time I had RACF SPECIAL I wouldn't even give myself UID(0), and that was *my* decision, not handed down from on high. Find out what they're doing and determine: 1. Can the privileged work be done in batch under a surrogate userid? 2. Can the privileged work be done with a lesser privilege level? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Unix Security
Patrick O'Keefe wrote: On Mon, 13 Nov 2006 17:28:47 +0100, R.S. [EMAIL PROTECTED] wrote: ... As you wrote it's because auditors want it. I understand your point, however I'm curious whether there's any real reason. I strongly agree with John on this. Even if no auditors were involved, giving a person UID(0)is giving far too much authority than is needed. To do that is to give the person a gun and paint a target on his or her foot (or on the whole shop's collective foot). Requiring setting SU in TSO or doing a setuid(0) or seteuid(0) in batch hopefully puts the user in be careful mode. I dare to disagree. No, I STRONGLY DISAGREE! What are your procedures for RACF SPECIAL user ? Are they so restrictive? What about storage administration ? I remember a shop with few newbies working as storage administrators. I protected ICKDSF by DASDVOL activation. They didn't get ALTER to DASDVOL profiles. Instead, they got CL(SURROGAT) STGUSER.SUBMIT ACC(READ) and STGUSER has ALTER. So they were able to use ICKDSF, but not screw something up using ISPF oops! typo navigation. SU everytime is similar (IMHO worse!) method for USS newbie administrator, but it is unneeded for experienced person who need UID(0) everyday. Last but not least: UID(0) on z/OS Unix is less than on any other Unix implementation. However AIX/HP-UX/Solaris/whatever administrators use UID(0) for everyday work. My $0.02 Regards -- Radoslaw Skorupka Lodz, Poland -- 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
Re: Unix Security
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of R.S. Sent: Tuesday, November 14, 2006 1:51 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Unix Security snip SU everytime is similar (IMHO worse!) method for USS newbie administrator, but it is unneeded for experienced person who need UID(0) everyday. Out of curiousity, what function requires uid(0) for an interactive user? I am the 99.999% UNIX administrator here. Most of the others are blistfully unaware of z/OS UNIX. I do not have uid(0). I've never missed it. I can ISHELL edit any file on the system (RACF profile). I can delete any file on the system. I can rmdir or mkdir anything, anywhere on any filesystem. The only thing that I have run into where my access fails is when pax does an fchattr (I think that's it). So I do an su, then a pax, then exit to go back to my normal id. Of course, you can argue that I have the power of uid(0) without the actual uid(0), so how is that safer? I can agree with that assesment. The only way is that my unique uid is logged so I know who done it. If multiple people have uid(0), then I cannot always figure out who done it. This is an audit point for us. Last but not least: UID(0) on z/OS Unix is less than on any other Unix implementation. However AIX/HP-UX/Solaris/whatever administrators use UID(0) for everyday work. So? Many recent Linux distros are no longer set up this way (Ubuntu comes to mind). In fact, some even go so far as to remove the ability to logon to root entirely. They do this by proper use of sudo. Unfortunately, z/OS UNIX does not have sudo. I worked for a short time with some AIX people. None of the AIX administrators routinely ran with uid(0). They used sudo for the dangerous stuff. The plus of sudo is that it leaves an audit trail of who really did what. Again, an audit point. Auditors like knowing who did what to which and when grin. My $0.02 Regards -- Radoslaw Skorupka -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- 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
Re: Unix Security
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Klavon John R Sent: Monday, November 13, 2006 8:56 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Unix Security Does anyone have a good suggestion for setting up (Superuser id or UID(0) for individuals that require the access. They would like to set up as few users as possible to satisfy the auditors.. Don't. Do. That. There is no need for a live person to have UID(0) as their normal UID. There are a whole set of RACF facilities to allow a person many of the functions normally granted by UID(0). Start reading at: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/BPXZB270/4.6 If nothing else, grant RACF read authority to BPX.SUPERUSER in the FACILITY class to the people who need it. This will allow them to su for root (UID 0) access as needed. There are a lot of profiles starting with BPX. in the FACILITY class to allow people to do superuser-like functions. There are many more profiles in the UNIXPRIV class to also let non-root people do things. If a live person must run a batch job which demands root, then set up a SURROGAT profile to allow them to submit a job with the USER= specifying the id in the SUPERUSER() parameter of BPXPRMxx in PARMLIB. We __never__ allow an interactive user to have UID(0) in their OMVS segment. Only a very few PROTECTED RACF userids have UID(0). In fact, there are only two in my shop. There is the SUPERUSER in the BPXPRMxx member and there is a separate one for the HTTPD server. The only reason I have two is so that the RACF accesses to non-UNIX datasets is more controlled for the HTTPD server id. These ids are only used for specific started tasks such as TCPIP and other UNIX daemons. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- 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
Re: Unix Security
McKown, John wrote: [...] If nothing else, grant RACF read authority to BPX.SUPERUSER in the FACILITY class to the people who need it. This will allow them to su for root (UID 0) access as needed. There are a lot of profiles starting with BPX. in the FACILITY class to allow people to do superuser-like functions. There are many more profiles in the UNIXPRIV class to also let non-root people do things. If a live person must run a batch job which demands root, then set up a SURROGAT profile to allow them to submit a job with the USER= specifying the id in the SUPERUSER() parameter of BPXPRMxx in PARMLIB. We __never__ allow an interactive user to have UID(0) in their OMVS segment. Only a very few PROTECTED RACF userids have UID(0). In fact, there are only two in my shop. There is the SUPERUSER in the BPXPRMxx member and there is a separate one for the HTTPD server. The only reason I have two is so that the RACF accesses to non-UNIX datasets is more controlled for the HTTPD server id. These ids are only used for specific started tasks such as TCPIP and other UNIX daemons. IMHO the better idea is to have dadicated user fo BPXPRMxx SUPERUSER. It should be very limited userid. Not used anywhere. Daemons should use other userid(s). BTW: whye the live person shouldn't have UID(0) ? I mean person who really needs it, not everyone. -- Radoslaw Skorupka Lodz, Poland -- 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
Re: Unix Security
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of R.S. Sent: Monday, November 13, 2006 9:58 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Unix Security snip IMHO the better idea is to have dadicated user fo BPXPRMxx SUPERUSER. It should be very limited userid. Not used anywhere. Daemons should use other userid(s). BTW: whye the live person shouldn't have UID(0) ? I mean person who really needs it, not everyone. -- Radoslaw Skorupka Personal opinion time on that last question. 1) I've never seen anybody who really needs it when the other RACF facilities are properly set up. 2) Auditors tend to not like it. So avoid an unnecessary fight with them. Especially in view of the above. Those two are sufficient for me. As to started tasks which need UID(0) running with different RACF ids, that is OK by me. At one time, I wanted a unique RACF id for every STC. However, given that the majority of STCs (ignoring CICS mainly) are single purpose and said purpose is limited, it just got to be a pain to maintain. Not to mention that other sysprogs kept wanting test STCs and wouldn't usually bother to ask me to set up a unique RACF id for it, because it is only for a short test. Granted, I could set RACF up so that such STCs would likely die from RACF errors, but this is a small shop and, again, I considered it to be over kill. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- 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
Re: Unix Security
McKown, John wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of R.S. Sent: Monday, November 13, 2006 9:58 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Unix Security snip IMHO the better idea is to have dadicated user fo BPXPRMxx SUPERUSER. It should be very limited userid. Not used anywhere. Daemons should use other userid(s). BTW: whye the live person shouldn't have UID(0) ? I mean person who really needs it, not everyone. -- Radoslaw Skorupka Personal opinion time on that last question. 1) I've never seen anybody who really needs it when the other RACF facilities are properly set up. 2) Auditors tend to not like it. So avoid an unnecessary fight with them. Especially in view of the above. IMHO it's sometimes easier to have UID(0) than issuing su everytime. Less effort, less errors. As you wrote it's because auditors want it. I understand your point, however I'm curious whether there's any real reason. Those two are sufficient for me. As to started tasks which need UID(0) running with different RACF ids, that is OK by me. So, you're using generic UID(0) for STC and dedicatd user for WAS. That's OK. My suggestion is to avoid using BPXPRM SUPERUSER as generic UID(0) for STC. Assuming some hacker will get UID(0) the system will assign him the SUPERUSER userid. That's why it is good to define it as much as restricted. Regards -- Radoslaw Skorupka Lodz, Poland -- 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
Re: Unix Security
On Mon, 13 Nov 2006 17:28:47 +0100, R.S. [EMAIL PROTECTED] wrote: ... As you wrote it's because auditors want it. I understand your point, however I'm curious whether there's any real reason. I strongly agree with John on this. Even if no auditors were involved, giving a person UID(0)is giving far too much authority than is needed. To do that is to give the person a gun and paint a target on his or her foot (or on the whole shop's collective foot). Requiring setting SU in TSO or doing a setuid(0) or seteuid(0) in batch hopefully puts the user in be careful mode. ... My suggestion is to avoid using BPXPRM SUPERUSER as generic UID(0) for STC. Assuming some hacker will get UID(0) the system will assign him the SUPERUSER userid. That's why it is good to define it as much as restricted. ... Good heavens. I don't think there was any suggestion to have the default userid have BPXPRM.SUPERUSER access. The default id should have as little autoroty as possible. The generic UID(0)for STC would hopefully not be useable by a person - would not have a password. I'm way out of my area of expertese here, but I think all the major security products have that capability. I think we need to repeat John's no person with UID(0) plea often and loudly because we have to counteract those Program Directories (and non-IBM equivalents) that still say UID(0) is required. Many product still have installation instructions claiming this because the packagers are to lazy to determine their true needs. And don't care that they are are advocating a security and integrity exposure. Pat O'Keefe -- 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
