RE: security hole in interactive sql call statement?

> Consider STRSQL as the RDBMS equivalent to the command
> line.
> 
> Thus, if you don't allow the programmers access to the
> command line you
> probably shouldn't be allowing access to STRSQL either.

I think I want to disagree with that thought Charles - In the example
presented the database was secure against programmer access (so STRSQL
was no additional threat), it's just that other portions of the OS were
not secured well enough to prevent identity theft of the production
owning User Profile.  That may be a common security exposure but it's
not one that you can lay at the feet of the STRSQL statement, or even
the RDBMS.

JMHO,

jte  

--
John Earl | Chief Technology Officer
The PowerTech Group
19426 68th Ave. S
Seattle, WA 98032
(253) 872-7788 ext. 302
john.earl@xxxxxxxxxxxxx
www.powertech.com 
 

 
This email message and any attachments are intended only for the use of
the intended recipients and may contain information that is privileged
and confidential. If you are not the intended recipient, any
dissemination, distribution, or copying is strictly prohibited. If you
received this email message in error, please immediately notify the
sender by replying to this email message, or by telephone, and delete
the message from your email system.
--

> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
> bounces@xxxxxxxxxxxx] On Behalf Of CWilt@xxxxxxxxxxxx
> Sent: Tuesday, November 16, 2004 12:50 PM
> To: midrange-l@xxxxxxxxxxxx
> Subject: RE: security hole in interactive sql call
> statement?
> 
> Consider STRSQL as the RDBMS equivalent to the command
> line.
> 
> Thus, if you don't allow the programmers access to the
> command line you
> probably shouldn't be allowing access to STRSQL either.
> 
> 
> 
> Charles Wilt
> iSeries Systems Administrator / Developer
> Mitsubishi Electric Automotive America
> ph: 513-573-4343
> fax: 513-398-1121
> 
> 
> > -----Original Message-----
> > From: Lim Hock-Chai [mailto:Lim.Hock-Chai@xxxxxxxx]
> > Sent: Tuesday, November 16, 2004 3:22 PM
> > To: Midrange Systems Technical Discussion
> > 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.
> >
> --
> 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.