Re: Friday question: ISPF Statistics Manipulation

[Paul Gilmartin]

On Mon, 10 Jul 2017 09:27:07 -0500, Walt Farrell wrote:

>On Mon, 10 Jul 2017 00:49:13 -0500, Barbara Nitz  wrote:
>
>>That's what I mean by 'used as evidence'. And I wondered if it is just my 
>>ignorance or if there really is no way (as I suspected) to 
>>prevent unauthorized changing of the statistics. 
>
>There is no way to do that without installing an add-on product.
> 
Such a product would need to have many tentacles in the system.
I could imagine unloading a PDS with IEBCOPY; tweaking the stats
in the PDSU directory image, and reloading.  It would need to prevent
that.  Where might it intervene to do so?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Friday question: ISPF Statistics Manipulation

[Don Leahy]

I once wrote a blog on this topic on the company's internal social media
site.  I called it "Lies, damned lies and Member List Statistics". :-)

On Mon, Jul 10, 2017 at 10:27 AM Walt Farrell 
wrote:

> On Mon, 10 Jul 2017 00:49:13 -0500, Barbara Nitz  wrote:
>
> >That's what I mean by 'used as evidence'. And I wondered if it is just my
> ignorance or if there really is no way (as I suspected) to
> >prevent unauthorized changing of the statistics.
>
> There is no way to do that without installing an add-on product.
>
> --
> Walt
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Friday question: ISPF Statistics Manipulation

[Walt Farrell]

On Mon, 10 Jul 2017 00:49:13 -0500, Barbara Nitz  wrote:

>That's what I mean by 'used as evidence'. And I wondered if it is just my 
>ignorance or if there really is no way (as I suspected) to 
>prevent unauthorized changing of the statistics. 

There is no way to do that without installing an add-on product.

-- 
Walt

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Friday question: ISPF Statistics Manipulation

[Barbara Nitz]

>Evidence of what Barb ? Don't hang anyone on this evidence. Anyone with
>update access to the pds can update this field..

My colleague asked me on Friday if it is possible to fake the ISPF Statistics. 
I already knew that you can write them yourself using something other than 
ISPF. So we tested how easy it would be to change them. Apparently in a former 
life my colleague was blamed for an error because his name was in that 
statistics field as the one who last changed, and he had never seen that member 
or that content before.

Last year I was asked if the powers that be can use ISPF statistics as tracking 
who had changed a source code library (on a regular basis, and please no plugs 
for source control products!). I pointed them to ISPF 3.5 then and to the fact 
that STATS OFF will delete existing statistics. Fortunately my answer 
discouraged them enough so they didn't follow this scheme any further. I 
nevertheless do have STATS ON in the global (system) ISPCCONF. Which you can 
not use by using your own, preconcatenated version.

That's what I mean by 'used as evidence'. And I wondered if it is just my 
ignorance or if there really is no way (as I suspected) to prevent unauthorized 
changing of the statistics. 

Thanks to all who answered.

Barbara

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Friday question: ISPF Statistics Manipulation

[Kenneth J. Kripke]

Friday question: ISPF Statistics Manipulation:

A product that tracks and controls access to members within a PDS is
eventACTION.  

Granted, it doesn't prohibit someone from changing the ISPF stats for a
member, 

But, if the library is controlled, It will prohibit updates unless
authorized.  

It will also track and report accesses and the nature of access.  

 

Sincerely;  

 

Kenneth J. Kripke

 

k.kri...@comcast.net 

 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Friday question: ISPF Statistics Manipulation

[CM Poncelet]

If it helps, this thing updates a PDS directory using STOW. It will need
some tweaking to update the USERDATA (check the PDS directory map).
Cheers, CP
 

MEMBER NAME  ALIAS
*
* THIS PROGRAM ALIASES ENTRIES IN A PARTITIONED DATASET.
* MEMBERS MAY HAVE FIXED OR VARIABLE LOGICAL RECORD LENGTH (FB OR VB).
* MEMBER NAME AND ALIAS MUST BE SUPPLIED VIA SYSIN CARD.
*
*
* FORMAT OF SYSIN CARD IS
*   'MEMBER=@@...@,ALIAS=@@...@ '
* WHERE '@@...@' REPRESENTS A 1 TO 8 CHAR VALID MEMBER/ALIAS NAME
* AND WHERE ANYTHING (INCLUDING COMMENTS) (EXCEPT MEMBER= //  /*) MAY
* PRECEDE THE 'MEMBER=' START OF CARD DATA
* AND WHERE THE END OF CARD DATA (AFTER ALIAS NAME) MUST BE A BLANK.
* NOTE THAT THE COMMA, AFTER THE MEMBER NAME, IS MANDATORY,
* EACH SEPARATE ALIAS REQUEST MUST BE ON A SEPARATE CARD
* AND THE CARDS ARE FIXED RECL=80 WITH DATA IN COLS 1 TO 72 INCLUSIVE,
* DECLARED VIA DDNAME SYSIN.
*
* MEMBER NAMES MUST BE IN ASCENDING ALPHABETICAL ORDER.
*
* INVALID SYSIN CARDS ARE IGNORED.
*
* ALIASES SUCCESSFULLY ADDED ARE LISTED UNDER DDNAME=REPORTS OUTPUT.
*
* CREATED: CHRIS PONCELET12/10/88
*
***
*
 PRINT  NOGEN
ALIASPDS CSECT START CONTROL SECTION
*
* PASSING  THE 'NEXT' LABEL AS A PARAMETER TO THE 'READREC' MACRO
*
R0   EQU   0REDEFINE REGISTERS
R1   EQU   1
R2   EQU   2
R3   EQU   3
R4   EQU   4
R5   EQU   5
R6   EQU   6
R7   EQU   7
R8   EQU   8
R9   EQU   9
R10  EQU   10
R11  EQU   11
R12  EQU   12
R13  EQU   13
R14  EQU   14
R15  EQU   15
*
***
** MACROS *
*
 MACRO
   READREC 
   GET  READREC MACRO
 MVC   INPUT(80),0(R1) MOVE FROM BUFFER TO INPUT AREA
 MEND
*
 MACRO
   WRITEREC
   PUT   REPORTS,OUTPUT  WRITEREC MACRO
 MEND
*
*** END OF MACROS *
***
*
**
*** INITIAL PROCESSING ***
**
*
* NOTE: SAVE ALL REGISTERS ON ENTRY, AT 18 FULLWORDS STARTING AT
*   ADDRESS GIVEN IN R13 - USING STORE MULTIPLE.
*   THEN USE R14 (SAVED, THAT IS) TO RETURN CONTROL AFTER EXECUTION
*   OF THIS PROGRAM (AFTER RELOADING USING LOAD MULTIPLE.)
*
BEGINSTM   R14,R12,12(R13) SAVE REGISTERS 14->12 TO OFFSET 12
 BALR  R11,R0  LOAD CURRENT LOCATION INTO R11
 USING *,R11,R3DEFINE R11 + R3 AS BASE REGISTERS
NAMEOFT  EQU   NAME-*
TTROFT   EQU   TTR-*
ALIASOFT EQU   ALIAS-*
KOFT EQU   K-*
COFT EQU   C-*
INPUTOFT EQU   INPUT-*
 LAR3,*-4+4096
 STR13,SAVER13 FREE REGISTER 13 BY SAVING
 LAR13,SAVEBLK LOAD MY SAVEAREA'S ADDRESS INTO R13
*
***
 START OF PROGRAM CODE PROPER *
***
*
 OPEN  (SYSIN,(INPUT))
 L R4,=F'64'   FOR COUNTING ¬> 64 CARDS
 LRR9,R11  FOR INDEXING MEMBER NAMES + BASE
 LAR9,0(,R9)   CLEAR TOP 8 BITS
 S R9,=F'14'
 LRR10,R11 FOR INDEXING ALIAS NAMES + BASE
 LAR10,0(,R10) CLEAR TOP 8 BITS
 S R10,=F'8'
*
* DO UNTIL THERE ARE NO MORE SYSIN RECORDS
*
NEXT READREC SYSIN
 LRR5,R11  USE R5 AS PSEUDO BASE REG
 LAR5,0(,R5)   CLEAR TOP 8 BITS
 SRR6,R6   USE R6 AS INDEX INCREMENT
 LAR6,1(,R6)
 LRR7,R11  USE R7 AS INDEX UPPER LIMIT
*
*  'MEMBER=' = 7
*  ',' = 1
*  'ALIAS=' = 6
*   = 1 MIN
*   = 1 MIN
*  OFFSET = POSITION - 1
*  72-7-1-6-1-1-1=55
*
 LAR7,55(,R7)  SYSIN CARD UP TO COL 72 MAX.
*
* FIND 'MEMBER=' STRING IN CURRENT SYSIN CARD.
*
FINDMCLI   INPUTOFT(R5),C'M'   LOOK FOR CHAR 'M' AT CURRENT POS.
 BECHK1A
 BXLE  R5,R6,FINDM IF NOT FOUND TRY NEXT POSITION UP
 B NOTFND
CHK1ACLC   INPUTOFT(7,R5),=C'MEMBER=' IS IT 'MEMBER='?
 BEOK1
 BXLE  R5,R6,FINDM NO: START AGAIN FROM NEXT POS. UP
 B NOTFND
OK1  LAR5,7(,R5)   YES: SHIFT UP TO READ NAME
 ST

Re: Friday question: ISPF Statistics Manipulation

[Joel C. Ewing]

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   jcew...@acm.org 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Friday question: ISPF Statistics Manipulation

[Steve Horein]

On Fri, Jul 7, 2017 at 8:05 AM, 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.
>
> Barbara
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

I hijack the USERID field often (using "G" next to the member in ISPF, or
"Z" with DSC/IPT) to put additional info about the member.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Friday question: ISPF Statistics Manipulation

[Beverly Caldwell]

Evidence of what Barb ? Don't hang anyone on this evidence. Anyone with
update access to the pds can update this field..
I do it all the time to source code libraries to set the version level in
the uid field.

I can't think how you would do it. The ds name in the RACF call will not
contain a member name just the pds name as it is the directory which is
being updated.

Maybe an ISPF exit ?

On Fri, Jul 7, 2017 at 8:05 AM, 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.
>
> Barbara
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Friday question: ISPF Statistics Manipulation

[Paul Gilmartin]

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Friday question: ISPF Statistics Manipulation

[Dana Mitchell]

Free PDS command on CBT Tape can do this, see the ATTRIB subcommand:

 SYNTAX -   
   ATTRIB  member  AMODE24/AMODE31/AMODE64/AMODEANY 
   AUTH/NOAUTH  or  APF/NOAPF   
   DC/NODC  
   EDIT/NOEDIT  
   ENTRY(externalname)  
   EXEC/NOEXEC  
   LOADONLY/NOLOADONLY  
   PAGE/NOPAGE  
   REFR/NOREFR  
   RENT/NORENT  
   REUS/NOREUS  
   RLDFIX/NORLDFIX  
   RMODE24/RMODEANY 
   SSI(hxdata)/NOSSI
   UNALIAS  
   NONE / ADDSTATS  
   VER(nn) / MOD(mm) / ID(who) / USERID(who)
 CREATED(mm/dd/yy) MODIFIED(mm/dd/yy)   
 LAST(mm/dd/yy) TIME(hhmm) SECS(ss) 
   LKEDDATE/NOLKEDDATE  
   ALIASINFO/NOALIASINFO
  

As far as I know the vendor version 'StarTool' still does this too, I haven't 
worked with that in years though.

Dana

On Fri, 7 Jul 2017 16:56:09 +0200, R.S.  wrote:
>
>...except the dates.
>Sometimes I want to change the date (just to prepare "installation
>package", no cheating).
>Is there any method to change the dates?
>I mean set the date to something like 1999-09-09, not just reset.
>
>
>--
>Radoslaw Skorupka
>Lodz, Poland
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Friday question: ISPF Statistics Manipulation

[Ed Jaffe]

On 7/7/2017 11:07 AM, Paul Gilmartin wrote:


I'm curious what else might lurk in that "PDSE AX cell".  Perhaps an
immutable creator ID?

8 characters in z/OS 2.3?


Note that 8-byte userid support was added to MVS way back in 1995. Only 
TSO/E lagged behind...


.*  $04=OW13376  HBB4420  950329  PD81XZ:  Add ASXBUSR8

ASXBUSR8 DS0CL88-byte version of ASXBUSER @04A
ASXBUSER DSCL7 -   USER ID FOR WHICH THE JOB OR SESSION
*  IS BEING EXECUTED  (MDC306) @Z40RP9A
 DSB - Last byte of ASXBUSR8. ASXBSECR @04A
*  and ASXBSFLG are deleted

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Friday question: ISPF Statistics Manipulation

[Paul Gilmartin]

On Fri, 7 Jul 2017 13:17:52 -0400, Tony Harminc wrote:
>
>It will surprise me if IBM hasn't given some serious thought to this
>for PDSEs. A formally managed interface to PDSE member metadata,
>subject to RACF etc. controls, would be quite doable. Of course it
>would be tricky to make it compatible, but since you already can't do
>EXCP to a PDSE, it might not be so hard to capture STOW and subject it
>to security controls. Or provide a brand new member metadata API that
>is unrelated to the existing directory userdata.
>
In:
z/OSIBM Network File System Guide and Reference
Version 2 Release 2
SC23-6883-02

I read:
Time stamps for PDSs and PDSEs
   ...
2. MVS maintains the PDSE member create/change time stamp (mtime) in the PDSE 
AX cell.
   The Server uses a FileAccessMethodService (FAMS) call to retrieve/save the 
member
   attributes (containing time stamps) from/to the PDSE AX cell.

It's hard to learn more about this FAMS thingy.  I suspect IBM doesn't want us 
to know.

One interesting thing is that when a PDSE is NFS mounted on a Solaris
system, the "ls -l" command shows file timestamps with microsecond
granularity for members never touched by ISPF.

If I migrate that PDSE and recall it, those timestamps are preserved.

If I copy that PDSE with IEBCOPY, the timestamps are reset to the time
that I performed the copy.

I'm curious what else might lurk in that "PDSE AX cell".  Perhaps an
immutable creator ID?

8 characters in z/OS 2.3?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Friday question: ISPF Statistics Manipulation

[Brenton, Ren]

lmdate

  mtime = flmtime

  csize = Strip(flcnorc)

  isize = Strip(flinorc)

  user  = fluser

  cdate4= flc4date

  mdate4= flm4date



  If Datatype(csize) = 'NUM';Then do



 If datatype(isize) = 'NUM';Then do

mrecs = csize - isize

 End

 Else mrecs = 0

   End

   Else mrecs = 0



   If mrecs < 1;Then do

  mrecs = 1

   End





Return



Update_Stats:



   Address "ISPEXEC" "LMMSTATS DATAID("dataid01")   MEMBER("mbrnam")",

 "VERSION("ver1")",

 "MODLEVEL("mod1")  CREATED("cdate") MODDATE("mdate")",

 "MODTIME("mtime")  CURSIZE("csize") INITSIZE("isize")",

 "MODRECS("mrecs")   USER("user") CREATED4("cdate4")",

 "MODDATE4("mdate4")"

   cc = rc



   If cc <> 0;Then Signal Err_LMMSTATS_B



Return



Err_Missing_PDS_NAME:



   zerrsm = ''

   zerrlm = 'The PDS_NAME is missing.',

'This function requires a PDS_NAME and a MEMBER name.'

   cc = 16



Signal Err_Exit



Err_Missing_MBRNAM:



   zerrsm = ''

   zerrlm = 'The MEMBER NAME is missing.',

'This function requires a MEMBER name.'

   cc = 16



Signal Err_Exit



Err_LMINIT:



   zerrsm = ''

   zerrlm = 'An error, RC =' cc,

'occurred trying to:',

'"ISPEXEC" "LMINIT DATAID(DATAID01) DATASET('pds_nam') ENQ(SHRW)"',

'The following messages apply:' zerrsm zerrlm



Signal Err_Exit



Err_LMMLIST2:



   zerrsm = ''

   zerrlm = 'An error, RC =' cc,

'occurred trying to:',

'"ISPEXEC" "LMINIT DATAID(DATAID01) DATASET('pds_nam') ENQ(SHRW)"',

'The following messages apply:' zerrsm zerrlm



Signal Err_Exit



Err_Exit_LMMLIST:



   zerrlm = 'An LMMLIST Error has occurred. Dataset is:' pds_nam'.',

'DATAID01 is' dataid01', MOD is' mbrnam'.',

'Return code is:' cc,

'The following messages apply:' zerrlm zerrsm

   zerrsm = ''



Signal Err_Exit



Err_LMMSTATS_B:



   zerrlm = 'An LMMLIST Error has occurred. Dataset is:' pds_nam'.',

'DATAID01 is' dataid01', MOD is' mbrnam'.',

'Return code is:' cc,

'The following messages apply:' zerrlm zerrsm

   zerrsm = ''



Signal Err_Exit



Err_Alloc:



   zerrsm = ''

   zerrlm = 'An error, RC =' cc,

'occurred trying to allocate DD' dd_nam 'to' pds_nam 'as follows:',

"ALLOC FILE("dd_nam") DA("pds_nam") SHR"



Signal Err_Exit



Err_Alloc_OLd:



   zerrsm = ""

   zerrlm = "Allocation error on:",

"ALLOC FILE("fi_nam") DA('"pds_nam_mem"') OLD"



Signal Err_Exit



Err_Exit:



   zerrlm = zerrlm 'This message was issued from F@UPDSTA.',

   'Parms were: pds_nam =' pds_nam', and member =' mbrnam'.'



   If type = 'BATCH';Then Say zerrlm

   Else Address "ISPEXEC" "SETMSG MSG(ISRZ002)"



Signal Z99







Ren

Ext 1448



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: Friday, July 07, 2017 11:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday question: ISPF Statistics Manipulation





IMPORTANT!! - External Content - Please use caution.







John McKown wrote:



>​There are no control possible for this.



There are some control. ISPCCONFIG can be used to FORCE stats using module 
ISPCFIGU, but hahahahahaha, override it with option =3.5 as the OP said.





>The ISPF statistics are simply data in the "user data area" portion of a 
>member's directory entry.



True. Those stats are just screen ornaments. Beautiful, but useless... They're 
really speedhumps on a racetrack...





>Bottom line: ISPF statistics are NOT ANY GOOD for any kind of security 
>orauditing purposes. User can update them easily using 3.5 and you can't stop 
>them.



Activate logging using SMF and use RACF to monitor member usage. Not the 
overhead worth...



Groete / Greetings

Elardus Engelbrecht



--

For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with the message: 
INFO IBM-MAIN
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Friday question: ISPF Statistics Manipulation

[Walt Farrell]

On Fri, 7 Jul 2017 16:56:09 +0200, R.S.  wrote:

>W dniu 2017-07-07 o 15:29, Lizette Koehler pisze:
>> As far as I know, the statistics have always worked that way.  That as long 
>> as you had the ability to edit (change/alter/del/create) the PDS you could 
>> use 3.5 to change the ID field to anything you like.
>
>...except the dates.
>Sometimes I want to change the date (just to prepare "installation
>package", no cheating).
>Is there any method to change the dates?
>I mean set the date to something like 1999-09-09, not just reset.

That may require a program of your own that uses STOW.

-- 
Walt

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Friday question: ISPF Statistics Manipulation

[Tony Harminc]

On 7 July 2017 at 09:30, John McKown  wrote:

> There are no control possible for this. The ISPF statistics are simply
> data in the "user data area" portion of a member's directory entry.
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.f54mc00/ispmc28.htm
>
> how a PDS directory entry is formatted:
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.idad400/pdsd.htm
>
> Binyamin mentioned ACF2, but a regular program can use the STOW macro to
> update a PDS directory entry. In fact, must be able to in order to add,
> delete, or update (other than "in place") a member. I doubt, that even ACF2
> has any control to disallow updating the directory entry of a member in a
> DSN to which the user has update authority.

It will surprise me if IBM hasn't given some serious thought to this
for PDSEs. A formally managed interface to PDSE member metadata,
subject to RACF etc. controls, would be quite doable. Of course it
would be tricky to make it compatible, but since you already can't do
EXCP to a PDSE, it might not be so hard to capture STOW and subject it
to security controls. Or provide a brand new member metadata API that
is unrelated to the existing directory userdata.

> Bottom line: ISPF statistics are NOT ANY GOOD for any kind of security or
> auditing purposes. User can update them easily using 3.5 and you can't stop
> them. You would need a product such as PDSMAN
> https://docops.ca.com/ca-pdsman/7-7/en/administrating/what-is-pdsman

How does PDSMAN or similar help with this? By avoiding ever having
direct access to the PDS?

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Friday question: ISPF Statistics Manipulation

[Elardus Engelbrecht]

John McKown wrote:

>​There are no control possible for this. 

There are some control. ISPCCONFIG can be used to FORCE stats using module 
ISPCFIGU, but hahahahahaha, override it with option =3.5 as the OP said.


>The ISPF statistics are simply data in the "user data area" portion of a 
>member's directory entry.

True. Those stats are just screen ornaments. Beautiful, but useless... They're 
really speedhumps on a racetrack...


>Bottom line: ISPF statistics are NOT ANY GOOD for any kind of security 
>orauditing purposes. User can update them easily using 3.5 and you can't stop 
>them. 

Activate logging using SMF and use RACF to monitor member usage. Not the 
overhead worth...

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Friday question: ISPF Statistics Manipulation

[R.S.]

W dniu 2017-07-07 o 15:29, Lizette Koehler pisze:

As far as I know, the statistics have always worked that way.  That as long as 
you had the ability to edit (change/alter/del/create) the PDS you could use 3.5 
to change the ID field to anything you like.


...except the dates.
Sometimes I want to change the date (just to prepare "installation 
package", no cheating).

Is there any method to change the dates?
I mean set the date to something like 1999-09-09, not just reset.


--
Radoslaw Skorupka
Lodz, Poland




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.
   


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Friday question: ISPF Statistics Manipulation

[Longabaugh, Robert E]

The 3.5 option has been able to manipulate member stats since I first saw "SPF" 
somewhere around 1980.   The most useful function I have found is being able to 
delete member statistics.  This is one way you can save a new member when the 
directory is out of space.  It is usually my second choice after trying "STATS 
OFF" on the new member I am editing.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Friday, July 07, 2017 8:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday question: ISPF Statistics Manipulation

CAUTION: This email originated from outside of CA. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.


On Fri, Jul 7, 2017 at 8:05 AM, Barbara Nitz <nitz-...@gmx.net> 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.
>

​There are no control possible for this. The ISPF statistics are simply data in 
the "user data area" portion of a member's directory entry.
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ibm.com_support_knowledgecenter_en_SSLTBW-5F2.1.0_com.ibm.zos.v2r1.f54mc00_ispmc28.htm=DwIFaQ=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0=_pjUpH7SxKBkB6gBZH_r7a7W1q59Nzy5lPxFUOMH-UM=4Nkmg4zgV8bvaZuf3pzQfmzQUNagnQX66musH9Nq2lY=gmQ7AOx3yGz72ixAbnTxOfFf3gqZ-Z7ugt_coMfx1DM=

how a PDS directory entry is formatted:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ibm.com_support_knowledgecenter_en_SSLTBW-5F2.1.0_com.ibm.zos.v2r1.idad400_pdsd.htm=DwIFaQ=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0=_pjUpH7SxKBkB6gBZH_r7a7W1q59Nzy5lPxFUOMH-UM=4Nkmg4zgV8bvaZuf3pzQfmzQUNagnQX66musH9Nq2lY=f80EEL_LypcCjkKc6P-Yiaqk55B20TIKjP7-qQsnRyo=

Binyamin mentioned ACF2, but a regular program can use the STOW macro to update 
a PDS directory entry. In fact, must be able to in order to add, delete, or 
update (other than "in place") a member. I doubt, that even ACF2 has any 
control to disallow updating the directory entry of a member in a DSN to which 
the user has update authority.


Bottom line: ISPF statistics are NOT ANY GOOD for any kind of security or 
auditing purposes. User can update them easily using 3.5 and you can't stop 
them. You would need a product such as PDSMAN 
https://docops.ca.com/ca-pdsman/7-7/en/administrating/what-is-pdsman


>
> Barbara
>
>

--
Veni, Vidi, VISA: I came, I saw, I did a little shopping.

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Friday question: ISPF Statistics Manipulation

[John McKown]

On Fri, Jul 7, 2017 at 8:05 AM, 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.
>

​There are no control possible for this. The ISPF statistics are simply
data in the "user data area" portion of a member's directory entry.
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.f54mc00/ispmc28.htm

how a PDS directory entry is formatted:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.idad400/pdsd.htm

Binyamin mentioned ACF2, but a regular program can use the STOW macro to
update a PDS directory entry. In fact, must be able to in order to add,
delete, or update (other than "in place") a member. I doubt, that even ACF2
has any control to disallow updating the directory entry of a member in a
DSN to which the user has update authority.


Bottom line: ISPF statistics are NOT ANY GOOD for any kind of security or
auditing purposes. User can update them easily using 3.5 and you can't stop
them. You would need a product such as PDSMAN
https://docops.ca.com/ca-pdsman/7-7/en/administrating/what-is-pdsman


>
> Barbara
>
>

-- 
Veni, Vidi, VISA: I came, I saw, I did a little shopping.

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Friday question: ISPF Statistics Manipulation

[Lizette Koehler]

As far as I know, the statistics have always worked that way.  That as long as 
you had the ability to edit (change/alter/del/create) the PDS you could use 3.5 
to change the ID field to anything you like.

I typically change it to BASE and then as I update members, I can see what has 
been altered.

And I think there has never been a separation in ISPF between the Directory 
entries and the PDS so there are no security controls over who can alter it.  
Everything is controlled at the dataset level.  So I can change the Stats in 
any PDS for any member I have UPDATE access to.  I would have to check on READ 
access.

You can delete the statistics just as easily as create them.  And deleting 
statistics is an easy way to provide room in the directory to add more members 
if you do not have a tool to increase the Directory entire of a PDS.

There are SAF products like TSS that can secure at the MEMBER level, but I do 
not think RACF can do that.  And maybe that function in TSS may provide the 
ability to protect the statistics for that member.  But that would be a 
question for Top Secret.


Lizette




> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Barbara Nitz
> Sent: Friday, July 07, 2017 6:06 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Friday question: ISPF Statistics Manipulation
> 
> 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.
> 
> Barbara

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Friday question: ISPF Statistics Manipulation

[Binyamin Dissen]

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.

As the statistics can be manipulated by STOW/EXCP outside of ISPF, having
WRITE authority to the dataset is enough to change it.

I have heard that acf2 has a means of altering the DEB of a PDS to prevent
access outside of certain member areas, but have not tried it.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Friday question: ISPF Statistics Manipulation

[Barbara Nitz]

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.

Barbara

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN