.so macs
.TL Security
.br
The reliable denial of services to unauthorised requests

  It is extremely important that the Remote File System server is given
privileges appropriate to the user who is using it to access files on a remote
machine.

  Validation of requests for a remote execution is not as important. While the
job is running resources may be being used illicitly, but no permanent harm can
be done on the scale that an unauthorised remote file system server could
wreak, because a remotely executing program does not interact with the file
system of its host. The following discussion is concerned primarily with
authorisation in the remote file system.

  It is a first principle in maintaining security that access should not be
determined by knowledge of information alone because information can be copied
and used by others without the victim realising.

  Unfortunately, the requirement of a physical element (such as being logged in
to a terminal adjacent to the machine) is an unacceptable restriction on the
utility of a remote access system. We must devise a means by which a request
can reliably be accepted or refused based solely on the exchange of
information.

  In the \*(UX environment, ``privileges appropriate to the user'' are
conferred by having control of a process which has the
effective user-id of the user in question. This can be achieved by logging in
to the machine as the user, which requires knowledge of the user's username and
corresponding password, each of which consists of up to eight characters.
This is therefore sufficient information to allow access to a user's files.

  The password for a user is held in an irreversibly encrypted form in a
publicly readable \*(UX file. The test for validity of a password is to encrypt
the supplied password and to compare the result with the encrypted version held
in the file. It is the knowledge of the unencrypted password which allows
access to files, not that of the encrypted one.

.TL Validation

  A full explanation of the problems in secure validation will not be presented
here.

  The characteristics of the setup of a transport service connection are as
follows:

  A server on the remote machine opens a TSB port and \fBlistens\fP for a
specified \fBname\fP on it.

  The client opens a TSB port on his machine and sends a connect message
specifying the host and the \fBname\fP it is connecting to.

  The listening server is then informed which host the incoming connection came
from.

  Once this has happened a bidirectional byte stream has been set up between the
processes. It cannot be monitored of interfered with by an intruder because the
open transport ports refuse a second attempt to open them.

  Two programs on the same host can listen for the same name on two ports. An
incoming connection for that name is only passed to one of them; the one which
listened first appears to be favoured.

.TL Proposal

  The connecter must supply the correct unencrypted password to the listener
who can then encrypt it and check it against the system password file.

  Unencrypted passwords must not, therefore be passed over the network. An
intruder could listen for the same name as the server, discover the user's
password and use the knowledge to fool the server:

.so secpic1.t

  Restricting access to TSB ports is not a satisfactory solution because the
RFS software needs to be able to obtain TSB ports at random when it is
running with an unprivileged user-id. It would also mean that each machine is
dependent upon the security of all the others.

  It is no better to send an encrypted version of the password; the intruder
cannot find out the unencrypted password but
could repeat the encrypted form to the listener without having to
know the unencrypted form.

.TL "Better proposal"

  The previous system required that the connecting process knew the remote
user's password but that it need not be held unencrypted on the machine to
which he is connecting.

  If both the connecter and the server (which initially has the powers of the
super-user) can find out the user's unencrypted password, each can verify that
the other is who he claims to be without giving any information away to an
imposter.

  With the first message the connecter sends a random string of characters
which both processes encrypt with the user's password. The listener sends back
the encrypted text and another random string which they both encrypt. The
connecter then sends the encrypted version of this back to the listener.

.so secpic2.t

By this means, both sides can verify that the other knows the user's password
without the passage of the passwords themselves in any form. A prospective
intruder can present the server with chosen plaintext and receive correctly
encrypted ciphertext back but cannot correctly encrypt the server's message.

As an added measure, let the user whose files are to be accessed explicitly
have permitted the caller to access his files. (Maintain a list saying which
remote users from which hosts are permitted to access each person's files.)
If an unsuccessful attempt is made to connect to a server, because the server
encrypted some text but did not receive a correct reply (for any reason
including termination of the transport service connection), that permission
is revoked until the target user explicitly permits it again. This defuses a
repeated chosen plaintext attack on the password.

  The encryption algorithm for this must be such that it is impossible to
deduce the key from one plaintext/ciphertext pair given full knowledge of the
algorithm, or that an exhaustive search to find it would take several hundred
years. The
.SC DES
algorithm supplied with \*(UX fills these requirements.

.TL Efficiency

  Extra cost is incurred by a remote execution in setting up the connection
between machines, which will be greater for the Remote File System as it has to
perform validation. Extra processing has to be done on each machine for each
remote procedure call; commands and their arguments have to be linearised for
transmission over the bytestream and decoded when received.

  The need to add a
few bytes of information to a (say) 1024-byte block of data to be read or
written will reduce the advantage of block-buffering if the transport service
used the same size of buffer. A possible remedy to this is to tune the buffer
size used by the user program to a figure such that the transmission of one
buffer of data results in a transport service message equal to or slightly less
than its buffer size. Unfortunately, some programs rely upon their buffer size
being a power of two. A safer solution would be to increase the size to (say)
4096 bytes.

  The higher level of traffic on the network is not a problem at Kent as our
Cambridge ring is working well below its capacity.

  The need to keep more binary files, recompiled to do Remote Procedure Calls
will use more filespace. Local and remote versions of the same program running
on the same machine occupies more memory that two instances of the same
program. However, centralising compilation, text formatting and other large
tasks means that only one copy of the sharable text segment of the object code
need be resident in the whole system's collective memory. What is more,
the ability to even out the workload over several machines also raises the
system's throughput of work.