Not sure if it is still an issue, but SDSF SVC could be used to switch from semmi authorized to superviser mode.
ITschak בתאריך שבת, 1 ביוני 2019, 1:04, מאת Ray Overby <rayove...@comcast.net>: > In response to "What convention? The z/OS platform is (mostly) secure." > > z/OS is the most secure-able platform I know. However, a z/OS > installation is only secure when the installation configures it > correctly AND all programs running on the system do not violate the > statement of integrity. Both must be true or it is not secure. > > In response to "If the user adds authorized code then it is no longer > IBM's platform, and security vulnerabilities caused by not following the > statement of integrity are vulnerabilities in the installation, not in > z/OS." > > Please assume a TRAP DOOR vulnerability is in IBM, ISV, or installation > written code for this. That will help focus the discussion. > > * Do the capabilities of the code vulnerability change based on whose > code the vulnerability is located in? I don't think so - it > certainly does not for a TRAP DOOR. > * Does the vulnerability risk to the installation change based upon > whose code the vulnerability is located in? I don't think so - it > certainly does not for a TRAP DOOR. > * Does the installation, whose mainframe has exploitable code > vulnerabilities, really care if the vulnerabilities come from IBM, > ISV's, or installation written code? Yes, but only because they > will need to know in order to report the problem to get a fix. > > I do not see that your distinction between an "IBM platform" and an > "Installation Platform" helpful for an installation when it is trying to > deal with exploitable code vulnerabilities. Perhaps there is a reason > that I don't see. > > Something that might help this discussion (I would suggest this be done > periodically - for example monthly): > > * How many integrity vulnerabilities are located in an installations > CSI's GLOBAL zones? > * How many are in apply status? > * How many new ones are there each reporting period? > > My company does not have access to this data so I don't really know the > answers. Perhaps someone else could report it (assuming that does not > violate some legal agreement). Even if you don't report it the > information may be enlightening. > > I think people need to understand - TRAP DOORS (as well as other > vulnerability categories) exist in IBM, ISV, and installation code on a > regular basis based upon the data my company has acquired. As others > have pointed out my company does not find all code vulnerabilities but > we still have found several hundred. Code vulnerabilities are not a once > in a lifetime occurrence as most people assume. The numbers are not like > the other platforms but they are greater than what most would expect. > Perhaps if someone reports the information in their SMP/E CSI's that > might shed more light on this subject. > > In response to "Now, when *IBM* fails to follow the statement of > integrity, that *is* a z/OS vulnerability, but when is the last time > that IBM refused to correct such an error when it was reported?" > > I attribute this to Mark Nelson (IBM) - I am paraphrasing - Mark - > please correct this if I get this wrong - That IBM has corrected all > accepted integrity problems with one exception. Mark thought that the > product with the vulnerability was removed from marketing. This one > exception caused a change to the IBM statement of integrity to "IBM will > always take action". > > I think the problem here is that some people assume that there are no > integrity problems in IBM code. IBM's statement of integrity clearly > states that if an integrity problem is found and accepted by IBM that > they will take some action. Periodic review of the SMP/E CSI's will > establish whether or not there are any integrity fix's. > > > On 5/31/2019 12:29 PM, Seymour J Metz wrote: > > What convention? The z/OS platform is (mostly) secure. If the user adds > authorized code then it is no longer IBM's platform, and security > vulnerabilities caused by not following the statement of integrity are > vulnerabilities in the installation, not in z/OS. > > > > Now, when *IBM* fails to follow the statement of integrity, that *is* a > z/OS vulnerability, but when is the last time that IBM refused to correct > such an error when it was reported? > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > > > ________________________________________ > > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on > behalf of Wayne Driscoll <wdrisc...@rocketsoftware.com> > > Sent: Thursday, May 30, 2019 5:20 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls > > > > If the trap door is in an APF authorized library, then by convention > it's part of the operating system, and would be considered a platform > issue. Anything that is APF authorized is expected to adhere to the > statement of integrity that z/OS publishes. > > > > Wayne Driscoll > > Rocket Software > > Note - All opinions are strictly my own. > > > > -----Original Message----- > > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On > Behalf Of Seymour J Metz > > Sent: Wednesday, May 29, 2019 2:58 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls > > > >> A single TRAP DOOR code vulnerability pierces the veil of integrity > >> and can be used to compromise the mainframe. Is this a platform > weakness? > > An application with a trap door is an application vulnerability. If > there is a trap door in z/OS itself then that's a platform vulnerability. > I'd be willing to bet a substantial amount that the majority of > penetrations in z/OS are application, configuration, personnel and process > vulnerabilities rather than z/OS vulnerabilities. > > > >> Would you say that the elimination of User Key Common storage is an > >> example of a z/OS change to address a mainframe platform weakness > > Partially. > > > > -- > > Shmuel (Seymour J.) Metz > > > https://nam01.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3&data=02%7C01%7Cwdriscoll%40ROCKETSOFTWARE.COM%7C4ec98728280a4395aab708d6e46ff2fd%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C636947566821955527&sdata=Ggtx2UoZolPoAJZgbcdFshw16B%2B1Yy998xUO7Bts%2FzU%3D&reserved=0 > > > > ________________________________________ > > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on > behalf of Ray Overby <rayove...@comcast.net> > > Sent: Wednesday, May 29, 2019 11:11 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls > > > > In response to "Mistakes, lack of time, lack of control, lack of skills. > > Not a platform weakness." comment: The mainframe platform, z/OS, and > ESM's all rely on integrity to function. A single TRAP DOOR code > vulnerability pierces the veil of integrity and can be used to compromise > the mainframe. Is this a platform weakness? I think so. The platform relies > on all code it runs adhering to certain rules. z/OS could be changed to > better check and enforce those rules. > > > > Would you say that the elimination of User Key Common storage is an > example of a z/OS change to address a mainframe platform weakness? I think > so. > > > > An interesting observation. Thanks. > > > > On 5/29/2019 5:25 AM, R.S. wrote: > >> That's classical FUD. > >> Frightening people. > >> "if an exploit", "if job reads you RACF db", "unintended consequences". > >> What exactly hacking scenario can provide RACF db to the hacker? > >> Yes, I saw APF libraries with UACC(ALTER), UID(0) as standard TSO user > >> attribute, even UPDATE to RACF db. But it's problem of people. > >> Mistakes, lack of time, lack of control, lack of skills. Not a > >> platform weakness. > >> > >> It's typical that assurance/lock/gun salesmen tend to talk about > >> risks, threats and dangers. They create a vision. > >> My English is poor, but I can observe it for two of debaters here. > >> It's visible. I don't like social engineering. > >> > > ---------------------------------------------------------------------- > > 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 > > ================================ > > Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA > 02451 ■ Main Office Toll Free Number: +1 855.577.4323 > > Contact Customer Support: > https://secure-web.cisco.com/1Sx3aGBNDdC-i6lMJ3SYQf94xr7-uJ29cf49tPteg8EumjwYoSxEcUL9FgNj8iG98vHvMgCxxHlQdap3rMDI9ajg0gouV6tUjrZ8eNZENLl3so_IVtpukfpXY3RWMLUWGbP5HsbwqtMUM_p30Gub90nCbulp_yWTJ6VgYs9Qw9YpMRETBrkwbBEJ3n0wM_gI0tTD_cYCB7hl1QvvNQAV8xHFVJFSLkt4psG8MqyHcEycm-QRVwU6mxjGOVrK1P5TpegYPUzvLe2jLh0crwXVN4TJAcQEZDcowXP-q0QFnr87UEbU5pNhDH-dh4pSe1Y9-XiqUDGbnxIKBnHLBVupAOwPnne4jC542DSVZL4U2OLP8O3s1ltJnijdjGck5_uH9HPPwPMZwKqq7r24tD2zCU3mkhddBxA-1UjT0pVXT_SuyXwZ63_-XcT6xeJvpbxTv/https%3A%2F%2Fmy.rocketsoftware.com%2FRocketCommunity%2FRCEmailSupport > > Unsubscribe from Marketing Messages/Manage Your Subscription Preferences > - > http://secure-web.cisco.com/1rQaTFN6UUseMQmfhu8LgDt4pa7bWVwMV3ujEAT-sE6745cgKJQsM4WE4Mgrjh4LYQf38_o0D9J6AJmX4nNX9lEiS4w5dtsoJXuRozhwzOxpcoomhEfVTWoFpwVM-pRqnJ7vXyGBwOHBwC0YMyaM75sNZdfeAWqfweQZqPcvGVBoQSEnt7cWJzMUW6yHxoTqRaFicKx73U_hRCZMrTVRkxmvRtySi_FfEUg7_IOfU2tLPbqMKkxwpuEL_tYPaCcVNdOiFtMFuwCnv7gXs0MPkp7VI7BWHyEqycUopxPeTCWM7sIK_ROXX5fT8h9UkCw7nFnvNA-_t3Yp1YXXlHwYhYcBjuUuKTLKMBwQRcUdA3IYLSXJYbWUHMKgRx7smJkSeA6IAb_1hAsJdc-nIQJ8CSAe8bkvOVZEdmYLEa_ICoP9cFKKAjspLTik8Tv3qMMDE/http%3A%2F%2Fwww.rocketsoftware.com%2Fmanage-your-email-preferences > > Privacy Policy - > http://secure-web.cisco.com/1nklBz-Z6IM8tzCR5_GWdb14WwlulitDUUWn3NUecDqqEpL6uaRXVCw1rCAU8Tx-8wdA1fy1qA-IBLCskPK8q_N0A8DcxbbKkzZfIfGWrpaWIe_Vxuf_ba5BeIo0SIogzgX9w-NCglLXcMW391MdSvPuMzL3RxbEJBvb-WXQ8ksBIgSw4QRldGpBH8plaeDQSTmavtu2upK9k5o6bckJhM_DrExWPThzoxspX6pr3KKENT39lzo8jX-aIHuNlqElyuMFkkQrujdGvV9r7PALjl9vbdTbRZ20Sk7LN-Lomi20ZaHeWR0l76VaiuX2id_oStyiIAmu-lkFIjAHg0H_JojcGFZWHLE3iK1nuoFMJFYd_DAV13_R7aspOr3JM_mk-DVaHBGbXzV1vCj5fWb9eKw9RZ23dJV0Howbc56tyYj-7p1POjY6mnWYYqxY6ZWGY/http%3A%2F%2Fwww.rocketsoftware.com%2Fcompany%2Flegal%2Fprivacy-policy > > ================================ > > > > This communication and any attachments may contain confidential > information of Rocket Software, Inc. All unauthorized use, disclosure or > distribution is prohibited. If you are not the intended recipient, please > notify Rocket Software immediately and destroy all copies of this > communication. Thank you. > > > > ---------------------------------------------------------------------- > > 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 > > > > ---------------------------------------------------------------------- > 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
