RE: QSECOFR was: Anti-virus for i5OS

First off *ALLOBJ does not give you the ability to create or change
profiles. Secondly if a programmer did create a temporary profile to do
such devious work, the special owner profile for the packaged
application would be logged. If the programmer deleted the logs, the
recreated logs would show that. Hmmm food for thought. Oh and SST
profiles are completely different than user profiles. Even as QSECOFR,
you still have to log in to SST. You can prevent some of the issues you
mentioned with security setting in SST.

If you don't have the sysvals pushed up to SST, *ALLOBJ gives you the
ability to change the security level on the system. You do so, update a
data area.

Next time your program runs you check the data area and use the reduced
security level to bypass the restrictions on granting yourself *SECADM.
You grant yourself everything you want. You change the *SECLVL back to
its original value.

All of which is my way of saying: if you've locked down the updating of
security related sysvals in SST, you can monitor activity for everybody,
including QSECOFR. QSECOFR can't circumvent it any more than a user with
*ALLOBJ.

If you don't lock down the security related sysvals in SST, a user with
*ALLOBJ can get around everything you put in place. Besides the
convoluted re-ipl scenario above, couldn't a user with all object swap to
QSYS and then monkey to their heart's content?

Even if they can't (I've never tried that level of hacking), they already
have access to the company data. I would think that checking to see if
*SMTP is configured, and emailing a file would not be too difficult an
exercise.

That's the reason I'm willing to install packages using QSECOFR, but I
will nail down any profiles having *ALLOBJ. There's currently two on our
system, only because PM400 won't work without a profile having full
QSECOFR rights that isn't QSECOFR.