|
Roger, In a message dated 6/22/99 1:06:17 AM Eastern Daylight Time, rvicker@vicker.com writes: > <<MODE(*RANT)>> > I have a customer where a vendor (name withheld to protect the GUILTY) for one > of their packages, during a version upgrade, changed all the program create > commands to USRPRF(*OWNER) AUT(*ALL) and all the file create commands to > USRPRF(*OWNER) LVLCHK(*NO) AUT(*ALL). To top it off they compiled as a > member of QSECOFR. Scrap them and get your money back, or sue them. This is unacceptable conduct. Even the (arguably) "industry standard" Help Systems has been lambasted here in the past for things like placing libraries in the system portion of the library list with its Robot product without informing the customer or offering them an alternative. A vendor that truly understands the AS/400 and the security implications of this sort of thing would NEVER resort to these sorts of methodologies. > I plan to explain to the vendor Wednesday morning how disastrous this > can be, especially on a system where theirs is one of many packages plus > multiple in-house development. Also, this is the WRONG way to make changes > (to the QSYS library objects) even if they were justified. I doubt if they realize > that anyone could Trojan horse one of their called programs to gain complete > system access. Even if theirs was the only package on the box they have a > payroll module which all this leaves wide open! You shouldn't _HAVE_ to explain this although, to my knowledge, Help Systems didn't take the hint from the bath they took here previously -- even though I know they monitor this list. There is _NO_ justification for the modification by a vendor of system values, authority settings on already installed objects, or command defaults, IMO. Several vendors, including my personal favorite, do this without regard to the consequences. Trojan horses are the _least_ of your problems -- people with access to your system that know this package and what it does could do more damage to your AS/400 in 10 seconds than a "Trojan Horse" could do in ten years. > <<MODE(*REQUESTER)>> > > What I would like, without creating a total flame war, is a FEW items from this > esteemed group to show them as a backup to my lesson on how to play nicely > as a software package vendor. I can accept the USRPRF(*OWNER) _IF_ the > owner is a special package owner and properly managed but definitely not > QSECOFR! > > <<MODE(*HUMBLE)>> > Thanks In Advance. MODE(*SERIOUSASAHEARTATTACK) Adding library list entries, changing command defaults, and messing with system defaults are completely unnecessary. Some suggestions: 1. If you MUST have specific libraries for your application, create data areas pointing to the proper libraries within your application that are changed during install to point to the libraries that were actually installed. Then qualify your programs/commands based upon these data areas. 2. If you need to change command defaults, duplicate the commands out of QSYS into QTEMP during install and CHGCMDDFT there. Qualify the commands to your changed version in QTEMP. 3. If you follow 1 and 2 and have a well written package, changing system defaults should not be necessary. Frankly, security matters have been given short shrift around here of late. I don't know if this is because of IBM's correction of most of the matters at the system level with which we were concerned a few years back, a more knowledgeable user base, or a genuine lack of knowledge among the newcomers. It certainly _IS NOT_ because of better vendor implementation of security. We used to get two or three posts from Steve Glanstein (our Hawaiian security advocate) per week, now we rarely hear from him. Perhaps more issues like this should be raised... Regards, Dean Asmussen Enterprise Systems Consulting, Inc. Fuquay-Varina, NC USA E-mail: DAsmussen@aol.com "Who would ever need more than 640K of memory and a 30 meg hard drive?" -- visionary Bill Gates +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
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.