%	$Source: /mit/jtkohl/tex/RCS/roroot.tex,v $
%	$Author: jtkohl $
%	$Header: roroot.tex,v 3.0 88/09/28 15:07:45 jtkohl Locked $
%
\documentstyle[timrom]{article}
\input{margins}
\stdsizes
\title{A proposal for read-only root filesystems on Athena workstations}
\author{John T. Kohl}
\date{DRAFT v4.0---28 September 1988}
\begin{document}
\maketitle
\section{Why a read-only root filesystem?}
The main impetus in preparing a read-only root filesystem for the
workstation is to prevent users from accidentally or maliciously
modifying the system software on the workstation's hard disk.
Athena operations frequently reloads software on machines because of
corrupted root filesystem contents. 
A read-only root will substantially improve the integrity
of the system software present on a workstation's hard disk, reduce
the necessity of reloading software, and provide a longer mean time
between failure of a public workstation.

There have been many reports of users modifying in some fashion the
software on the root filesystem of a workstation.  This usually involves
changing {\tt /etc/athena/activate} and {\tt deactivate} to turn access on
all the time.  So far as is known, it has not yet involved ``Trojan horses''
intended to steal passwords or other sensitive information.
A read-only root filesystem will substantially discourage these attacks.

In addition, by moving some slowly-changing files off of the root
filesystem, the risk of catastrophic filesystem damage in the case of
power loss or other inadvertent processor halts is reduced.  This kind
of damage is often seen when {\tt /etc/passwd} is corrupted and {\tt
fsck} causes an infinite reboot cycle trying to fix it.

By raising the cost (i.e. reducing the ease) of arbitrary
privatizations, we are better able to force private workstation users to
select customization patterns we explicitly support.

\section{Why not a read-only filesystem?}
There are also considerations arguing against a read-only file system.

A read-only filesystem will probably retain any modifications until the
next update to the workstation.  While this is fine for private
workstations, this could be a disaster on public workstations, if someone
were to break in and modify software.  However, with the implementation
described below, it is fairly easy for an Operations employee to fix
such a modified workstation.

A read-only filesystem also presents a roadblock to a private workstation
maintainer who wishes to perform some customizations.  However, this
problem is limited to customization desires which are not servicable by
the standard Athena configuration hooks (such as {\tt /etc/rc.conf},
symbolic links to {\tt /site}, and Hesiod).

It also complicates the automatic update feature (whereby
workstations, upon deactivation, would run an automatic update script to
get the latest and greatest changes).

\section{The real desire}
What we want out of a read-only root filesystem is to be able to
guarantee the contents of a given workstation's root filesystem (to
detect/prevent/correct corruption or malicious tampering).

Updating to a new version of software is essentially changing the
standard root filesystem contents.  Major updates are radical changes to
or replacement of the contents; minor updates are small changes.

This can be accomplished in several ways:
\begin{itemize}
\item Re-install a workstation from
scratch, essentially throwing out what is on the disk.  This results in
the cleanest solution with known contents.

\item Update the things which have changed between versions.  This
leaves any customizations (and unwanted modifications) to unchanged
files alone.

\item Synchronize all the controlled files.  This will remove any
customizations or modifications to standard systems, but not clean up
additional or uncontrolled files.
\end{itemize}

Since we really want to know {\em exactly} what is on the root
filesystem, we want the first option.  But under the current install
scheme, this is a bit expensive, and requires manual intervention
(something we want to avoid).
It also makes it critical that we provide enough customization hooks
such that a private workstation manager can do all he wants without
being thwarted by a read-only root filesystem.

Cambridge University in England has an attractive solution, which, when
combined with a new boot procedure, may be useful.
They have modified the RVD system such that a local disk can be used as
a cache of a read-only shared remote disk.  If used for a root
filesystem, this would provide a clean solution to the problems:
\begin{itemize}
\item The root filesystem has known contents.
\item Any suspected tampering can be fixed (at the cost of performance)
by flushing the cache.
\item Updates merely become changing the standard root RVD, combined
with a cache flush.
\item The user only needs to pay once for things he uses.  Unused files
are never placed in the cache.  Re-used files act as if they are local.
\end{itemize}
Combined with a standard bootp/TFTP boot procedure to find the right
kernel and friends (memory disk?), this could be an easy way to get
known root filesystem contents with the flexibility required for easy
operation.

We might achieve good results by having the standard boot program boot
from /vmunix, but add a flag to the current flags so that the boot
program could do a bootp/tftp boot for an auto-update (the auto-update
causes a reboot -network or some such).  We also want a flag to the boot
program specifying ``flush the RVD cache,'' so that a user can clean up
any trash left by others.  (This might be the same flag used to indicate
a net boot).

Another consideration is a micro-root filesystem (containing /boot and
/vmunix, perhaps), and use the remaining portion of the traditional root
fs area as the cache.

We also want to make sure that we can support our development
operations.  Staff occasionally have need to modify or test
software resident on the root filesystem.
In such a case, it would be desirable to provide the ability to completely
cache the remote disk and run with a local read-write disk system.  At
some future point, the maintainer would be expected to revert to the
standard read-only cached RVD filesystem.

\section{The implementation}
The change involves kernel modifications to support booting into a read-only
root filesystem, modifications to the root filesystem layout to move
things around, and changes to a few programs which try to write into
directories ({\em not} files---see below) in the root
filesystem\footnote{Currently identified programs are 
vipw, umount and detach.}.

The kernel is changed so that if a global flag is set, the root
filesystem is mounted read-only upon booting.

The writable configuration files which normally reside in the root are
symbolically linked to the {\tt /site} partition (including {\tt
/etc/passwd}).  This is not a problem except for operations performed
before {\tt /site} is mounted.  {\tt /etc/mtab}, even though linked to
{\tt /site/etc/mtab}, has a shadow copy in the root filesystem as {\tt
/site/etc/mtab} (similar to the trick with {\tt /site/tmp}).  This
shadow copy is primed with the entries specifying that {\tt /} and {\tt /site}
are mounted ({\tt /etc/mount} will behave properly in this situation).
{\tt /etc/rc}, when it normally forces {\tt /} into the mount table,
will also force {\tt /site} into the mount table (which is on the {\tt
/site} partition).

A program ({\tt rwroot}) is provided which prompts for a password on a
terminal.  If the password entered does not encrypt to the same string
as a password stored in a file on the root filesystem, the program
terminates.  If the password matches, {\tt rwroot} decrypts its main
body and executes it.  The body patches the root filesystem to make it
read-write.  {\tt rwroot} is prepared specially, by linking as a ``407''
impure text execubable and then encrypting the portion of the text
segment containing the main body.

This scheme allows a privileged user (one with a special password) to
mutate a machine's root partition into a writable filesystem for
updating, customization, or whatever he desires.  One such customization
could be to enable read-write root filesystems for all future reboots
(by installing a new kernel).

An unprivileged user is prevented from writing to the root filesystem
and thus is relegated to booting off of some other device (such as
floppy, tape or network) or kernel in order to get write access to the
normal root filesystem.

\subsection{Availability}
A prototype implementation of the kernel modifications is available for
the VAX.  An RT implementation should be straightforward, about half a
day's work.  A prototype {\tt rwroot} is forthcoming.

\section{Proposed standard configuration}
The following files are symbolically linked to {\tt /site/etc/}:
\begin{verbatim}
/etc/mount
<all PID files>
/etc/passwd{,.dir,.pag}
/etc/group
/etc/utmp
/etc/rmtab
/etc/clusterinfo
/etc/clusterinfo.bsh
/etc/motd
\end{verbatim}
In addition, {\tt /core} is symbolically linked to {\tt /usr/tmp/core.root}.

{\tt /etc/umount} and {\tt /bin/athena/detach} create temporary mount
table files in {\tt /site/etc} directly, instead of in {\tt /etc} (this
is necessary due to the inability to atomically rename files across
filesystems).  Likewise, deactivate needs to create the {\tt ptmp} and
{\tt gtmp} files directly in {\tt /site}, and {\tt save\_cluster\_info}
needs to perform machinations with cluster information files in {\tt
/site/etc} rather than {\tt /etc}.

{\tt /dev/log} is symbolically linked to {\tt /site/dev/log}.  This is used by
{\tt /etc/syslogd} to receive all syslog messages from local daemons.
{\tt /etc/rc} needs to remove {\tt /site/dev/log} before syslogd is
started or else syslogd will be unable to create the socket in {\tt
/dev/log} and consequently complain and cease functioning.

{\tt /mit} is symbolically linked to {\tt /site/mit}.

Private workstations would be expected to operate with a
read-only root filesystem.  For customizations such as adding local
users, certain files (such as {\tt /etc/passwd.local} and {\tt
/etc/group.local} could be placed onto read-write partitions.

\section{Remaining problems}
\begin{itemize}

\item Bourne shell scripts cannot be run before {\tt /site} is mounted, since
they require a writable {\tt /tmp}.  But for
single-user use, bourne shell scripts {\em can} be sourced by using the
``{\tt .}'' builtin command.

This is only a minor problem; if {\tt /site} cannot be mounted, shell
scripts are likely to be of little use anyway.

\item It is possible for an advanced user to examine the kernel sources and
patch the kernel manually to make the root read-only.

This is the biggest problem with this proposal.  If we are to use a
read-only root filesystem, it will {\em always} be possible for someone
with access to our kernel sources to determine how to convert the
filesystem from read-only to read-write.  But by providing a confusing
user-code program ({\tt rwroot}) we may divert the energies of users
such that they do not make attempts to directly modify the kernel.

\item If the read-write password is compromised and replaced, the
workstation effectively locks out authorized users.

This can be corrected by booting off of another medium, e.g. floppy or
tape or extra disk, and correcting the password stored on the standard
boot device.  An alternative is to give up and reinstall if the
workstation's read-write password is corrupted or compromised.

\item There is a danger of the {\tt /dev/log} symbolic link being removed if
syslog is started while the root is read-write.  This will eventually
prevent syslogd from starting if the root becomes read-only (since it
will be unable to create {\tt /dev/log}).

This threat could be removed by changing syslogd to create its socket
directly on {\tt /site}, and installing the symbolic link as the
standard configuration.

\item Filesystems which expect to mount under anything directly on the root filesystem will not be mountable since attach will be unable to
create the mount points. This is especially pernicious with respect to
explicit attaches ({\em e.g.} {\tt attach -e priam:/u1}).  It also makes
many of the convenience Hesiod filesystem names such as ``paris:source''
unusable.

This has a major impact on the Athena staff and the conventions
established for using machine-named mounts.  Some relief could be
provided by changing the convention to mount such filesystems on {\tt
/@/machinename}. 

\item It would be nice to find a way to make automatic update work.
This might involves using a private version of the {\tt rwroot} program, but
care must be taken to prevent any non-password protected version from
escaping as private copies.

\item Check out vulnerability to /site modifications.

\end{itemize}

\section{Acknowledgements}
Thanks to Jeff Schiller, Ken Raeburn, Mark Eichin, Richard Basch, and
Jon Rochlis for ideas discussed while formulating this proposal, and to
Dan Geer for comments on early drafts.

\end{document}
