
HOW TO RUN CUSTOMS SECURELY

The original customs implementation had a number of severe security holes,
some of which are described in the paper in doc/customs.  This file
briefly describes the features that were added to allow running customs
in a reasonably secure way, suitable for production use in a not-so-trusting
environment.

The default configuration is such that all the security features described
below are enabled.  Customs can be run in `single-user' mode, i.e.,
privately by a user to only export his/her own jobs (intended mainly
for debugging purposes).  In that case, at least the reserved port feature
has to be turned off.

1. DENYING ROOT EXECUTION

As a minimal security feature, imported jobs owned by root are denied execution
if the INSECURE macros is not enabled.  This from the original code, and
was really only a half-hearted attempt at security.  Nevertheless, INSECURE
is still insecure.

For details see the comment regarding INSECURE in customs/config.h.

2. PROTECTING ACCESS TO THE RPC SYSTEM

The RPC systems uses a list of "local," i.e., trusted networks to control
access.  Calls from addresses not on this will simply generate an RPC_ACCESS
error, thus preventing any outside intervention or access to a customs
network.  What networks should be considered local?  Basically, only
those consisting only of hosts with hosts.equiv(5) status.  If that is
too strong a requirement, it may be sufficient to guarantee that the
user ids are assigned consistently across the network while using the
passwd-based access restriction to keep unwanted users out (see below).

The list of network addresses that can access the RPC system is initialized
from the addresses and netmasks obtained from local interfaces, and typically
includes the loopback address as well as at least one regular network
interface that supports broadcasts.  In most cases this will be appropriate
and no further action is required.  However, the customs(8) options 
-allow and -deny can be used (repeatedly) to add or remove individual hosts
or networks from the access list.  Typical uses for -allow are to add
extra trusted hosts from which one wishes to montitor the customs system
(e.g., using reginfo and cctrl).  A good reason to use -deny is to
make sure that a customs daemon on, say, a gateway machine is not 
susceptible to an off-site source.  (The effective access control list is
printed once when RPC debugging is enabled).

Note that even when extra networks or hosts have been allowed RPC access
they will only be able to actually participate in regular customs job
import/export operation if broadcasting works, at least from the master
host to all non-masters.

3. USER-BASED ACCESS CONTROL USING PASSWD FILE

Some sites like to keep a uniform users space (with shared home directories
and consistent user ids) but restrict actual access to machines
with rsh and rlogin.  For example, this is easily done using the netgroup(5)
mechanism in conjunction with the yellow pages support for /etc/passwd.
The -access flag in customs and cctrl can be used to allow exportation
only to machines that have valid passwd and/or shells defined for the
given user, thereby implementing the same kind of access control as the
passwd file does for the standard remote execution programs in UNIX.
Note, however, that the users .rhosts is not checked, effectively
creating hosts.equiv(5) status for all hosts on a customs network.

For details see the -access flag in the customs(8) manual page as well
as the DEF_CHECK_USER macro in customs/config.h.

4. HOST-BASED ACCESS CONTROL

The list of clients given to customs on startup can be used to implement
a host-based access control scheme.  For example, more trusted hosts
may be allowed to export to less trusted ones (regardless of user),
but not vice-versa.  This mechanism is unchanged from the original code.

For details see the customs(8) manual page.

5. RESERVED PORT AUTHENTICATION

To really avoid abuse by users who are willing to go through the trouble
of coding their own malicious customs clients, an authentication scheme
similar to the one used by rcmd(3) can be used.  To use this feature
configure customs to require reserved ports for security-sensitive RPC
calls, and select a port number in the reserved range (< 1024) for the
customs service.  This means that those critical operations can then
only be performed by root.  In particular, pmake and export,
the exporting client programs, should be made suid root. As long
as these binaries are not compromised remote execution with customs
should then be as secure as rsh(1).

For details see the USE_RESERVED_PORTS macro in customs/config.h.

A. Stolcke, 2/22/92

[$Id: SECURITY,v 1.2 1994/04/01 21:56:09 stolcke Exp $]
