|
The following are some of the standard requirements we have for security when we evaluate software. Failing to meet these requirements may not rule out a vendor, but definitely has an impact on our selection process. You would be surprised at how easy it is to get a command entry screen with QSECOFR authority in some software packages. - Secure command line access and control of access to systems commands and menus. - No hidden, undocumented access to the system. - No switching of user profile handles. - Secure use of adoptive authority and user profiles on JOBD's. - No second level passwords and user profiles. - The application's security must be based on individual user profiles. - The application must provide field level security. - There must be no dependence on QSECOFR authority adoption. The application software must not require QSECOFR authority to install. - Objects must be owned by a non-IBM provided user profile. Stan -----Original Message----- From: John Earl [mailto:johnearl@toolnet.com] Sent: Tuesday, 22 June, 1999 9:52 AM To: MIDRANGE-L@midrange.com Subject: Re: Package Vendor that changes IBM command Defaults. Roger, Yikes! These folks are out of control! A couple of points are worth making. First, by modifying critical pieces of the operating environment they are opening your client's system up for every program that is every compiled on that system. Because AS/400's are typically muli-tuser and multi-application platforms, this company is putting their customers boxes at great risk. If the customer has a program (not part of their package) that presents the user with a command line, and you compile that program using a profile that has some high level of authority, and then an end user did damage through the command line because the program adopted authority, would a court find that the vendor was liable for the damage? I don't know the answer, but I would bet it would be a good fight. I think this vendor ought to be given the opportunity to ponder their legal culpability. The second point to bring up is why does QSECOFR need to own anything? Does the application require that all users of the application be able to delete every object on the system (*ALLOBJ special authority), create and delete user profiles (*SECADM) and even alter storage and reconfigure ASPs (*SERVICE). By running all applications under QSECOFR authority they are giving _everyone_ who can access a command line from the application the ability to completely hose the system. And it is not for the vendor to say who does and does not get access to the command line, you have considerations in your shop that may make it necessary to provide the accounting supervisor command line access. That doesn't mean you want her running communicaitons trace and deleting Audit journals. The other problem that can occur with forcing you to use an IBM profile for ownership is that profiles can fill up. If a profile owns two many objects it runs out of space to record it's ownership and then simply will not allow you to create new objects under that profile. If everybody makes QSECOFR the owner you could run into this problem. I understand that the vendor is _trying_ to do the right thing by creating an Applicaiton Only Access sort of a system, (assuming that *PUBLIC has no rights to all the applicaiton objects...... boy I sure hope that's true!). But in order to do this correctly, the vendor should provide their own (owner) user profile(s) that has no special authority. Using any IBM profile, and especially QSECOFR, provides users of the package with all sorts of extra authority that they don't really need, and puts data at risk. Special Authorities within an application packageare seldom required. In the few instances that they are, a specific program can be crafted to adopt authority for the specific purpose at hand. Granting every program in an entire package the ability to adopt QSECOFR is gross negligence, IMHO. jte Roger Vicker wrote: > Hello, > > <<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. 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! > > <<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. > > Roger Vicker, CCP > > -- > *** Vicker Programming and Service *** Have bits will byte *** www.vicker.com > *** > We weld anything but the crack of dawn. > > +--- > | 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 > +--- -- John Earl johnearl@toolnet.com PowerTech Toolworks 206-575-0711 PowerLock Network Security www.400security.com The 400 School www.400school.com -- +--- | 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 +--- +--- | 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.