RE: QSECOFR was: Anti-virus for i5OS

[ALopez@xxxxxxxxxx]

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