On Tue, 27 Mar 2012 11:09:23 -0700, Skip Robinson <jo.skip.robin...@sce.com> wrote:
>The reason I brought up this 'vulnerability' is that we hired a consultant >a while back to look for weaknesses. Of course they were able to logon >with a vanilla userid that had no special authority. And this is what they >did. > >We all spend a lot of time and mental energy focused on how to protect >ourselves from sophisticated attack. We look at APF. We look at SVC >screening. We look at access to sensitive libraries. But this particular >'denial of service' can be accomplished by anyone with a valid userid and >password. And *only* because we lock up users for invalid password >attempts. I'm just sayin'... It's just another form of disaster you have to plan for, Skip. It's easy, for example, to setup an STC that runs with an ID that has SPECIAL, or that is the OWNER of some IDs that have SPECIAL, and have that STC run IKJEFT01 and issue ALTUSER ... RESUME for one or more other IDs that have SPECIAL. If they all get locked out, you just run the STC and that set of IDs is RESUMED. The STC itself will be able to run, even if its ID has been revoked, and so it provides protection against the issue you're suggesting. But yes, you need to be prepared for this, just as for anything that can compromise your system. (Other alternatives exist, by the way, including emergency copies of the RACF database that you can make available in such an emergency situation, but the STC approach is the simplest, in my opinion. Nonetheless, I would also recommend having an emergency RACF DB available, too, but that also goes along with having emergency system residence volumes available.) -- Walt Farrell IBM STSM, z/OS Security Design (for another half-hour or so) ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
