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
