Craddock, Chris wrote:
We're so used to having access to the keys to the kingdom that we tend
to forget that everyone else doesn't get them. IPCS for example; when
the system captures an SVC dump all of the available data (even fetch
protected data) is going to be laying around in the dump dataset. Give
Joe black hat uncontrolled access to IPCS and he can snoop around to his
heart's content looking under rocks and turning up vulnerabilities the
installation might not even be aware of.

I have not forgotten. When I worked as an application programmer back in DC, we could browse SYS1.PARMLIB. It was no big deal. When I worked as an application programmer in Glendale, we could browse SYS1.PARMLIB. It was no big deal. When I rented time at a service bureau in the valley, we could browse SYS1.PARMLIB. It was no big deal. And, now that I have the proverbial keys to the "kingdom" where I work, everyone can browse SYS1.PARMLIB. It's no big deal.

IPCS is used for processing SYSMDUMP and "transaction" dumps produced by IEATDUMP. These dumps are produced by problem-state, application programs. They do not contain sensitive data. And, as far as I know, IPCS is still the only tool that can intelligently process them.

I agree with you that there is no reason for application programmers to be looking at SVC dumps. But, there have been "sensitive" data sets around since "dirt". IPCS is just another data set browsing tool. Heck, if any user can browse an SVC dump (which is a simple RECFM=FBS format) using ISPF BROWSE, they're liable to see lots of stuff (EBCDIC data) they shouldn't be seeing -- whether they have IPCS access or not!

Can it be controlled by controlling access to dump datasets? Sure. But
again, it depends on somebody knowing what to do and how to do it. If
you're a lowly security administrator you're probably just going to
elect UACC(NONE) for everything you don't understand.

To reiterate, I agree the system's SVC dump inventory should be UACC(NONE) to most people. I never suggested otherwise. Without that, you risk users copying the data via FTP onto a USB flash drive and walking it out of the building!

--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to