GNU Queue load-balancing system:What are the Security Issues associated with Queue?:
When Installed by an Ordinary User

In this installation mode, GNU Queue takes many of the same precautions for these users as when it has been installed cluster-wide by a system administrator.

Unfortunately, when Queue is installed by an ordinary user, privileged ports are not available. This might make it possible for a malicious user already having a shell account on the same cluster to have queued or queue try to spoof each other.

To close this hole, Queue uses the one-way function crypt(3) and a cookie passed over NFS to allow queued and queue to authenticate each other. These cookies are used in the root version as well to prevent port confusion by queued trying to connect to a queue that has earlier died, although they aren't useful from a security standpoint.

When GNU Queue is compiled with the -DHAVE_IDENTD (and -DNO_ROOT), queued and queue also use the identd service (RFC 931) to prevent spoofing by checking the ownership of remote sockets within the cluster. For this to work proplery, identd must be running on all your cluster hosts, return accurate information (either the user's login name as given in the password file or his/her uid), and at least accept connections from within the cluster in a reasonable amount of time. The ./configure script tries to set -DHAVE_IDENTD automatically based on whether or not your host accepts local connections to port 113, but some systems intentionally allow identd to output bogus information for privacy reasons, and -DHAVE_IDENTD should not be set on these; if this is the case, you may need to re-compile GNU Queue with HAVE_IDENTD undefined in config.h. Fortunately, queue will normally complain immediately if -DHAVE_IDENTD is set when it shouldn't be.

To get around the performance hit of calling the crypt(3), one-way functions are not used if spoofing queued is impossible due to privilege ports (root installation) or authenticated ports (HAVE_IDENTD service), so running identd with GNU Queue or installing GNU Queue cluster-wide as root may offer a slight performance advantange. In sites which normally send user passwords over the network in cleartext it is not expected to substancial improve secure over the cookie passing mechanism, however.

These cookies are passed in plaintext, which means that a malicious user might be able to observe the NFS network traffic between the hosts and, having shell access on the cluster, might still be able to spoof queue or queued. Since most sites send UNIX account passwords over the network in cleartext as well, this is only of concern in very secure sites that do not pass passwords in cleartext over the network.

In the rare event that your site is a very secure site that does not send passwords in cleartext, and you are compiling Queue without root privileges, you should have your administrator install the identd (RFC 931) service and re-run ./configure to ensure HAVE_IDENTD is defined in config.h. If your very secure site prefers to spoof identd for privacy reasons, your administrator may be able to restrict identd access with tcp_wrapper or install an accurate identd on a non-standard port which could restrict connections to within the cluster via tcp_wrapper. You would need to re-compile GNU Queue with this new port number set in ident.c. Another option is to have your system administrator install Queue cluster-wide; this uses privileged ports and therefore may operate securely with resorting to identd.

These concerns do not apply when Queue has been installed cluster-wide by root (NO_ROOT is not defined), because privileged ports are then available.


werner.krebs@yale.edu
Previous: When Installed by System Administrator
This document is: http://bioinfo.mbb.yale.edu:80/cgi-bin/fom?file=14
[Search] [Appearance] [Show Edit Commands]
This is Faq-O-Matic 2.606.