RE: Installing 3rd Party Software using QSECOFR

This goes way back in this thread as to the vender needs to provide
documentation.  Sounds like you do that, great.  It also sounds like
your product is more of a system level maintenance / configuration tool
than a high level business application.  I would expect it to need more
special authorities to perform those types of functions.

Again if you know what you are buying and any specials authorities are
needed and well documented, that's a good vender to purchase from.

Good work.


Christopher Bipes
Information Services Director
CrossCheck, Inc.


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Dave Schnee
Sent: Wednesday, June 14, 2006 8:44 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Installing 3rd Party Software using QSECOFR

Gentle systems people:

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.

We do know quite a LOT about the AS/400 and OS/400 (or whatever names
they have this week).  Our product was written with that understanding.

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.

We include a section about "how to remove our product".  Completely.
Many other packages, for System i and for other platforms often ignore
this eventuality.

Our package needs *SECADM and *SERVICE authority not only to install,
but to change its own user profile and its Service Tool User's password.
They are changed frequently because of password expiration rules.

We need *IOSYSCFG authority because we change your I/O and LPAR
configuration according to your rules - that is the purpose of our
product.

We allow an installation to specify that ALL of the data communications
we use must be encrypted, but we need sufficient authority to use the
interfaces that requires.

We do not change ANY IBM objects, but there are some well-publicized IBM
interfaces that ship with public authority *EXCLUDE and we need some of
these.  *ALLOBJ authority is preferable to many private authorities to
objects that get replaced during an operating system upgrade.

We do not install any "back doors" nor any other shady code.  We do use
IBM's licensing code for our asset protection.  That is, we install with
RSTLICPGM, remove with DLTLICPGM and install license keys with
ADDLICKEY. 
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.
Again, we need sufficient authority to do that.  We also install license
keys and their time extensions across partitions via our communications
links again for the user's convenience and that, too, requires
sufficient authority.

We understand that when someone buys a proprietary product that requires
extreme authority to install and to run there are always questions and
doubts, but there ARE some good reasons for needing that kind of
authority if the product is to deliver its full value.

Sorry, but I take issue with the statement that "The _only_ company that
should be asking you to install (or even sign on) with QSECOFR is IBM".

Dave Schnee,
Barsa Consulting Group, LLC