|
That depends on how you look at it. Most of the commonly use ibm commands are ship with *public *use. That, I assumed, is why in the user profile we have an option to say LMTCPB(*YES). The profile is still authorized to use CALL command but because of the LMTCPB(*YES), he/she cannot CALL any program thru command line. Perfect design, because even though user cannot CALL any program at the command line, he/she still can use production applications that use CALL command (in CL or RPG). I just want to authorize user to STRSQL. However, by doing this, I'm now open up any command. -----Original Message----- From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of MWalter@xxxxxxxxxxxxxxx Sent: Tuesday, November 16, 2004 2:29 PM To: Midrange Systems Technical Discussion Subject: 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. -- 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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.