> On Jan 27, 2018, at 9:05 AM, Peter Relson <[email protected]> wrote: > > As Rob Scott pointed out, the information displayed is available to any > program. There is no system integrity issue with displaying any of this > information. > Changing that data to be fetch protected (which is the only way to protect > it) would be unacceptably incompatible and would break existing tooling. > > If a customer does not have their APF or PARMLIB or LNKLST or LPA > libraries properly protected, that is a different matter entirely, and is > one of the reasons why there is a RACF health check related to APF. > Restricting DISASM would not gain anything practical, since it is already > only displaying data that the user is permitted to access; restricting it > would just cost an interested party a little bit of extra time. > > The information itself cannot be "exploited". Customer security gaps can > be exploited. > > Security by obscurity (which is what you'd get to a small extent if what > was asked for was implemented) is often only a little better than nothing. > > > I'm quite sure that the request will be declined. > > Peter Relson > z/OS Core Technology Design Peter, I agree with what you are saying completely. However there is a large group of companies out there lying to the Senior Execs and this is one of their angles to get involved in security. I have seen at least two companies that actually lie and then it takes my days/weeks of talking to stop these people from coming in. I am not sure what the answer is but please somebody figure out how to stop these people. Ed
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
