
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 LOCAL_NETS macro can and should be used to define a list of "local",
i.e., trusted networks.  RPCs from outside this list will be categorically
barred, 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).

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

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.1 1992/03/25 01:09:41 stolcke Exp $]
