On Tue, 6 Apr 2010 10:39:22 -0500, Walt Farrell wrote:
>
>Sorry, Radoslaw, but while the implementation may have happened to provide a
>functional enhancement that some of you will find useful, we would not have
>released an APAR that -requires- those migration actions if it were merely
>an enhancement.
>
>We might have introduced such improved function via an APAR, but it would
>have been optional (e.g., "if you want to control function x you can define
>this profile", not "if you want to allow the program to continue working at
>all you must define a profile"). We do not lightly make such changes
>mandatory and force migration actions on our users in the service stream.
>
That was my surmise; apparently others felt only gratitude at the
perceived functional enhancement.
>There is a legitimate integrity exposure involved, and the APAR is properly
>classified as such. We perhaps should have said a bit more in the
>documentation. We're considering whether we can do so, and what we can say
>that will convey the magnitude of our concern (though merely the fact that
>we did this via an APAR with mandatory migration actions should serve as a
>indication that we have serious concerns and there is a legitimate problem
>to address).
>
It might be well to emphasize (if such is the case) that ordinary
RACF data set protections do not suffice to cover the integrity
exposure.
But I would hope for a genuine fix in the future: one that provides
sufficient internal robustness that data set protections will suffice,
as was the (incorrect) perception prior to IO11698. Even if this
is contingent on an enhancement to IEBCOPY such that it, and thus
GIMSMP, might run unauthorized.
Hmmm. Nowadays, IEBCOPY can do considerable work unauthorized,
particularly if it manipulates only PDSEs. Might a statement
be appropriate that if the user runs GIMSMP unauthorized (STEPLIB
could do it), the exposure is mitigated? For example, I believe
that if I omit the WAIT option I can use the UCLIN command with
GIMSMP unauthorized. Should there be a profile allowing all
users to use the UCLIN command provided that GIMSMP is
unauthorized?
(If an unauthorized program can threaten integrity, there's a defect
more drastic than has been suggested in this thread so far.)
S99WTDSN? That's the only cause of failures other than IEBCOPY
when I've inadvertently run GIMSMP unauthorized. Could that be
handled by a new facility class resource allowing selected programs
to set S99WTDSN even when invoked unauthorized? Would this require
DYNALLOC to issue SAF calls to query authorization? Is allocation
able to issue SAF calls?
I've read the APAR fix comments and ++HOLD:
o There are numerous references to "the section above titled
'Authorizing Use of SMP/E Commands and Services'." There is no
such titled section above nor anywhere else in the APAR fix.
o I see:
To allow current SMP/E users to continue executing SMP/E
functions, you must define the appropriate facility class
resources in the active security manager and grant all
userids that should be allowed to invoke the protected
SMP/E functions read access to those resources.
The key word is "should". Let's remember that. And:
although not recommended by IBM, it is possible to define
the profiles with UACC(READ) and AUDIT(ALL(READ)) to help
identify and log all userids that currently invoke SMP/E
functions and will require eventual definition in the
profiles' access list. After sufficient analysis has
occurred and the access list has been updated, then
profiles should be changed to UACC(NONE).
OK. That tells what IBM doesn't recommend. What _does_ IBM
recommend as a technique to identify users who "should be allowed
to invoke the protected SMP/E functions"? Should that be all
"current SMP/E users"? We have a development shop, like Bob
Shannon's. To date, "current SMP/E users" means all programmers
able to create data sets and run batch jobs that modify those
data sets. To date, we have relied only on data set protection.
Apparently data set protection no longer suffices (never did;
only we didn't know it). What should be our new criteria?
In the currently popular phrase, might SMP/E misuse allow "premature
termination or execution of arbitrary code, with possible leverage to
escalation of privileges", regardless of data set protection? (This
is typical of integrity flaws, once exploited.)
-- gil
----------------------------------------------------------------------
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
