Why should you be concerned about key 8 CSA usage? Use of key 8 CSA by
any code (installation or ISV) will eventually lead to an exploit of
that code that will enable your users to upgrade their security
authorization. This upgrade could mean becoming APF authorized or it
could mean an upgrade of their security authority. Note the use of "will
eventually" and not "may".
A trivial example of an exploit is the corruption of the system. This
type of exploit leaves evidence. The goal of the hacker is to upgrade
authorities, obtain something they would not normally have access to (or
update it) without any evidence of access/update. I refer to this as
"good burglar". It is the "good burglar" exploits that you need to be
worried about.
You can argue that none of your users have the expertize to create such
an exploit. You may be right. However, it only takes one person to
develop an exploit and to publish said exploit. It takes a lot less
expertize to implement an exploit once you have the script. You do have
people that can implement the exploit. Lots of them!
Anyone involved with securing a company's assets needs to be concerned
about mainframe software, both the installation/implementation and its
integrity. IBM has an option available as part of the IPL parameters
(ALLOWUSERKEYCSA()) that will disable a known feature, that if enabled,
will allow for an exploit to be developed. Make sure you have documented
reasons for allowing key 8 CSA as the business risk is high.
Ray Overby
Peter Relson wrote:
While it is true that many might not care about someone corrupting a user
key CSA area (even if it potentially compromises their system), that is not
the only integrity exposure that user key CSA can result in.
Allowing unauthorized communication between address spaces (i.e., "covert
channels") is also made possible by this.
By the way much of TSO/E is written to expect Key 8 callers. It always has
been. If it was simply a question of changing one module to return in the
key of the caller instead of the "known" key. So this is not necessarily a
question of getting back in an unexpected state, it is also a question of
not meeting the input requirements for a service.. If it were nicer, the
service would have simply returned or abended. Instead it trusted its
caller to have met those requirements. Are they documented? I have no idea.
Peter Relson
z/OS Core Technology Design
----------------------------------------------------------------------
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
----------------------------------------------------------------------
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
