|
> Unless the application is designed to allow it, there is > no way for user to assume the identity of another user if > LMTCPB is (*YES). Sure there is - in fact there are multiple ways - here is one that you pointed out yourself... > > Well, wrong. In the STRSQL session, programmer can do > > CALL QCMDEXC('sbmjob cmd(clrpfm xxx) jobd(PRODJOBD) > > user(*JOBD)', 000000060.00000)). This can also be done with DDM, REXEC, RMTCMD, and maybe a 1/2 dozen other ways to call a program on the iseries. You should know that the LMTCPB parameter is (so far) only enforced by QCMD and the FTP remote command server - a whole host of other services do not prevent users with LMTCPB(*YES) from running commands. The reason this SBMJOB can assume the identity of another user is because the Job Description and the QSECURITY system value conspire to allow the programmer to run commands using the identity of whoever is named in job description PRODJOBD. If you haven't done so already, DSPJOBD PRODJOBD and inspect the USER field. That is the user who's identity (and authority) is being hijacked by this SBMJOB. 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 Lim Hock-Chai > Sent: Tuesday, November 16, 2004 1:07 PM > To: Midrange Systems Technical Discussion > Subject: RE: security hole in interactive sql call > statement? > > Unless the application is designed to allow it, there is > no way for user to assume the identity of another user if > LMTCPB is (*YES). > Raising the security level would require a bit more work. > Oh, well, got to do what you got to do, right. > > > > -----Original Message----- > From: midrange-l-bounces@xxxxxxxxxxxx > [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of John > Earl > Sent: Tuesday, November 16, 2004 2:57 PM > To: Midrange Systems Technical Discussion > Subject: RE: security hole in interactive sql call > statement? > > > > Well, wrong. In the STRSQL session, programmer can do > > CALL QCMDEXC('sbmjob cmd(clrpfm xxx) jobd(PRODJOBD) > > user(*JOBD)', 000000060.00000)). > ^^^^^^^^^^ > |||||||||| > > There's your problem - you're running at QSECURITY level > 30 (or less), > or else all of your programmers have *USE (or better) > authority to the > user named in the PRODJOBD job description. > > The rules for assuming another user's authority via the > SBMJOB... > User(*JOBD) method are as follows: > > At QSECURITY 30 and lower. > The User that submits the job must have *USE authority to > the *JOBD > only. > > At QSECURITY 40 and higher. > The User that submits the job must have *USE authority to > the *JOBD, and > > The User that submits the job must have *USE authority to > the *USRPRF > that is named in the *JOBD. > > The problem with your QCMDEXC scenario is that users can > assume the > identity of the user named in the *JOBD PRODJOBD. You can > put a stop to > that with two simple steps > 1) Raise your QSECURITY level to at least 40 (See the > Security Reference > Guide for specific instructions on auditing before the > change) > 2) Make sure no one (especially *PUBLIC) has more than > *EXCLUDE > authority to the User Profile named in the *JOBD (Or to > any user profile > for that matter) > > The problem is not that programmers have the authority to > CLRPFM, the > problem is that they can assume the identity of another > user that has > authority CLRPFM on production data. > > jte > > -- > 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.