RE: QSECOFR was: Anti-virus for i5OS

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.