RE: Installing 3rd Party Software using QSECOFR

According to IBM, its perfectly acceptable to require *ALLOBJ to install a
licensed program:

http://publib.boulder.ibm.com/infocenter/iseries/v5r3/topic/cl/rstlicpgm.htm

The Restore Licensed Program (RSTLICPGM) command loads or restores a
licensed program for initial installation, for new-release installation, or
for recovery. 

Restrictions: 

This command is shipped with public *EXCLUDE authority. 
To use this command, the user must have *SECADM and *ALLOBJ authority. 

And saying QSECOFR (or equivalent) is definitely easier than saying *ALLOBJ
to the novice administrator. Typically either will work. QSECOFR/*ALLOBJ is
*not* a crime to install software, IMO its preferred.

Mike Grant
Bytware, Inc.
775-851-2900 

http://www.bytware.com

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

CONFIDENTIALITY NOTICE:  This e-mail message and any attachment to this e-mail 
message contain information that may be privileged and confidential.  This 
e-mail and any attachments are intended solely for the use of the individual or 
entity named above (the recipient) and may not be forwarded to or shared with 
any third party.  If you are not the intended recipient and have received this 
e-mail in error, please notify us by return e-mail or by telephone at 
775-851-2900 and delete this message.  This notice is automatically appended to 
each e-mail message leaving Bytware, Inc.