× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  1.  Home
  2. MIDRANGE-L
  3. November 2004

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


--
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 11:37 AM
> To: Midrange Systems Technical Discussion
> Subject: RE: security hole in interactive sql call
> statement?
> 
> In a sense that is what we thought we have achieved.  We
> go one level deeper.  We put security on data files!
> Programmer  have view access to most data files.  The
> library is also secured.  Programmer cannot added object
> to it.  Therefore not able to use CREATE TABLE.  This lead
> us to conclude that there is not big deal even though
> programmer can access STRSQL.
> Well, wrong.  In the STRSQL session, programmer can do
> CALL QCMDEXC('sbmjob cmd(clrpfm xxx) jobd(PRODJOBD)
> user(*JOBD)', 000000060.00000)).
> 
> (Note:  I think most of the commonly use ibm commands are
> *public *use).
> 
> 
> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx
> [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of
> CWilt@xxxxxxxxxxxx
> Sent: Tuesday, November 16, 2004 11:21 AM
> To: midrange-l@xxxxxxxxxxxx
> Subject: RE: security hole in interactive sql call
> statement?
> 
> 
> Look at it from the other end....
> 
> Instead of trying to find and secure every possible way of
> calling a
> command, including any news ones that may be added, you
> simply secure the
> commands that can be called.
> 
> Again, why are the IBM defaults not enough?  The default
> authority for IBM
> commands is generally plenty secure.  If WRKACTJOB is just
> an example, what
> is a specific command that you have a problem with?
> 
> 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 11:57 AM
> > To: Midrange Systems Technical Discussion
> > Subject: RE: security hole in interactive sql call
> statement?
> >
> >
> > well, WRKACTJOB is just an example I used.  If user can
> call
> > qcmdexc, the LMTCPB is pretty much useless and to look
> thru
> > and secure all the ibm commands is not an easy task.
> sooo,
> > The next question would probably be:  why not just
> secure the
> > call command or qcmdexc program.  Well, having some
> problems
> > with it at the moment.  These two objects are so
> commonly use
> > that some other problems are popping up when securing
> them.
> > oh, well, its a fun day.
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: midrange-l-bounces@xxxxxxxxxxxx
> > [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of
> > CWilt@xxxxxxxxxxxx
> > Sent: Tuesday, November 16, 2004 9:57 AM
> > To: midrange-l@xxxxxxxxxxxx
> > Subject: RE: security hole in interactive sql call
> statement?
> >
> >
> > If the IBM defaults are not good enough for you, then
> that is
> > your only
> > option.
> >
> > IBM ships WRKACTJOB with PUBLIC *USE.
> >
> > You apparently don't want everybody to be able to use
> it, so
> > you're only
> > choice is to change it and any similar command to PUBLIC
> *EXCLUDE.
> >
> > Of course, this begs the question...why do you think the
> > public shouldn't be
> > allowed to use WRKACTJOB?
> >
> > The IBM defaults should be plenty secure enough for
> 99.9% of
> > the shops out
> > there.
> >
> > 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 10:07 AM
> > > To: Midrange Systems Technical Discussion
> > > Subject: RE: security hole in interactive sql call
> statement?
> > >
> > >
> > > are you suggesting putting security on all ibm
> commands?
> > > doesn't sound like a simple task.  Any suggestion on
> how to
> > > implementer this?
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: midrange-l-bounces@xxxxxxxxxxxx
> > > [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of
> > > CWilt@xxxxxxxxxxxx
> > > Sent: Tuesday, November 16, 2004 8:58 AM
> > > To: midrange-l@xxxxxxxxxxxx
> > > Subject: RE: security hole in interactive sql call
> statement?
> > >
> > >
> > > If your programmers shouldn't be allowed to do a
> WRKACTJOB,
> > then they
> > > shouldn't have authority to the WRKACTJOB command.
> > >
> > > HTH,
> > > Charles
> > >
> > > --
> > > 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.
> > >
> > --
> > 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.
> >
> --
> 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 thread ...
Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 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.