RE: security hole in interactive sql call statement?

Oh, running on qseclvl(30) are we?  Do a CHGSYSVAL QSECLVL(40) or 
CHGSYSVAL QSECLVL(50), IPL and that problem is resolved.

Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





"Lim Hock-Chai" <Lim.Hock-Chai@xxxxxxxx> 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
11/16/2004 03:08 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
"Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
cc

Fax to

Subject
RE: security hole in interactive sql call statement?






I submit the command using the parm user(*jobd).  This job will run under 
the jobd's user ID.  The user ID is operator and got *all on data files.

As far as calling any command or api from within a program, that is not a 
problem.  Programmer cannot create program in production box.


-----Original Message-----
From: midrange-l-bounces+lim.hock-chai=arch.com@xxxxxxxxxxxx
[mailto:midrange-l-bounces+lim.hock-chai=arch.com@xxxxxxxxxxxx]On Behalf
Of Jim Franz
Sent: Tuesday, November 16, 2004 2:03 PM
To: Midrange Systems Technical Discussion
Subject: Re: security hole in interactive sql call statement?


you need more that view (read) access to clrpfm a file.
The security here is on the file, no matter what cmd used.
I think to be really tight, you have to assume anyone can get
some form of command access, and work from there. Your
programmers can already call any command or api from within a program.
jim
----- Original Message ----- 
From: "Lim Hock-Chai" <Lim.Hock-Chai@xxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Tuesday, November 16, 2004 2:37 PM
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.
>
>


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