RE: Losing Authority to a file in Batch

[rob@xxxxxxxxx]

Good point.  Documenting the situation may be needed.  We did have one 
vendor that had several programs owned by QSECOFR.  All's one did was CALL 
QCMD.  Evidently he tired of talking to IS folks and would have the 
accounting people fix problems.  Stuff like this is probably what got the 
auditors thinking the way they do.

Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





Jim Damato <jdamato@xxxxxxxxxxxxxxxxx> 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
01/26/2004 04:52 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
"'Midrange Systems Technical Discussion'" <midrange-l@xxxxxxxxxxxx>
cc

Fax to

Subject
RE: Losing Authority to a file in Batch






We end up justifying a few valid or unavoidable instances of 
USRPRF(*OWNER)
on a case by case basis and documenting them in the audit response.

Allowing remote commands is another great audit point, if you have 
competent
auditors.  Ideally you'd have a security scheme that addresses ALL
interfaces.

This is one case where I actually like the Unix/Oracle model.  The Oracle
database user doesn't have to have a corresponding Unix user, and a Unix
user doesn't need have inherent rights to databases.  Giving someone 
access
to the database through an Oracle user and the Oracle listener doesn't 
mean
you have to figure out and control the user's capabilities on the OS side 
of
the server.

For years I've seen folks use USRPRF(*OWNER) to deal with their lack of
understanding of OS/400 security.  I've also seen USRPRF(*OWNER) used as
part of good security design.  If you can document the purpose behind
USRPRF(*OWNER) properly it's easy to keep the auditors happy.  Typically
folks respond with "because we have to" or "the software company did that"
or "I think Charlie set it up that way back on the System/38".

-Jim

James P. Damato
Manager - Technical Administration
Dollar General Corporation
<mailto:jdamato@xxxxxxxxxxxxxxxxx>



-----Original Message-----
From: rob@xxxxxxxxx [mailto:rob@xxxxxxxxx]
Sent: Monday, January 26, 2004 1:14 PM
To: Midrange Systems Technical Discussion
Subject: RE: Losing Authority to a file in Batch


Then what a bunch of morons!  I suppose they prefer that the users have 
access to the files themselves so that they can update them from any PC 
application versus being locked into the authorized programs?  Guess it 
makes the auditors feel better if the users can run the following:

C:\>rmtcmd //gdisys dltf deleteme2/myfile

IBM iSeries Access for Windows
Version 5  Release 3  Level 0
Submit Remote Command
(C) Copyright IBM Corporation and Others 1984, 2003.  All rights reserved
U.S. Government Users Restricted Rights - Use, duplication or disclosure
  restricted by GSA ADP Schedule Contract with IBM Corp.
Licensed Materials - Property of IBM

CPC2191 - Object MYFILE in DELETEME2 type *FILE deleted.

C:\>

Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





Jim Damato <jdamato@xxxxxxxxxxxxxxxxx> 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
01/26/2004 01:53 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
"'Midrange Systems Technical Discussion'" <midrange-l@xxxxxxxxxxxx>
cc

Fax to

Subject
RE: Losing Authority to a file in Batch






Have you ever had to expose your system to a security audit?  Programs
compiled as USRPRF(*OWNER) are among the first things to go.

-Jim

James P. Damato
Manager - Technical Administration
Dollar General Corporation
<mailto:jdamato@xxxxxxxxxxxxxxxxx>

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.