Re: OMVS segments created on demand
Dave, You've touched on the one concern I have with using BPXMODEL to automatically set up a HOME for every user coupled with an automount policy that automatically creates the home file system. While it certainly is convenient, it potentially turns every ordinary CICS and IMS user into a telnet, ssh, or putty user. For this reason, the installations we've been working with to implement BPX.UNIQUE.USER have chosen to create a BPXMODEL user having an OMVS segment with PROGRAM(/bin/echo -or- /bin/false) and/or HOME that specifies a non-existing directory so as to deny use of telnet. A proper PROGRAM and HOME are assigned only to those relatively few individuals who need to access Unix files and directories, and this is done either manually or via ID provisioning scripts. While this technique blocks use of telnet and the like, it does not address use of other TCPIP applications such as FTP. FTP does not use PROGRAM or HOME. Most installations have not been aware that BPX.DEFAULT.USER made every ordinary CICS and IMS user an FTP user, and this realization has only come about as a result of its replacement. To restrict use of FTP and other such applications, you need to employ APPL and/or SERVAUTH profiles. I do not think it necessary to assign OMVS(NOUID) to all your ordinary users. This would simply trip them up and add to your administrative burden if they need legitimate access to a Unix service. Besides, they'd previously been getting such assess all along via BPX.DEFAULT.USER. But you don't want them all to be telnet users either. Properly securing both the data (as John McKown wisely points out) and system entry points is the better way to go. P.S. While we're on the subject of FTP, now is a good time to review its JESINTERFACELEVEL configuration parameter and related RACF controls. See our RSH RACF Tips article on this topic: http://www.rshconsulting.com/racftips/RSH_Consulting__RACF_Tips__April_2010.pdf Regards, Bob Robert S. Hansel Lead RACF Specialist RSH Consulting, Inc. 617-969-8211 www.linkedin.com/in/roberthansel http://twitter.com/RSH_RACF www.rshconsulting.com --- 2015 RACF Training - Intro Basic Admin - WebEx - JUN 22-26, 2015 - Securing z/OS UNIX - WebEx - SEPT 22-25, 2015 - Audit Compliance Roadmap - Boston - NOV 10-13, 2015 - Intro Basic Admin - WebEx - DEC 7-11, 2015 --- -Original Message- Date:Fri, 5 Jun 2015 08:27:24 -0500 From:David Magee david.ma...@dillards.com Subject: OMVS segments created on demand Environment: running z/OS V2R1, using profiles BPX.NEXT.USER and BPX.UNIQUE.USER, the BPXMODEL profile is set up correctly (with HOME as /u/racuid), and all users are automount manged under /u/ and the system dynamically creates and mounts the OMVS user's file system. New userid is added to RACF with no OMVS segment and neither it nor its GROUP is in any access list. Using an ssh client, I attempt to sign in to my z/OS host and it succeeds. The userid now has an OMVS segment and a mounted file system. That's great for adding new users that are members of our IT department, etc. But there are thousands of non-IT userids that exist in RACF for business purposes (users of CICS or IMS, etc.) and they have been in RACF for years with no OMVS segment. These days, a lot of that access is via browser or TN3270 clients on a PC of some type. A PC where an ssh client or putty could be used to attempt to access the z/OS host. Have I missed something? This seems to be a security issue to me. Other than going out and adding OMVS(NOUID) to a LOT of RACF USER profiles (which disables the dynamic creation of a new OMVS segment), what else is available to control this? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OMVS segments created on demand
On 2015-06-05, at 10:14, Jousma, David wrote: Unless I am missing something, how is it a security issue? You had to logon with an id and password. It can access its own home directory, and was created based on a template I am assuming you or someone in your shop setup. o Agreed. It might be a resource issue, but hardly if the default home directory is small. What's one cylinder, nowadays, anyway? o But in our environment, we have enough other UNIX network that we want to ensure that z/OS UIDs match other UNIX UIDs. Can this be automated? Perhaps with LDAP for z/OS? (This might be a lot easier if it weren't for the asinine 7-character constraint. USERIDALIASTABLE?) -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Magee Sent: Friday, June 05, 2015 9:27 AM Have I missed something? This seems to be a security issue to me. Other than going out and adding OMVS(NOUID) to a LOT of RACF USER profiles ... Must that be done individually? Can't it be set as a default? (which disables the dynamic creation of a new OMVS segment), what else is available to control this? Does that curtail use of FTP, either as server or client? (But that might be your intent anyway.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OMVS segments created on demand
Have to have a segment to use any IP services on the mainframe side. We are going through the conversion off of BPX.DEFAULT user now. We just decided that everything will get a omvs segment. Retro fitting the more critical stuff now, will turn on the autoassign soon to get the rest. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, June 05, 2015 12:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: OMVS segments created on demand On 2015-06-05, at 10:14, Jousma, David wrote: Unless I am missing something, how is it a security issue? You had to logon with an id and password. It can access its own home directory, and was created based on a template I am assuming you or someone in your shop setup. o Agreed. It might be a resource issue, but hardly if the default home directory is small. What's one cylinder, nowadays, anyway? o But in our environment, we have enough other UNIX network that we want to ensure that z/OS UIDs match other UNIX UIDs. Can this be automated? Perhaps with LDAP for z/OS? (This might be a lot easier if it weren't for the asinine 7-character constraint. USERIDALIASTABLE?) -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Magee Sent: Friday, June 05, 2015 9:27 AM Have I missed something? This seems to be a security issue to me. Other than going out and adding OMVS(NOUID) to a LOT of RACF USER profiles ... Must that be done individually? Can't it be set as a default? (which disables the dynamic creation of a new OMVS segment), what else is available to control this? Does that curtail use of FTP, either as server or client? (But that might be your intent anyway.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OMVS segments created on demand
snip Unless I am missing something, how is it a security issue? You had to logon with an id and password. It can access its own home directory, and was created based on a template I am assuming you or someone in your shop setup. /snip Agreed! snip Environment: running z/OS V2R1, using profiles BPX.NEXT.USER and BPX.UNIQUE.USER, the BPXMODEL profile is set up correctly (with HOME as /u/racuid), and all users are automount manged under /u/ and the system dynamically creates and mounts the OMVS user's file system. New userid is added to RACF with no OMVS segment and neither it nor its GROUP is in any access list. Using an ssh client, I attempt to sign in to my z/OS host and it succeeds. The userid now has an OMVS segment and a mounted file system. That's great for adding new users that are members of our IT department, etc. But there are thousands of non-IT userids that exist in RACF for business purposes (users of CICS or IMS, etc.) and they have been in RACF for years with no OMVS segment. These days, a lot of that access is via browser or TN3270 clients on a PC of some type. A PC where an ssh client or putty could be used to attempt to access the z/OS host. Have I missed something? This seems to be a security issue to me. Other than going out and adding OMVS(NOUID) to a LOT of RACF USER profiles (which disables the dynamic creation of a new OMVS segment), what else is available to control this? /snip This is the defined function of BPX.NEXT.USER/BPX.UNIQUE.USER If you really want to restrict OMVS access, set the OMVS PGM to FALSE in the MODEL user id. HTH, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OMVS segments created on demand
On Fri, Jun 5, 2015 at 11:14 AM, Jousma, David david.jou...@53.com wrote: Unless I am missing something, how is it a security issue? You had to logon with an id and password. It can access its own home directory, and was created based on a template I am assuming you or someone in your shop setup. I can, sort of, see a possible security concern here. At present, to access CICS, a RACF id must have a CICS segment. To access TSO, it must have a TSO segment. A CICS user cannot log in to TSO if they don't have a TSO segment. But, with the automatic UID GID assignment, that CICS user could, if they were knowledgeable enough, use PuTTY on their PC to connect and have a z/OS UNIX prompt. Depending on the environment, they may then have access to information to which they should not. Especially if the security department in the past has been lax because they can only get to stuff via CICS, so why bother with a lot of unnecessary data set profiles? At the very least, the unauthorized user could be running stuff for learning purposes which would use up CPU and DASD resources (e.g. fill up /tmp) and so impact performance and perhaps even billing (MSU increase). Can _you_ say fork bomb? Also, it could cause other problems with auditing. As in not having any reports for this sort of thing at present because nobody uses it. So now the auditors and security people may need to be involved. And that may have other, political, repercussions. -- Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be. My sister opened a computer store in Hawaii. She sells C shells down by the seashore. If someone tell you that nothing is impossible: Ask him to dribble a football. He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OMVS segments created on demand
Unless I am missing something, how is it a security issue? You had to logon with an id and password. It can access its own home directory, and was created based on a template I am assuming you or someone in your shop setup. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Magee Sent: Friday, June 05, 2015 9:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: OMVS segments created on demand Environment: running z/OS V2R1, using profiles BPX.NEXT.USER and BPX.UNIQUE.USER, the BPXMODEL profile is set up correctly (with HOME as /u/racuid), and all users are automount manged under /u/ and the system dynamically creates and mounts the OMVS user's file system. New userid is added to RACF with no OMVS segment and neither it nor its GROUP is in any access list. Using an ssh client, I attempt to sign in to my z/OS host and it succeeds. The userid now has an OMVS segment and a mounted file system. That's great for adding new users that are members of our IT department, etc. But there are thousands of non-IT userids that exist in RACF for business purposes (users of CICS or IMS, etc.) and they have been in RACF for years with no OMVS segment. These days, a lot of that access is via browser or TN3270 clients on a PC of some type. A PC where an ssh client or putty could be used to attempt to access the z/OS host. Have I missed something? This seems to be a security issue to me. Other than going out and adding OMVS(NOUID) to a LOT of RACF USER profiles (which disables the dynamic creation of a new OMVS segment), what else is available to control this? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OMVS segments created on demand
On Fri, 5 Jun 2015 12:09:42 -0500, John McKown john.archie.mck...@gmail.com wrote: I can, sort of, see a possible security concern here. At present, to access CICS, a RACF id must have a CICS segment. To access TSO, it must have a TSO segment. A CICS user cannot log in to TSO if they don't have a TSO segment. But, with the automatic UID GID assignment, that CICS user could, if they were knowledgeable enough, use PuTTY on their PC to connect and have a z/OS UNIX prompt. Depending on the environment, they may then have access to information to which they should not. Especially if the security department in the past has been lax because they can only get to stuff via CICS, so why bother with a lot of unnecessary data set profiles? At the very least, the unauthorized user could be running stuff for learning purposes which would use up CPU and DASD resources (e.g. fill up /tmp) and so impact performance and perhaps even billing (MSU increase). Can _you_ say fork bomb? Also, it could cause other problems with auditing. As in not having any reports for this sort of thing at present because nobody uses it. So now the auditors and security people may need to be involved. And that may have other, political, repercussions. John, Thanks for the additional input. You added some points that I was vaguely concerned about, but had not actually put words to in my haste to post what I consider to be a concern. Prior to the changes with the various BPX.*.USER profiles, I had not realized a user originally added to RACF for just CICS could acquire an session via ssh to the host. Therefore none of those userids have ever had OMVS(NOUID) added to them. I'm thinking that I might need to go alter all of those userids and our process for adding new userids to RACF needs to be changed. Anyone else out there already doing something in this area or have plans to do so? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OMVS segments created on demand
I may be missing something obvious here but if in my past life I worked with many thousands of CICS only users none of whom had a CICS segment. Now if they did use their PC to acquire a z/OS UNIX prompt, then what? They would have access to any ID(*) or UACC=notNONE dataset profiles. I suppose they could submit a job whose last step submits itself 10 more time, etc etc. Likewise FTP some datasets. On 6/5/2015 4:05 PM, David Magee wrote: On Fri, 5 Jun 2015 12:09:42 -0500, John McKown john.archie.mck...@gmail.com wrote: I can, sort of, see a possible security concern here. At present, to access CICS, a RACF id must have a CICS segment. To access TSO, it must have a TSO segment. A CICS user cannot log in to TSO if they don't have a TSO segment. But, with the automatic UID GID assignment, that CICS user could, if they were knowledgeable enough, use PuTTY on their PC to connect and have a z/OS UNIX prompt. Depending on the environment, they may then have access to information to which they should not. Especially if the security department in the past has been lax because they can only get to stuff via CICS, so why bother with a lot of unnecessary data set profiles? At the very least, the unauthorized user could be running stuff for learning purposes which would use up CPU and DASD resources (e.g. fill up /tmp) and so impact performance and perhaps even billing (MSU increase). Can _you_ say fork bomb? Also, it could cause other problems with auditing. As in not having any reports for this sort of thing at present because nobody uses it. So now the auditors and security people may need to be involved. And that may have other, political, repercussions. John, Thanks for the additional input. You added some points that I was vaguely concerned about, but had not actually put words to in my haste to post what I consider to be a concern. Prior to the changes with the various BPX.*.USER profiles, I had not realized a user originally added to RACF for just CICS could acquire an session via ssh to the host. Therefore none of those userids have ever had OMVS(NOUID) added to them. I'm thinking that I might need to go alter all of those userids and our process for adding new userids to RACF needs to be changed. Anyone else out there already doing something in this area or have plans to do so? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
