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