These sessions both intended and scary can be controlled by Policy Agent (PAGENT under z/OSMF)
Marshall Stone | Lead Engineer| Mainframe & Engineering Solutions | Enterprise Infrastructure and Architecture – TRICARE 101 MetLife Way, MET1 03.273, Cary NC 27513 | T. 919-907-5346 | M. 919-324-4312| marshall.st...@metlife.com The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Styles, Andy (ITS zPlatform Services) Sent: Friday, March 23, 2018 2:50 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXT] Re: Health Check JES_NJE_SECURITY This is a real possibility - I've seen it in action; a connection via NJE was established and an unauthenticated user was able to submit a batch job under the id of someone in the Security area with RACF SPECIAL access. At that time, our NJE network was using unsecured IP connections over port 175. Andy Styles z/Series System Programmer -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: 22 March 2018 23:14 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Health Check JES_NJE_SECURITY -- This email has reached the Bank via an external source -- I chatted up Tom Wasik at SHARE in Sacramento. We have a robust internal NJE network but no longer any outside connections. Tom raised the possibility of someone using a mechanism (like Python) to spoof an NJE node from within the closed network. I know nothing about Python, but just the prospect is unnerving. I think we'll pursue this (remote?) exposure to minimize the risk. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Robert S. Hansel (RSH) Sent: Friday, March 02, 2018 6:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Health Check JES_NJE_SECURITY Hi Skip, If you define &RACLNDE and add the name of a node to it, JES will 'trust' and accept any job coming from that node and propagate the submitter's ID and group as is. Adding a node to &RACLNDE is the equivalent of creating NODES profiles of node.USERJ.* UACC(UPDATE), node.GROUPJ.* UACC(READ), and node.SECLJ.* UACC(READ). Note that NODES profiles are ignored for nodes listed in &RACLNDE, so you can't do any submitting user or group translations using NODES profiles. &RACLNDE is very powerful, and nodes should only be defined to it that are under your control. If a job is received from an &RACLNDE trusted node, and on the receiving system (a) the submitting user isn't defined, (b) the submitter's group isn't defined, or (c) the submitting user isn't connected to the group, the submitter is treated as an undefined user and the job may fail. This is why, as Walt indicated, you should only define nodes to &RACLNDE whose RACF databases are aligned for users, groups, and connects. For systems that aren't so aligned, don't include their nodes in &RACLNDE and use NODES profiles instead. I recommend you define &RACLNDE in each of your RACF databases and in each such profile include only the nodes for the systems sharing that particular database. Do so even on standalone systems or Multi-Access Spool configurations. This will facilitate spool reloads. Regards, Bob Robert S. Hansel Lead RACF Specialist RSH Consulting, Inc. *** Celebrating our 25th Year *** 617-969-8211 www.linkedin.com/in/roberthansel https://twitter.com/RSH_RACF www.rshconsulting.com -------------------------------------------------------------------------------- Upcoming RSH RACF Training - WebEx - RACF Audit & Compliance Roadmap - SEPT 10-14, 2018 - RACF Level I Administration - APR 10-13, 2018 ** Date Change ** - RACF Level II Administration - JUN 4-8, 2018 - RACF Level III Admin, Audit, & Compliance - OCT 1-5, 2018 - RACF - Securing z/OS UNIX - APR 23-27, 2018 -------------------------------------------------------------------------------- -----Original Message----- Date: Wed, 28 Feb 2018 19:38:33 +0000 From: Jesse 1 Robinson <jesse1.robin...@sce.com> Subject: Health Check JES_NJE_SECURITY APAR OA49171 introduces a new health check called Date: Thu, 1 Mar 2018 03:14:36 +0000 From: Jesse 1 Robinson <jesse1.robin...@sce.com> Subject: Re: Health Check JES_NJE_SECURITY Ouch. I never saw Walt's proviso mentioned in the doc. Yes, these nodes are all totally under our control. However each node (sysplex) constitutes a different business environment supported by a different RACF data base. A person may have the same userid on sandbox and on production, but they do not necessarily have the same authority on both. Both represent the same person but not necessarily the same role. We need to reassess our goal here. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Walt Farrell Sent: Wednesday, February 28, 2018 5:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Health Check JES_NJE_SECURITY On Wed, 28 Feb 2018 18:21:03 -0500, Tom Conley <pinnc...@rochester.rr.com> wrote: >I ran these on 1/5/18 to fix this check: > >RDEFINE RACFVARS &RACLNDE UACC(NONE) OWNER(<sysprog group>) RALTER >RACFVARS &RACLNDE ADDMEM(<your JES node>) (add one for each >node) >SETROPTS CLASSACT(RACFVARS) RACLIST(RACFVARS) You should be careful with that, Tom. &RACLNDE should only contain the names of nodes whose RACF databases are identical to each other, at least with respect to the users, groups, and user-group connections that are defined. Having a node listed in &RACLNDE will have a strong effect on security processing (mainly the propagation of submitter identity) for jobs submitted from that node to other nodes in your JES2 network. -- Walt ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC95000. Telephone: 0207 626 1500. Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 2065. Telephone 0207 626 1500. Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC327000. Telephone: 0207 626 1500. Lloyds Bank plc, Bank of Scotland plc are authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and Prudential Regulation Authority. Halifax is a division of Bank of Scotland plc. HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC218813. This e-mail (including any attachments) is private and confidential and may contain privileged material. If you have received this e-mail in error, please notify the sender and delete it (including any attachments) immediately. You must not copy, distribute, disclose or use any of the information in it or any attachments. Telephone calls may be monitored or recorded. ---------------------------------------------------------------------- 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
