The remote procedure call interface(RPC) is the workhorse of the NFS
system. It is implemented through a library of procedures and a daemon process
on remote hosts. This library acts as an agent to execute the procedure call
on behalf of the calling process. In RPC, a local client application makes
procedure calls that can be executed on remote servers. Remote, however,
does not necessarily mean that clients and servers are communicating over a
network. Clients and servers may exist on the same machine. They are best
understood as processes, running anywhere on a network. In general, services
make themselves known to a network of clients through an independent naming
service or daemon. This service can give clients the address they need to
open a communication channel with a server. The server can than accept or
deny client requests, sending replies as necessary.
Binding is the act of associating a server with a socket. When the
RPC server transport handles are created, they are bound to a certain network
port and a socket address. A binding is a logical association between a
client and server. A binder service is the intermediary between clients and
servers designated to assist in network resource location.
The rpcbind server replaces portmap as the service that provides the
address of an RPC server program to a client program. Rpcbind converts RPC
program numbers into universal addresses. When an RPC service is started,
it tell rpcbind the address at which it is listening, and the RPC program
number it is prepared to serve. When a client wishes to make an RPC call
to a given program number, it first contacts rpcbind on the server machine
to determine the address where RPC requests should be sent. Rpcbind also
features host access control on IP addresses. The local host is considered
authorized. Host access control requires a library that comes with recent
tcp wrapper implementations. Requests that are forwarded by the rpcbind
process will forwarded through an unprivileged port. The rpcbind process
also refuses to forward requests to rpc daemons that do or should verify the
origin of request. At present, the list includes most of the call to the
NFS mount/ NFSD daemons and the NIS daemons. However, limiting access to
the rpcbind daemon does not protect you from direct attacks on the rpc
daemons themselves. The main task of rpcbind is to maintain a table of
available RPC services and of the network ports that they are listening to.
On the other hand, even though rpcbind with access control only makes an
attack more difficult, it will still provide an excellent early warning system.
Rpcbind should started before any other RPC service. Normally, standard
RPC servers are started by port monitors, so rpcbind must be started before
port monitors are invoked. When rpcbind is started, it checks that certain
name-to-address translation-calls function correctly. If they fail, the
network configuration databases may be corrupt. Since RPC services cannot
function correctly in this situation, rpcbind reports the condition and
terminates. As because rpcbind is responsible for the address mapping, it
can only be started by the super-user.
The more general rpcbind service which uses more abstract addresses
that replaced portmap(which used port numbers) still had many problems.
Basically it is a directory service that maps Sun RPC services to network
port numbers. Traditionally, internet services listen on well known network
ports. With Sun RPC, there is no fixed relationship. A server binds to a free
port and registers itself with the portmap daemon(or rpcbind). Of course
both the portmap and rpcbind services listen on a well known port(port 111).
A new version of rpcbind was recently released in TIRPCSRC 2.3 in
August, 1994. This distribution contains SunSoft's implementation of transport-
independent RPC(TI-RPC), External Data Representation(EDR), and various
utilities and documentation. TI_RPC is an enhanced version of TS_RPC that
requires the UNIX System V Transport Layer Interface(TLI) or an equivalent
X/Open Transport Interface(XTI). TI_RPC is on-the-wire compatible with TS_PRC,
which is very widely supported. It is basically an rpcbind replacement with
tcp wrapper style access control. It provides a simple mechanism to discourage
remote access to the NIS(YP), NFS, and other RPC services. Wietse Venema,
from the Science Eindhoven University of Technology in the Netherlands has
recently modified the latest version of the rpcbind server. His changes
address a couple of problems. Many Sun RPC services are insecure because
they have no access controls. With the modified portmap(rpcbind) program,
such services are harder(but not impossible) to find. Also, it addresses the
ability of rpcbind to forward service requests. This is useful when a client
does not know what host provides a service: it just broadcasts to every host,
on port 111, and waits for the first reply. This is, for example, how many NIS
clients identify their NIS server. The problem is, that by forwarding the
request, it appears to come from the machine itself. This feature can bypass
access control in, for example, NFS. Weitse's modification is to disallow
forwarding of NFS mount requests and a few others. This release is being
distributed to make the Sun implementation of the ONC technologies available
for reference and porting to non_Solaris platforms. The current release is
a native source distribution, and provides services that are already available
on Solaris, such as the RPC headers, the RPC library in libnsl, rpcbind, and
rpcinfo, etc.
Bibliography
Power Programming with RPC. O'Reilly and Associates inc. 1992