Re: Securing a command from command line.

[Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>]

Hi Rob,

> I want people to not use a certain command from the command line but using
> it in a program is ok.  I even want to restrict QSECOFR so LMTCPB is not
> the option.  First thought was CHGCMD and take away *INTERACT.  However,
> that killed the use in a program.  I thought *IPGM was all I needed.
> However *IPGM is pretty insistent that the program be a CLP.  Trying the
> command with QCMDEXC in RPGLE blows up after you remove *INTERACT.

Heh... RPG programs can't run CL commands, that's why *IPGM and *IMOD both 
only work with CL (and ILE CL)

I assume that you're running the command through QCMDEXC, QCAPCMD, or a 
similar interface.  In that case, it's treated just like a command-line. 
It's not really a program-to-program call!

If you somehow made it so that it was allowed through QCMDEXC and not 
allowed from the command-line, what would stop a user from simply typing 
CALL PGM(QCMDEXC) PARM('MYCMD PARM() PARM()' 123) at the command line and 
completely defeating your security?

Likewise, if you wrap the command with a CL program so that it can be 
called from RPG (or whatever) what will stop the user from calling the CL 
program from the command line using the CALL command?

I think your best bet is to write routines that analyze the call stack to 
see where the program is being called from. Then your program can end 
itself if it's called from the command line rather than from a program.

You'll also want to make sure that the source code isn't on the system, 
that you've removed the ability to retrieve that code with RTVCLSRC (etc) 
in order to prevent someone with QSECOFR access from simply changing the 
code and recompiling it.

That's still not a perfect fix, since someone with that level of access 
could use the "Display, Alter, Dump" utility to change the actual machine 
code to bypass your checks -- but it certainly makes it more difficult.