Network Security and Trust Relationships

Since the Informix database products stem from a UNIX environment, it is not surprising that the model for security is the UNIX model. In a UNIX environment it is required that a user have a valid entry in the /etc/passwd (or /etc/shadow) files. Informix uses the UNIX security to decide whether or not to let the user into the system, and Informix takes the security a step further by specifying access to tables and other data objects within the database itself. For now, we are just interested in the ability for a user to get into the system, that is, get past the UNIX security.

The dbaccess program is a good example of the nature of this security. When dbaccess starts up on a remote (client) machine, the user can choose databases in one of two ways. The first way is to simply select the database using either the "Query" or the "Database" option. The user is then presented with a listing of databases available on the server identified by the $INFORMIXSERVER variable. This server can either be a local server on the same machine as the dbaccess program or a remote machine. If the connectivity is set up properly, the user can access this server without needing to enter a password. The second method is to use the "Connect" menu option to choose a server. The user is then prompted to enter a login name and password. If these are correct, the user is then presented a list of databases on the remote machine, and from then on the remote server is treated just like a local database.

If the user can set the $INFORMIXSERVER variable to a server and log on without a password, then the connectivity is set up properly. If this doesn't work, but the user can use the "Connect" option to log on by entering a name and password, then there is a problem with the security or trust relationship between the two machines.

We're referring to the failure to connect without a password as a "failure." There could be valid reasons for this to be correct behavior depending upon the security needs and requirements of the system. In most development applications, though, the system needs to be set up to allow users and DBAs convenient, unfettered access to all the servers on the system, and this requires that they be able to connect without a password.

An analogous UNIX concept is the use of the rlogin command to login from one machine to the other. For rlogin to work properly, there must be matching usernames and passwords on each machine, as well as a trusted relationship between the two systems. A trust relationship between two machines and/or users means that the user on one machine is equivalent to the user on the other. This trusted relationship can be enforced by two UNIX level files.

/etc/hosts.equiv

The /etc/hosts.equiv file allows a user from one server to log into a target server without a password as long as the sending server's username is a valid username on the target server. For example, suppose the system administrator wants to give user joe on machine the_client to be able to access the_server as user joe without a password. He would place the following entry in the /etc/hosts.equiv file:

   the_client         joe

The format is servername, whitespace, username. Alternatively, entering a "+" as the only field on a line would give unlimited access to all users on all known servers. Note that there may be differences in the use of both the /etc/hosts.equiv and .rhosts files depending upon your version of UNIX. Check your manpages if you are not sure.

This file can also be placed on a Windows NT system, where it serves the same function for Informix. Put in the same directory as your hosts file.

~/.rhosts

The .rhosts file is located in the home directory of the user name you wish to use on the server. For example, if you wanted a user on client the_client named joe to be able to log into server the_server as user john, in john's home directory on server the_server, john would place an .rhosts file containing the following:

   the_client           joe

If user john wanted to allow unrestricted logins by anybody, anywhere (in blatant violation of just about every security rule in the book), he would enter

* *

The general format for the .rhosts file is server_name followed by white space followed by username. The asterisks indicate wildcards for server and login.

This file can also be placed in a user's home directory on a Window NT system. To do this, though, the user must be set up with a home directory in the user manager program. Put the .rhosts file there and it will behave just like it does in UNIX.

Security Implications of /etc/hosts.equiv and ~/.rhosts

These two files affect more than just Informix. They allow remote logins from foreign machines and can have adverse UNIX security implications. For example if you made the root accounts equivalent on two machines, if the root account was compromised on one machine, it would also be compromised on the other. In fact, if you have a complicated trust relationship between multiple machines, a security failure on any one of the machines can affect security on all of the systems.

The ~/.netrc File

As an attempt to partially alleviate some of the security issues, Informix can also use a third UNIX file, the .netrc file in the user's home directory. This file contains information about alternative usernames and passwords that can be used to connect with a machine that is not trusted and does not have a ~/.rhosts file. This file is used in UNIX for allowing ftp access between systems, and Informix has expanded its use to include access to the database. Be aware that entries in this file may open you up to some ftp security issues.

The format of the file is different from both the .rhosts and /etc/hosts.equiv files in that it requires the use of three tokens followed by the values of the tokens. These tokens are:

• machine: Use this token followed by whitespace followed by another machine's name

• login: Use this token followed by whitespace followed by the login name you want to use

• password: Use this token followed by whitespace followed by the password to be used on the other machine

As an example, if you are user joe on machine the_client and want to be able to log into machine the_server as user fake_user with password fake_password, you would put the following line into your .netrc in the joe home directory on the_client:

   machine the_server  login  fake_user password fake_password

Again, realize that there are some security implications here also. Most noticeable is the fact that the password for the user fake_user is written in plaintext as fake_password. In most development environments, security is of little concern, since everyone wants unfettered access to everything. Be aware, though, that as you move into a production environment, you will need to be much more critical of security. Before using any of these three UNIX files to relax security, be sure that your system administrator knows what you are doing and why.

There is no analogue to the .netrc file on Windows NT systems. If you want to be able to access another server with a different login name, you must do it through setnet32.