On 07/07/2017 03:50 PM, Paul Gilmartin wrote:
> On Fri, 7 Jul 2017 08:05:42 -0500, Barbara Nitz wrote:
>
>> A colleague of mine just asked me if ISPF statistics in a data set,
>> especially the USERID field, can be manipulated. We used ISPF 3.5 and we
>> were both astonished that I was easily able to fake a userid as the one who
>> last changed a member (testing in my own dataset, of course).
>>
>> This immediately raised the question for me if there is any RACF control
>> that would prevent this type of manipulation, especially since the userids
>> in those statistics are widely used as evidence. Does anyone know if there
>> are such RACF controls? A quick search in the ISPF books didn't turn up any
>> hint.
>>
> Use UNIX files rather than PDS members. The analogous "chown" is a
> privileged command.
>
> -- gil
>
>
But when using UNIX files, you likely have to allow for
update/maintenance by more than one user -- pretty common for most
business data since every functional role should be covered by backup
personnel to allow for vacation days and unexpected sick days. That
would normally mean you have to permit UNIX file updates via the group
ID, not the owner ID, which also means you can't be sure the UID owning
the file is the last updater. If a non-owner accesses and updates the
UNIX file via group ID write access rather than by deleting and
re-creating a new file with his own UID as owner, the file owner still
reflects the original owner, not the last updater. You can get around
that problem by only allowing indirect updates done by some special
utility that insures last updater get plugged as the owning UID, but if
you have to go to that effort then you could play the same games with a
PDS[E] -- disallow direct update access that could alter directory stats
and only allow Program-Controlled update access to the PDS[E] via a
special utility that checks for a valid updater userid in the directory
stats before doing the update.
If you can somehow force STATS ON, ISPF captures the last updater of the
member in the directory stats, but there obviously is also a need for
some way to restrict who has the authority to manually alter the stats.
Can't SMF records now track PDS[E] updates at the member level? Unless
manual ISPF directory stat changes can be restricted, ISPF stats should
be taken as suggestive but less conclusive than SMF data. But, finding
the relevant SMF records can also be an expensive task when the number
of SMF records is very large.
Joel C. Ewing
--
Joel C. Ewing, Bentonville, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
