Re: Informix and trusted host access

In <1qhppnINNb0q@emory.mathcs.emory.edu> obelix.informix.com!johnl@emory.mathcs.emory.edu (Jonathan Leffler) writes: >>Date: Wed, 14 Apr 93 09:53:03 CST >>From: uunet!mulga.awadi.com.AU!lwaugh (Lionel Waugh) >>Subject: Re: Informix and trusted host access >>X-Informix-List-Id: <list.2147> >>John Carter wrote Re: Informix-NET and trusted host access >>> This involves using DES and a fair amount of C code on both client and >>> server to perform the handshaking between systems and ensure that >>> someone isn't trying to sneak in their own packet and break in. >>> It is necessary to turn off the trusted host mechanism and use >>> encrypted packets with special key generated access codes on each >>> transmission set. [some stuff deleted] >>While I agree with you about the work needed to guarantee network security >>access, I still do not like the fact that Informix have tied their access >>checking to that required by dangerous(*) system utilities like 'rlogin', >>'rsh', etc, thereby giving users access to machines that they really >>only need database communications with. >Two comments. >(1) If you give the users a login shell which simply denies them access to > the machine (logs them off again), they cannot login to the machine. > (They may still be able to use ftp and things like that, though.) Come on now, isn't that a copout? For example, we have a large number of users that need access to a database logging communications activity for support purposes. Many of these people have no need to be on the machine on which the database resides (some have no account). Others need unrestricted access, others need controlled access (menu). Why tie my hands by asking me to slaughter their login? >(2) If you can't trust your users, should you be giving them access to your > databases at all? I don't like /etc/hosts.equiv, but you can use > .rhosts files instead. And if you make it a policy that .rhosts files > will be policed and that unauthorised users will have all permissions > revoked (and you then do the policing), you can keep your system > reasonably secure. Where people abuse the privilege, you fire them, Gosh, so far this response is almost as good as the last part. As far as trusting your users, if you have this attitude I expect you probably have no passwords on any of your systems, right? Then there's the .rhosts file policing. It's this kind of obscure security holes that cause the most problems. Not only is there an extra hole to cover, but policing an open door once a day doesn't tell you who opened-entered-closed the door during the day. Then there's the firing bit. . .well, no, that doesn't even deserve a response! > because the company policies make it clear that to abuse your access > privileges is gross misconduct. And if the company management don't > recognise this, you make it clear to them that their policies are > self-contradictory -- if the system must be kept secure but they won't > provide the tools to enforce the security, they have a policy paradox. No, it sounds like a "fools paradox". If you're calling "company policy" security then. . .well. . .best of luck to ya'. > No, it isn't perfect. But it can be made to work. NOT! >>What I have proposed to Informix (not yet had a reply) is that instead of >>relying on trusted host access (/etc/hosts and .rhosts) that by using RPC >>calls and their own list of trusted hosts ($INFORMIXDIR/etc/hosts) they >>would have the same level of network security but not reduce the general >>level of network security by opening up the system utilities access. I think they should allow a user list as well (optional). >RPC facilities are not as widely available as the TCP/IP facilities. >Informix have to be able to port our product to a vast range of machines >and variants of Unix. Any machines using TCP/IP facilities are inherently >less than secure. Oh, sorry, the "a great big hole is no worse than a small hole" addage. >If your proposed $INFORMIXDIR/etc/hosts contained internet addresses, we >have a double maintenance problem (two places where internet addresses are >maintained). If it only contains host names (so we reference /etc/hosts to >find addresses), then it is feasible. I would hope you would use the resolver routines to allow nameserver use where the names are supplied and allow IP addresses to provide additional security. I'm not sure, but I could imagine a situation where a multi-homed host would have an interface on a secure network (physically secure) and an interface on a not-so-secure network. A nameserver query could return two addresses and, if the not-so-secure address came first another system could fake it. If you allowed IP addresses as well then the DBA could specify only the one address, not the name. >However, one of the reasons for requiring the user to have a login on the >remote machine is so that the engine can check the security access. The >sqlexecd daemon will set the real UID of the engine it forks to the uid of >the user on the remote machine. If the system does not use the real UID, >how do we identify a user over a network non-forgeably? Put succinctly, >you can't. Actually, systems like Kerberos probably allow for this, but >not every site has Kerberos running. Configurable host/name mappings not tied to system utilities. What if user id's are not synchronized on the machines? >>BTW it seems the Informix-Star has the same limitation so I am widening >>this discussion to Informix and trusted host access >As far as I am aware, the access requirements for I-Net and I-Star are the >same. >Yours, >Jonathan Leffler (johnl@obelix.informix.com) #include <disclaimer.h> I'm sure you contributed lots of useful stuff here and I'm always glad to see vendors on the net. Don't take the responses wrong, I'm just a bit disappointed in the casual attitude to security and versatility from the employee of such a well known vendor. -- -----------------------+--------------------------------------------------- Charles "Chip" Yamasaki| The opinions expressed here are my own and are not chip@osh1.OSHA.GOV | supported or even generally accepted by OSHA. :-) -----------------------+---------------------------------------------------