Hi Tony, The last sentence in your email catched my attention " I don't see that it has any close relation to IBM's mainframe OSs and their security issues." I used to have a client that claims his systems are 100% secure. We attacked this client from his partner who was connected over CICS connection. we disabled transactions, letting support understand that they are not running and enable them, and then disabled them again. LOL. Now think that I got control over your HMC (Technically possible, especially with the new Linux architecture) and IPL your system during business hours several times. Again LOL. Absolutely IBM mainframe security issue.
There are few ways to access your HMC. my interest is from BCPII (limited functionality) and the HMC APIs. there also a way using Selenium (witch is less stable as it is sensitive to the html sent by HMC. Anyway, to do this, I need access to an HMC. will you donate yours?! no harm to HMC or systems. ITschak On Sat, Feb 2, 2019 at 2:43 AM Tony Harminc <t...@harminc.net> wrote: > On Fri, 1 Feb 2019 at 09:29, R.S. <r.skoru...@bremultibank.com.pl> wrote: > > > > IMHO the topic is HMC for zPDT. Unfortunately zPDT does not have HMC in > > any form, real or emulated. > > It's not mainframe, it's only emulation. > > No, zPDT *is* a mainframe. It implements a permitted subset of the > architecture documented in the Principles of Operation. > > The HMC is not described in the Principles of Operation. It replaces > the knobs, lights, and switches that provided the operator interface > on older systems. Some of the *functions* performed by the HMC are > architected (and are implemented by zPDT without an HMC), but none of > how it works or what the interface looks like. Here is the only > description of anything like an HMC in the POO: > > "Operator Facilities > The operator facilities provide the functions necessary for operator > control of the machine. Associated with the operator facilities may be > an operator-console device, which may also be used as an I/O device > for communicating with the program. > > The main functions provided by the operator facilities include > resetting, clearing, initial program loading, start, stop, alter, and > display." > > And later: > > "The operator facilities may be implemented on different models in > various technologies and configurations. On some models, more than one > set of physical representations of some keys, controls, and indicators > may be provided, such as on multiple local or remote operating > stations, which may be effective concurrently. " > > All subsequent description of these functions refer to "keys", e.g. > the load key, the start and stop keys, and so on, just as in the S/360 > POO in 1964. > > To the OP's plans... I think doing penetration testing on a box with > no available architectural doc at all, and extremely limited external > doc, might be useful, but how will you even know if it's misbehaving > if there are no specs? Sure, maybe you can force a buffer overrun or > something in the web interface, take over the box (Linux?), and then > what? I don't see that it has any close relation to IBM's mainframe > OSs and their security issues. > > Tony H. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Contiguous Monitoring for Legacy **| * ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
