On Wed, 26 Jun 2013 17:53:00 -0700, Lizette Koehler wrote:
>
>To answer the one question
>
>But GIMZIP/GIMUNZIP require SMP/E RACF authorization (WHY!?) which may be an
>obstacle in some environments.
>
>Because many of us asked for IBM to do this. We found that groups outside of
>Sysprogs were using SMPE to verify fixes. We did not want them altering the
>environment. So the facility classes were created.
>
No. If you read the archives, you will find:
From: Walt Farrell <wfarr...@us.ibm.com>
Date: Wed, 14 Apr 2010 09:46:01 -0500
In the original discussion, it was speculated that IBM obviously did not
understand that one should protect the data sets rather than trying to
protect the program or functions. And that therefore anyone who did have
proper data set protections is safe.
In most cases that is true. In this case it is not (that's why there is an
exposure, and that's why we had the System Integrity APAR IO11698 and its
PTF(s).).
And:
Date: Tue, 13 Apr 2010 09:43:46 -0500
Quoting from IO12263:
...
However, of all the functions described above,
several need to be controlled very carefully. Users who are
granted access to these resources have the potential to
undermine system security regardless of any data set protections
you may have in place. Therefore, they should be as trusted,
for example, as users who have authority to update APF
authorized libraries.
It's pretty clear that there's an integrity flaw in SMP/E, and that IBM chose
not to fix it, but to allow customers to restrict access to SMP/E services.
>Also, I think there were some audit issues within some shops. So this was
>done to also support them.
>
Neither of these rises to the level of a "System Integrity APAR". Use
of SMP/E must be restricted to persons who are trusted not to do
something, without being told what that something is.
Granted, Walt said much later, in response to my goading, that something
such as due caution is sufficient protection. But that's still prety vague.
I imagine that IBM could have introduced a new class of resource
protection of properly narrow scope rather than ""trying" to protect
the program or functions, but felt that doing so would unacceptably
disclose the original flaw.
Yet there's precedent. IBM did very much that sort of thing when OA30897
introduced the BPX.EXECMVSAPF.program_name FACILITY class that made
it glaringly obvious what the defect had been.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
