|
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.