There is a difference between *ALLOBJ authority and QSECOFR. My main
issue here is with the requirement to use QSECOFR. I also have issues
with the requirement of *ALLOBJ but that is a separate one and easier to
justify in certain cases. It is each admin's responsibility to be aware
of and develop their own security standards. In our case we rarely if
ever use the actual QSECOFR profile.
Remember, QSECOFR does not just have *ALLOBJ, it also has *AUDIT,
*IOSYSCFG, *JOBCTL, *SAVSYS, *SECADM, *SERVICE and *SPLCTL.
Do you want your new software package to adjust your auditing level,
create a PPP connection and add a job schedule entry that calls home and
reports **anything it wants** from your system? ABC Corp may have just
used "social engineering" to get you to install your very own iSeries
virus!
Regards,
Scott Ingvaldson
Senior IBM Support Specialist
Fiserv Midwest
-----Original Message-----
From: ALopez@xxxxxxxxxx [mailto:ALopez@xxxxxxxxxx]
Sent: Wednesday, April 02, 2008 7:00 AM
To: midrange-l@xxxxxxxxxxxx
Subject: RE: Anti-virus for i5OS
So you would want 5722XE1, iSeries Access for Windows installed
under
a profile other than QSECOFR? The same thing for Query Manager and
TCP/IP connectivity Utilities? Seems way overboard to me.
Absolutely, I don't know that any of these specifically require use of
the QSECOFR profile. RSTLICPGM only requires *SECADM and *ALLOBJ
authority.
I guess my confusion comes from the fact that the only profile with
*ALLOBJ on our system is QSECOFR. That will be the only usable profile
ever on our system to have *ALLOBJ. Hence we load licensed programs
with QSECOFR. If you load a package with another profile that has
*ALLOBJ, you've given them access to QSECOFR anyway, right?
That's quite a different question from what the licensed program, or
third party package, runs under. I've had my fun battles with an EDI
package and a spool management software package that seem overly
enamoured with running under a profile with *ALLOBJ. In cases like
these you normally end up knowing more than the vendor's help desk about
how their security works. Amazing how many people get totally confused
by the fact that you want to change one of their programs to run as
*USER and can't because the program doesn't have the needed data to be
changed without recompiling.
In the past some software vendors would require the use of the QSECOFR
profile for installation, then immediately copy it to the profile that
owns all their objects. Then their helpdesk could have QSECOFR access
without having to ask you for it. Once you give up the control they
can do anything they want, like using a profile of ABC123 with a
password of ABC123.
How would they access your system without your knowledge? For the EDI
package that I'm saddled with, the user profile was disabled and only
very limited communications was allowed to the package. While it took
continuing work to get excess authorities of the owning profile removed,
I was fairly confident that nobody was using it without my knowledge. I
may be wrong (wouldn't be the first time....).
midrange.com
