RE: security hole in interactive sql call statement?

I've been loosely following this thread. I still don't see where it is a
security hole. Having LMTCPY(*YES) and giving the programmer access to the
CALL command isn't any different than giving access to STRSQL. CALL in sql
is part of the language. Your security scheme really needs to be reviewed.
I'm sure you'll find many more 'holes'.

Thanks,

Mark

Mark D. Walter
Senior Programmer/Analyst
CCX, Inc.
mwalter@xxxxxxxxxx
http://www.ccxinc.com


|---------+------------------------------->
|         |           "Lim Hock-Chai"     |
|         |           <Lim.Hock-Chai@arch.|
|         |           com>                |
|         |           Sent by:            |
|         |           midrange-l-bounces@m|
|         |           idrange.com         |
|         |                               |
|         |                               |
|         |           11/16/2004 03:22 PM |
|         |           Please respond to   |
|         |           Midrange Systems    |
|         |           Technical Discussion|
|---------+------------------------------->
  
>------------------------------------------------------------------------------------------------------------------------------|
  |                                                                             
                                                 |
  |       To:       "Midrange Systems Technical Discussion" 
<midrange-l@xxxxxxxxxxxx>                                            |
  |       cc:                                                                   
                                                 |
  |       Subject:  RE: security hole in interactive sql call statement?        
                                                 |
  
>------------------------------------------------------------------------------------------------------------------------------|




correct.  Just a bit disappointed with this security hole in strsql.  We'll
probably have to lock programmer out of STRSQL for now.  To secure the JOBD
is not easy because programmer is using the same user ID to access the
production application.  Some of the program is coded to submit the job
with user(*jobd).  In this case, the program will error out.

Programmer cannot create program in production.  Their user profile is
LMTCPB(*YES).  Well, that is if they do not have access to strsql.  If the
programmer use ODBC or JDBC, it will be caught by the Database Server exit
program.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of CWilt@xxxxxxxxxxxx
Sent: Tuesday, November 16, 2004 2:11 PM
To: midrange-l@xxxxxxxxxxxx
Subject: RE: security hole in interactive sql call statement?


Lim,

You problem isn't that the programmer has authority to CLRPFM.  The problem
is the programmer has the authority to the PRODJOBD job description and the
user profile named there.

Note: at security level 40 or 50.  When using SBMJOB USER(*JOBD), the
submitting user must have authority to both the JOBD and the user profile
named in the jobd.  At security level 30 and below, only authority to the
JOBD is needed.


Let me give you another example of how this could be exploited by your
programmers.  All the programmer would need to do is write a CL program to
do the very same thing!  Or better yet, write a program that swaps to the
profile then calls QCMD.

--
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.