Re: Informix and trusted host access

>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. >> This should suffice to get the juices going and to let you know that >> to my knowledge proprietary code _is_ required to enforce system security. >> I would be surprised to find that any database expert can find a way to >> embed trusted host security into a database engine, but I'm also just as >> sure it can be done. >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.) (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, 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 isn't perfect. But it can be made to work. >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. 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. 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. 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. >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>