Re: STRSRVJOB and database journal entries

I think the point is that the journal records the fact that user BOB
made the change to the file, but that the reality is that programmer
MARY was responsible for the value being what it was.

As other have said, the problem is programmers having authority to debug
production jobs live in the first place.

I've never heard of any auditors who don't recommend preventing
programmers from having such access to the production box. You if chose
to allow such access then you are choosing to allow such access.

Having said that, I suppose a case could be made that MARY's changing of
a variable using debug ought to be able to be logged somewhere if it
isn't already.  But I don't think the log entry should show in BOB's job
or the file journal.  Instead, the audit journal would be a good place
for the info to be logged or even MARY's job log.



Charles Wilt
--
iSeries Systems Administrator / Developer
Mitsubishi Electric Automotive America
ph: 513-573-4343
fax: 513-398-1121
  

-----Original Message-----
From: security400-bounces@xxxxxxxxxxxx 
[mailto:security400-bounces@xxxxxxxxxxxx] On Behalf Of Bob Crothers
Sent: Thursday, June 29, 2006 1:40 PM
To: 'Security Administration on the AS400 / iSeries'
Subject: Re: [Security400] STRSRVJOB and database journal entries

But in the case below, isn't the Journal accurate?

Program reads in database record.  Pgm changes data, hits 
break point before
the update is issued.  Person uses CHGPGMVAR to change one of 
the fields and
then resumes execution.  Record update is done.  Journal 
accurately shoes
what the data was when the record was written/updated...AFTER 
the chgpgmvar!

Not seeing the problem.

Bob

-----Original Message-----
From: security400-bounces@xxxxxxxxxxxx [mailto:security400-
bounces@xxxxxxxxxxxx] On Behalf Of mlazarus@xxxxxxxxxxxxx
Sent: Wednesday, June 28, 2006 12:51 PM
To: security400@xxxxxxxxxxxx
Subject: Re: [Security400] STRSRVJOB and database journal entries

 You are also required to have at least *USE authority to 

the target job's

*USRPRF.  So, if the system in question has a gaping security hole
(allowing the user to debug the job in the first place), I 

wouldn't expect

IBM to log all changes to the journal, especially since 

those changes were

to memory, not yet in the database.

 -mark

Original Message:
-----------------
From: Hall, Philip phall@xxxxxxxx
Date: Wed, 28 Jun 2006 11:31:15 -0500
To: security400@xxxxxxxxxxxx
Subject: Re: [Security400] STRSRVJOB and database journal entries

I started a debug session for another job, using 

chgpgmvar I changed a

program variable that was due to be written to a database 

file and then

I

looked at the journal.
There was no trace of the fact that the job that wrote 

the modified

value

was interrupted in any way.
This looks like a problem, doesn't it?

Only if you put debug versions of your objects into production.


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .



_______________________________________________
This is the Security Administration on the AS400 / iSeries 

(Security400)

mailing list
To post a message email: Security400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/security400
or email: Security400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/security400.

_______________________________________________
This is the Security Administration on the AS400 / iSeries 
(Security400) mailing list
To post a message email: Security400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/security400
or email: Security400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/security400.