RE: QSECOFR was: Anti-virus for i5OS

["John Earl" <john.earl@xxxxxxxxxxxxx>]

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

I'm pretty sure that the swap profile API's will not allow you to swap
to QSYS.  They will allow QSECOFR.

jte

--
 
John Earl, VP and Chief Technology Officer
PowerTech:   253-872-7788
Direct:          253-479-1408
Mobile:          206-669-3336
John.Earl@xxxxxxxxxxxxx
 

 
 
Email is an excellent way to communicate material that is not time
sensitive.  If your communication is of a more urgent nature, please
call. 
 
===========================
This email message and any attachments are intended only for the use of
the intended recipient named above and may contain information that is
privileged and confidential. If you are not the intended recipient, any
dissemination, distribution, or copying is strictly prohibited. If you
received this email message in error, please immediately notify the
sender by replying to this email message or by telephone and delete the
message from your email system. Thank you.
 

> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx 
> [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of 
> ALopez@xxxxxxxxxx
> Sent: Wednesday, April 02, 2008 8:43 AM
> To: midrange-l@xxxxxxxxxxxx
> Subject: 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.
>
> --
> This is the Midrange Systems Technical Discussion 
> (MIDRANGE-L) mailing list To post a message email: 
> MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change 
> list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, 
> please take a moment to review the archives at 
> http://archive.midrange.com/midrange-l.