I understand the paranoia. However, if RACF/VM is down you 'd be using the operator console to recycle that virtual machine (or perhaps re-IPL VM, if necessary, as there may be certain scenarios -caused by implementing certain RACF parameters). All in all, you could leave a non-RACF hooked CPLOAD module on the parm disks (CF1, etc.) in order to IPL via the SAPL method...so as just to recover or reinstall RACF/VM if it's that hosed -- As in, the client's/shop's security policy may be specific to run production LPARs only with RACF/VM or an external security manager, otherwise it would be deemed unsecure/unfit for production (policy-wise). I would be very curious to know if the RACF/VM manuals mention this OPERATOR user/RACF LOGONBY scenario or suggests something else. On a side-note, I've found that (some?) auditor's methods for z/VM audits are antiquated. We are rolling very securely at this client site. Even still, one recent audit referenced an old security parameter in an obsolete, superceded CP initialization module (DMKSYS). A quick search on the Net, and I found this was in regards to an old VM audit guide depicting VM/SP http://www.auditnet.org/docs/vmos.txt from 1985?! Audits at IBM (in VM development) were different, as they were based on the nature of software security levels (EAL, etc.). But in the client world, I would hope auditors don't follow this normally, as I was in 2nd grade when it came out. Or do I not hope that? :) Doug Ponte
________________________________ From: The IBM z/VM Operating System on behalf of Lionel B. Dyck Sent: Wed 26-Sep-07 11:31 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: z/vm security advise requested Operator was an exception just incase RACF were down and we needed to use it to recover. If this is not required then I'm very open to making it conform. Thanks ________________________________ Lionel B. Dyck, Consultant/Specialist Enterprise Platform Services, Mainframe Engineering KP-IT Enterprise Engineering, Client and Platform Engineering Services (CAPES) 925-926-5332 (8-473-5332) | E-Mail: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> AIM: lbdyck | Yahoo IM: lbdyck Kaiser Service Credo: "Our cause is health. Our passion is service. We're here to make lives better." "Never attribute to malice what can be caused by miscommunication." NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, you are prohibited from sharing, copying, or otherwise using or disclosing its contents. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and permanently delete this e-mail and any attachments without reading, forwarding or saving them. Thank you. From: "Ponte, Doug" <[EMAIL PROTECTED]> To: IBMVM@LISTSERV.UARK.EDU Date: 09/26/2007 08:10 AM Subject: Re: z/vm security advise requested ________________________________ Agreed. Although, why is OPERATOR proposed as an exception? The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. From: The IBM z/VM Operating System on behalf of Huegel, Thomas Sent: Wed 26-Sep-07 10:35 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: z/vm security advise requested I think once you have RACF installed all of the other sevurity problems you describe are solved. -----Original Message----- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU <mailto:IBMVM@LISTSERV.UARK.EDU> ]On Behalf Of Lionel B. Dyck Sent: Wednesday, September 26, 2007 9:30 AM To: IBMVM@LISTSERV.UARK.EDU Subject: z/vm security advise requested To keep our auditors happy (assuming that is possible) to secure our z/vm (5.3) environment I am planning on doing the following. Note that our environment is purely in support of linux virtualized servers and the only cms users are the handful of sysprogs supporting z/vm. 1. installing both racf/vm and dirmaint 2. all linux virtual server guests will be defined with LBYONLY and a LOGONBY for the sysprogs 3. all system machines with the exception of Operator will also be defined with LBYONLY and LOGONBY for the sysprogs Does anyone see any issues/exposures with this approach. Thanks ________________________________ Lionel B. Dyck, Consultant/Specialist Enterprise Platform Services, Mainframe Engineering KP-IT Enterprise Engineering, Client and Platform Engineering Services (CAPES) 925-926-5332 (8-473-5332) | E-Mail: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > AIM: lbdyck | Yahoo IM: lbdyck Kaiser Service Credo: "Our cause is health. Our passion is service. We're here to make lives better." "Never attribute to malice what can be caused by miscommunication." NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, you are prohibited from sharing, copying, or otherwise using or disclosing its contents. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and permanently delete this e-mail and any attachments without reading, forwarding or saving them. Thank you. ________________________________ << ella for Spam Control >> has removed 13021 VSE-List messages and set aside 12385 VM-List for me You can use it too - and it's FREE! www.ellaforspam.com <http://www.ellaforspam.com/ <http://www.ellaforspam.com/> >
