RE: Installing 3rd Party Software using QSECOFR

   Tom:

    

   In order to make all the parts of our Automatic Partition Resource Manager
   (APRM(R)) product work we need almost all of what QSECOFR has.  There are
   8 special authorities (*ALLOBJ, *AUDIT, *IOSYSCFG, *JOBCTL, *SAVSYS,
   *SECADM, *SERVICE and *SPLCTL) we need all of these except *SAVSYS and
   *AUDIT.  Well, we _could_ get along without *ALLOBJ, but we would need a
   _lot_ of private authorities to IBM-supplied objects like commands and
   APIs.  And that list tends to change as the product matures and has to
   support new hardware and new IBM code.

    

   We do need 2 profiles for our product: an "object owner" profile with a
   lot of authority so we create it with a password of *NONE and therefore
   cannot be used to sign-on.  All of our programs adopt that "owner"
   profile's authority but include their own checking of the user's authority
   (to functions within the product) to do or not do what the user asks.  We
   also need a separate profile because we need to use (at least on iSeries
   hardware) the only IBM API that allows LPAR configuration and THAT API
   requires an OS/400 user profile AND a service tool (DST) user profile with
   the same name and the same encrypted password.  Both of these must NOT be
   expired.  I didn't make this up - IBM did - "for security reasons".  Not
   only that, but DST expires its users every 180 days - no choices.  As you
   know, OS/400 has a LOT of password system value controls.  The good news
   here is that none of these password rules is applied to the CHGUSRPRF
   command - they only work with normal CHGPWD and the sign-on situation
   where your password has already expired.

    

   We pride ourselves in marketing a product that many customers have been
   able to install and configure with only normal operations personnel and
   some telephone support.  We do provide easy-to-follow instructions in our
   technical manual.  Now, not everybody is a security expert.  If we were to
   list the 6 special authorities we need to have and tell our potential
   customers to sign-on with "enough" authority to create the user profiles
   we will use and to install the product library and create the other
   objects, change an IBM subsystem to add an auto-start job entry for our
   product, etc., I think we would be doing them no service at all. 
   EVERYBODY understands "sign-on with QSECOFR authority".  Again, we do
   list, in full as part of our documentation, all of the things we create
   and we include instructions for _completely_ removing our product and its
   changes.

    

   The idea is to make it easy for the customer, not complicated.

    

   Dave

    

   - - - - - - -  Tom Liotta wrote  - - - - - - -

    

   date: Thu, 15 Jun 2006 19:10:06 -0400
   from: qsrvbas@xxxxxxxxxxxx
   subject: RE: Installing 3rd Party Software using QSECOFR

   midrange-l-request@xxxxxxxxxxxx wrote:

   >   5. Re: Installing 3rd Party Software using QSECOFR (Dave Schnee)
   >
   >This is in response to many posts about requiring QSECOFR authority to
   install a software package and why that's always absolutely terrible and
   unnecessary.
   >
   >Sometimes, it is needed.
   >
   >We market a product that requires QSECOFR authority to install.  We are
   not IBM.

   Dave:

   I don't mind hearing about valid exceptions; it'll be a long time before I
   know everything.

   Perhaps it would be worthwhile to supply a general description of the need
   and involved objects to security/auditing companies such as my employer.

   We could, for example, possibly add your objects to lists of exceptions
   that we distribute inside of our ComplianceMonitor product. We are looking
   at various default "templates" for a lack of a better term. Companies that
   have your products might then be able simply to click on a "Barsa
   Consulting" block and have it automatically included in the exceptions
   they allow rather than needing to contact you and enter a list manually.

   >We include a section in our technical manual entitled "Show this section
   >to your security auditor" - because we're proud of the way we have
   handled
   >security issues to provide full capabilities without security exposure.

   <snip general discussion of multiple needed authorities>

   >We also run in multiple partitions of a System i server and propagate our
   >own software updates, when installed, from one partition to another and
   >automatically reinstall the upgrade for the user's convenience.

   Multi-system/LPAR/single-hardware-platform and control over all data
   transfer encryption -- certainly candidates for QSECOFR though I haven't
   heard specific examples. The LPAR management stuff is definitely outside
   my day-to-day though.

   If you know particular examples for QSECOFR requirement, it'd be a service
   to everyone else to let us know what they are. While needing a number of
   special authorities makes the use of QSECOFR convenient, it might also be
   convenient for customers to use a separate *SECOFR profile.

   But if a requirement exists, general education is best, IMO. Most often to
   me, that means discussion on this list.

   I use IBM's Software Product APIs to create, save, restore, delete and
   license some of our products, including licensing by LPAR. And it takes a
   bunch of special authority to install many of our products for many of the
   same reasons you listed. But I haven't seen a requirement for QSECOFR yet.

   I'm always willing to learn.

   Tom Liotta

   --
   Tom Liotta
   The PowerTech Group, Inc.
   19426 68th Avenue South
   Kent, WA 98032
   Phone  253-872-7788 x313
   Fax    253-872-7904
   http://www.powertech.com