RE: ALL I/O in single module was(ARGH!!! (was file open with LR))

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

> From: rob@xxxxxxxxx
> 
> As far as a programmatic interface, that's security by obscurity.  You
> should have seen the bug eyed IBMer's a few years back in Rochester
which
> called the iSeries Navigator API's from the command line, passing the
> necessary hex codes, just lightning fast.

Oh lord.  Who let Leif in here <grin>?  Anybody who attempts this should
be fired on the spot, and if you have an atmosphere where this sort of
thing is attempted, then you have far more serious problems, but that's
a different issue.

If you believe people will attempt to call your update programs from the
command line, then you simply put in a secondary check in the trigger to
ensure that the program with adopted authority is being called by a
trusted program.

As you mentioned, you can use cascaded authority adoption, letting only
trusted programs have access to the I/O module.  But what if they get
authority to the I/O module some other way?  If you want even more
security, use both the authority method AND the trigger stack check.
Now, the only way they can break your security is by replacing the
trigger or replacing the trusted program.

There is of course a point of diminishing returns, and that's a business
decision, because what if the user gets the DST password?  Or uses an MI
program to get around security?  Or restores a system state program?
There is no such thing as complete security short of turning off the
machine.

Joe