Build HTML documentation and install it.

[become] / manual / become.tex

%%% -*-LaTeX-*-
%%%
%%% $Id: become.tex,v 1.3 1997/08/07 09:37:44 mdw Exp $
%%%
%%% Documentation for `become'
%%%
%%% (c) 1997 EBI
%%%

%%%----- Licencing notice ---------------------------------------------------
%%% 
%%% This file is part of `become'
%%% 
%%% `Become' is free software; you can redistribute it and/or modify
%%% it under the terms of the GNU General Public License as published by
%%% the Free Software Foundation; either version 2 of the License, or
%%% (at your option) any later version.
%%% 
%%% `Become' is distributed in the hope that it will be useful,
%%% but WITHOUT ANY WARRANTY; without even the implied warranty of
%%% MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
%%% GNU General Public License for more details.
%%% 
%%% You should have received a copy of the GNU General Public License
%%% along with `become'; if not, write to the Free Software
%%% Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

%%%----- Revision history ---------------------------------------------------
%%%
%%% $Log: become.tex,v $
%%% Revision 1.3  1997/08/07 09:37:44  mdw
%%% Updated to reflect new `become' version.  Included description of multiple
%%% server support, netgroup handling, larger random seed file, and so on.
%%%
%%% Revision 1.2  1997/08/04 10:24:20  mdw
%%% Sources placed under CVS control.
%%%
%%% Revision 1.1  1997/07/21  13:47:54  mdw
%%% Initial revision
%%%

%%%----- Document preamble --------------------------------------------------


%% --- Document class and packages ---

\documentclass[a4paper, 10pt]{article}
\usepackage{array, tabularx}
\usepackage[rounded]{syntax}

\newif\ifxypic
% \IfFileExists{xy.sty}{\usepackage[all]{xy}\xypictrue}{\xypicfalse}

\IfFileExists{mdwfonts.sty}{\usepackage{mdwfonts}}{}


%% --- Macros and things ---

\newcommand{\become}{\textsf{become}}
\newcommand{\path}[1]{\texttt{#1}}
\def\<#1>{\synt{#1}}
\newcommand{\xor}{\oplus}
\newcommand{\ror}{\mathbin{>\mskip-6mu>\mskip-6mu>}}


%% --- eqalign, from Plain TeX, LaTeXified ---

\makeatletter
\def\eqalign{%
  \null\,\vcenter\bgroup\openup\jot\m@th%
  \ialign\bgroup%
    \strut\hfil$\displaystyle{##}$&$\displaystyle{{}##}$\hfil\crcr%
}
\def\endeqalign{
    \crcr%
  \egroup\egroup%
  \,%
}
\makeatother


%% --- Other layout preferences ---

\setlength{\grammarindent}{1in}
\renewcommand{\arraystretch}{1.2}
\addtolength{\textwidth}{0.6in}
\addtolength{\oddsidemargin}{-0.3in}
\sloppy

\begin{document}


%%%----- Introductory matter ------------------------------------------------


%% --- Title and some `brief' acknowledgements ---

\title{The \become\ program}
\author{Mark Wooding\thanks{
    The program contains nontrivial pieces of code owned by the European
    Bioinformatics Institute, Mark Wooding and Straylight (even though I
    actually wrote it all).  Thanks also to the Free Software Foundation for
    Autoconf; to Ron Rivest for the MD5 message digest algorithm; to Xuejia
    Lai and James Massey for the IDEA cipher; and to Bruce Schneier, for
    writing \emph{Applied Cryptography}, which explained why I'd written the
    first version of all this code wrong.} \\
  \texttt{mdw@ebi.ac.uk}}

\maketitle


%% --- Abstract ---

\begin{abstract}
  This document describes a system for allowing users to `become' other users
  in a secure and controlled way under Unix.  The idea is to allow users to
  maintain programs and other resources which require their own accounts
  while removing the need for such accounts to have passwords (which can be
  disclosed, forgotten or otherwise abused in ways that passwords for user
  accounts don't tend to be).

  The \become\ program will look up the user's identity, the identity of the
  user he or she wishes to `become', the name of the program which is to be
  executed, and the identity of the current host, consult a configuration
  file, and decide whether the request is permitted before granting it.  The
  novel idea is that the table doesn't need to be on the local machine --
  \become\ will send a request to a server, asking it for permission,
  allowing the information to be held centrally, and making maintenance more
  convenient.  Cryptographic protocols are used to ensure the authenticity of
  the server's responses.
\end{abstract}


%% --- Contents ---

\tableofcontents


%%%--------------------------------------------------------------------------
\section{User guide}


\subsection{Introduction}

Running \become\ lets you `become' another user.  What this really means is
that it lets you execute a process with the permissions of another user.
Which users you're allowed to `become', and exactly what processes you're
allowed to execute as those users is determined by the people that installed
\become.


\subsection{Invoking \become}

Invoking the \become\ program is impressively simple.  There are essentially
two forms of invocation:
\begin{syntdiag}
  `become' <user-name> \[ <program> \[ \< <argument> \> \] \]
\end{syntdiag}
and
\begin{syntdiag}
  `become' `-c' <shell-command> <user-name>
\end{syntdiag}
The first variant allows you to execute any \<program> as user \<user-name>,
as limited by your site's configuration.  The second variant simply passes
the \<shell-command> to \path{/bin/sh}, so you must have permission to
execute the shell as \<user-name>.  The latter form doesn't actually allow
you to do anything the former doesn't: it is in fact entirely equivalent to
saying `\syntax{"become" <user-name> "/bin/sh -c" <shell-command>}', but
slightly more compact.


%%%--------------------------------------------------------------------------
\section{Installation and configuration}


\subsection{Unpacking and compiling}

Before you begin, there are some prerequisites you should check:
\begin{itemize}
\item You need the Free Software Foundation's gzip program to unpack the
  distribution archive.
\item You need an ANSI-conformant C~compiler and library to correctly compile
  the source code.  No effort at all has been made to support nonstandard
  C~implementations.\footnote{
    The ANSI~C standard was ratified in 1989.  It is now 1997.  If your
    system vendor hasn't bothered to comply with an eight year old standard,
    you ought to firstly complain to your vendor, and secondly install the
    GNU~C compiler.}
\item You'll probably need GNU flex and bison to rebuild the scanner and
  parser.  However, prebuilt C~source for these components is provided, and
  will probably work.
\item A recent version of \LaTeX\ is required for formatting the manual.  For
  those without \LaTeX, a formatted version of the manual is supplied, in
  PostScript form.
\end{itemize}

The \become\ software is distributed as a gzipped tape archive: saying
\begin{verbatim}
    $ gunzip -c become-1.2.tar.gz | tar xvf -
\end{verbatim}
will decompress and unpack the source code into a directory
\path{become-1.2}.

The software must be configured prior to compilation.  The author has used
the Free Software Foundation's Autoconf system which will (with luck)
configure \become\ correctly for the host platform.  The simplest way to do
this is to change into the unpacked source directory and say
\begin{verbatim}
    $ ./configure
\end{verbatim}
If you're compiling for several architectures, you can keep the object files
for each in a separate directory.  To do this, create a directory for each
one, e.g., by saying something like
\begin{verbatim}
    $ mkdir linux solaris
\end{verbatim}
Then make the appropriate directory current, and run the configure script
from the parent directory:
\begin{verbatim}
    $ cd linux
    $ ../configure
\end{verbatim}

Without any arguments, the configure script will attempt to deduce all it
needs to know about your platform, and it will choose default places to
install files.  You can change the configure script's ideas about where to
put the files by passing it command line arguments.  By default, all of
\become's files are placed relative to a \emph{prefix} directory (so binaries
go in \emph{prefix}\path{/bin} and so on).  The prefix directory is usually
\path{/usr/local}, although you can change this by using the
\texttt{--prefix} option, e.g.,
\begin{verbatim}
    $ ./configure --prefix=/usr/local/become-1.1
\end{verbatim}
(This will keep all of \become's files in a subdirectory of
\path{/usr/local}, which you may find makes maintenance easier.)

You can also choose different locations for various types of file.  Most
importantly, \become's configuration files are put into a `system
configuration' directory, which by default is \emph{prefix}\path{/etc}.  You
can change it using the \texttt{--sysconfdir} option, e.g.,
\begin{verbatim}
    $ ./configure --sysconfdir=/etc/become
\end{verbatim}
If you're planning to use \become\ in a centralised installation (see
section~\ref{sec:become.inst-type} on page~\pageref{sec:become.inst-type})
then the system configuration directory \emph{must not} be on a remote
filesystem because cryptographic keys are stored in this directory and
putting them on a remote filesystem will make them visible on the network.

A complete list of options accepted by the configure script may be displayed
by passing the \texttt{--help} option:
\begin{verbatim}
    $ ./configure --help
\end{verbatim}

You can now build the programs by invoking make.

Finally, you can install the various files to their correct directories by
saying
\begin{verbatim}
    $ make install
\end{verbatim}
(again, using GNU make, so maybe it's not called `\texttt{make}' at your
site).

Congratulations: \become\ is now compiled.  The easy part is now done.


\subsection{Different installation types}
\label{sec:become.inst-type}

There are two types of installation for \become, and which one you choose
depends on how you want to maintain the configuration file, which contains
the rules describing who is allowed to become whom:
\begin{itemize}
\item a \emph{standalone} installation, where the configuration is stored
  locally, and
\item a \emph{centralised} installation, where the configuration is stored on
  a central trusted server.
\end{itemize}
The difference is basically how you want to maintain the configuration.  In
the standalone case, you have to ensure that the configuration file is copied
to each participating host each time it gets changed.  In the centralised
case, you only have one copy of the configuration file, and have a different
problem concerning key distribution.


\subsection{The configuration file}

The configuration file for \become is called \path{become.conf}, and it's
stored in the system configuration directory you set up when compiling the
program.  It defines a set of records, each containing four fields:
\begin{itemize}
\item a \emph{from} field, identifying a class of users;
\item a \emph{to} field, identifying a (possibly different) class of users;
\item a \emph{commands} field, describing a class of commands; and
\item a \emph{hosts} field, describing a class of hosts.
\end{itemize}
Such a record permits any user in the \emph{from} class to run a command
contained in the \emph{commands} class as any user in the \emph{to} class, on
any host in the \emph{hosts} class.  If any class fails to match, permission
is denied.

The configuration file can contain comments, which start with a \lit{\#}
character and extend to the end of the line; this is the only time when
newlines are significant in the configuration file.

\subsubsection{Allow records}

A record like the one described above is represented in the configuration
file by an \emph{allow record}.  It has the following syntax:
\begin{grammar}

<allow>         ::= \[[
  `allow'
    \[ `[' <host-class> `]' \]
    <user-class> `->' \[ <user-class> \]
    \[ `:' <command-class> \]
  `;'
\]]

\end{grammar}
The items \<host-class>, \<user-class> and \<command-class> are all
\emph{class expressions}.  If you omit one of the classes, then it will match
all requests.  So saying
\begin{verbatim}
    allow EVILHACKER -> ;
\end{verbatim}
allows anyone in the `EVILHACKER' class to become anyone they like,
everywhere, and do anything.

\subsubsection{Class expressions}

Class expressions allow you to define classes of users, hosts and commands
conveniently.

All class expressions have the same high-level syntax, and it's fairly easy
to understand.  It looks a little bit like set notation: you can obtain the
union of two classes using the \lit{|} character (or), take intersections
using \lit{\&} (and), and subtract classes using \lit{-}.  Finally, you can
list several classes by separating them with commas \lit{,}.  The order of
precedence, from lowest to highest, is \lit{,}, \lit{-}, \lit{|} and
\lit{\&}.\footnote{
  Actually, the \lit{,} and \lit{|} operators do exactly the same thing.  The
  only difference is their relative precedence.  It probably helps if you
  think of them as being conceptually different, though.}
You can override the precedence rules by using parentheses.

The whole syntax looks like this:
\begin{grammar}

<class-expr>    ::= \[[
  \[ \< <class-minus-expr> \\ `,' \> \] <class-minus-expr>
 \]]

<class-minus-expr> ::= \[[
  \[ \< <class-or-expr> \\ `-' \> \] <class-or-expr>
\]]

<class-or-expr> ::= \[[
  \[ \< <class-and-expr> \\ `|' \> \] <class-and-expr>
\]]

<class-and-expr> ::= \[[
  \[ \< <class-primary> \\ `&' \> \] <class-primary>
\]]

<class-primary> ::= \[[
  \( `(' <class-expr> `)' \\ <class-name> \\ <explicit-item> \)
\]]

\end{grammar}

\subsubsection{Naming classes}

To save repetition, you can give names to classes, using one of the three
assignment statements:
\begin{grammar}

<user-assign>   ::= \[[ `user' <name> `=' <user-class> `;' \]]

<host-assign>   ::= \[[ `host' <name> `=' <host-class> `;' \]]

<command-assign> ::= \[[ `command' <name> `=' <command-class> `;' \]]

\end{grammar}

Classes can be defined in terms of themselves: saying
\begin{verbatim}
    user HACKERS = HACKERS | "mdw";
\end{verbatim}
says to add `mdw' to the class of hackers, for example.  The configuration
file is read strictly top-to-bottom, and an allow record already given
doesn't change its meaning just because you later redefine of the classes it
refers to.

\subsubsection{Naming users, hosts and commands}

Right: you now know how to define classes in terms of other classes, but
you've got to start somewhere.  Each type of class has its own way of
identifying members.
\begin{itemize}
\item A user may be identified either by writing the user's name in double
  quotes (e.g, \texttt{"mdw"}) or by giving the integer user id (e.g.,
  \texttt{272}).
\item A host may be specified by giving, in quotes, either the host's
  \emph{fully qualified} name (e.g., \texttt{"excessus.hacker.org"}), or its
  IP~address, (e.g., \texttt{"158.152.170.219"}).  Note that the IP~address
  must be quoted too: this is slightly unusual.  Either form may contain
  wildcards: \lit{?} matches any character, and \lit{*} matches zero or more
  characters.  For example, I can name all hosts at hacker.org by saying
  \texttt{"*.hacker.org"}.  \emergencystretch=10pt
\item A command may be specified by giving its \emph{full pathname} in quotes
  (e.g., \texttt{"/sbin/shutdown"}).  Again, wildcards can be used to specify
  lots of commands at the same time.
\end{itemize}

\subsubsection{Predefined names}

Before reading the configuration file, \become\ predefines a collection of
classes:
\begin{itemize}
\item For every user $u$, a class `$u$' is created containing that user.
\item For every group $g$, a class `$g$' is created containing all members of
  that group.
\item For each netgroup $n$ read from the NIS server, a class `\lit*{u_}$n$'
  is created containing all the users listed in the netgroup, and a class
  `\lit{h_}$n$' containing the IP address of all the hosts listed in the
  netgroup.\footnote{
    Netgroups don't fit in particularly well with \become's way of thinking.
    The netgroup idea tries to bind users and hosts together in tight little
    bundles, which doesn't help here.  The current behaviour of splitting
    the tight little host--user--domain bundles into separate lists of users
    and hosts is, to the author's knowledge, the cleanest way of making
    netgroups useful.

    It should probably be pointed out that, in general, NIS should be
    considered insecure.  Nothing too terrible should happen if you run your
    \become\ server on the NIS master machine.}
\end{itemize}
User and group names can contain characters (e.g., dashes or dots) which
aren't allowed in \become\ class names; \become\ automatically translates
any non-alphanumeric characters into underscores.

Note that by the end of this process, each class contains the \emph{union} of
all the things which are automatically put there.  So if your system has a
`root' group, then the class \lit{root} ends up containing the root user
together with all members of the root group.  You can be sure of referring to
a single user by enclosing the user name in quotes.  Hence
\begin{verbatim}
  allow HACKERS -> rcs;
\end{verbatim}
lets your syshacks become anyone in the rcs group, whereas
\begin{verbatim}
  allow HACKERS -> "rcs";
\end{verbatim}
lets them become the rcs user only.


\subsection{Configuring standalone installations}

That's it, really.  Make sure that \become\ can find the configuration file
on each host.  If \become\ can't find a server to talk to (which it can't
because you haven't configured one) it will parse the local configuration
file and decide for itself whether to grant the user's request.

If you're only interested in setting up a standalone installation, then
you're finished, and can get on with doing something interesting.
Alternatively, read on, and see all the work you don't have to do.  You
should probably note, however, that reading a configuration file for a
reasonable-sized site takes quite a long while, though; doing this in a
central server will make your users happier, as well as being less work for
you.


\subsection{Keys and random numbers}

Because \become\ uses cryptographic methods for communicating with its
server, you must set up some encryption keys for it to use.  You need to set
up two files, both in \become's system configuration directory:
\begin{itemize}
\item The file \path{become.key} contains \become's `master' key.  Someone
  who knows the master key can fake responses from the server, and grant
  themselves any privileges they like.
\item The file \path{become.random} contains a `random number seed' which is
  used (together with the master key) to generate random numbers (e.g.,
  session keys).  Someone who knows the random numbers can fake responses
  from the server, and grant themselves any privileges they like.  It's
  difficult to actually predict random numbers given the random number seed
  file, although it's not a good idea to leave the seed lying around.
\end{itemize}
Both of these files should be stored on a local filesystem, and they should
be readable only by the super-user.

The key contains a 128-bit number; the random number file contains a 512-bit
number.  Both numbers are written in hexadecimal.  To make the thing more
readable, you may insert dashes in the number between each chunk of eight digits.\footnote{
  Actually, you can insert dashes wherever you like in the number, but this
  is only because the parser is rather primitive.  The author recommends that
  you stick with every eight digits.}
Here's an example of a possible key file:
\begin{verbatim}
    4fda99b0-fcbd8bcb-d1bcf951-e1ed04c9
\end{verbatim}

You should generate 128 genuinely random bits for the key file.  It is
\emph{not} good enough to use a computer random number generator.  A program
will be supplied later which will examine key timings as a source for random
numbers.  Also, don't use the number printed above.  That would be really
silly.  To help you do this, a program `keygen' is provided.  It uses timings
of keypresses to generate random numbers.  To use the program to generate
the key file, type
\begin{verbatim}
    $ keygen -o become.key
\end{verbatim}
Keygen will report the number of bits which still need to be generated.  Keep
typing until it says `done'.  The program automatically ensures that its
output file, if it doesn't already exist, is readable only by its owner.  The
command line arguments to keygen are simple:
\begin{syntdiag}
`keygen' \< \[ `--bits' <number> \\ `--output' <file-name> \] \>
\end{syntdiag}
If you don't specify a \<number> of bits, a default of 128 random bits are
generated, which is correct for IDEA keys.  If you omit the \<file-name>, the
random key is written to standard output.

The random number file can be generated by saying
\begin{verbatim}
  keygen -o become.random -b 512
\end{verbatim}
However, \become\ will generate a random number file if it can't find one.
Note that its randomness acquisition isn't completely wonderful yet; the
author recommends that you \emph{do} generate a seed file.


\subsection{Setting up the server and clients}

As of version 1.2, the \become\ client is capable of sending its request to
multiple servers, which makes it more resilient to server failures.

You don't need a separate program to run as a \become\ server: the normal
\become\ is quite capable of behaving as a server all by itself.  However,
before you start the server up, you need to decide on a port to which it will
listen.  The author uses port 9876 for testing purposes, and there's not much
reason why you couldn't do the same.

There are three ways you can inform \become\ of your choice of port:
\begin{itemize}
\item You can pass the port number on the command line, using the
  \texttt{--port} option.
\item You can add a line saying `\syntax{"port" <number> ";"}' to the
  configuration file.
\item You can add an entry to your \path{/etc/services} file (or NIS map),
  binding your chosen port number to the name `become'.\footnote{
    Actually, \become\ searches for the port using the filename with which
    it was invoked, so if you call the \become\ binary \path{splat}, then
    \become will look for a service labelled `splat'.}
\end{itemize}
If \become\ still has no idea which port to use, it refuses to start up as a
server and reports an error message to you.

You can also choose a different key file to use, by writing a line of the
form `\syntax{"key" <filename> ";"}' in \path{become.conf}.  The client won't
listen to this -- only the server does that.

To make \become\ run as a server, say
\begin{verbatim}
    $ become --daemon
\end{verbatim}
(or to use an explicit port number, say something like
\begin{verbatim}
    $ become --daemon --port=9876
\end{verbatim}
replacing \texttt{9876} in the example with your chosen port).  You can also
run the daemon with a different configuration file, by using the
\texttt{--config-file} option, e.g.,
\begin{verbatim}
    $ become --daemon --config-file=/etc/become/server.conf
\end{verbatim}

Now to configure the clients.  All they need is a file saying where to find
the server or servers.  This has the syntax:
\begin{syntdiag}
  \< <host-name> \[ `:' <port> \] \>
\end{syntdiag}
The \<port> can be either a number (which is used directly) or a service
name, which is looked up in the system's services database (typically
\texttt{/etc/services}).  If you omit the port number, then \become\ looks in
the services database for a service with the name used to invoke it.  This
usage isn't recommended, however.\footnote{
  It's not actually a security risk, because even though a user could
  potentially make the client send its request to a different server, the
  server would only be able to build a valid reply if it knew the correct
  key.}

The server wakes up every half an hour to rescan its configuration and
encryption key.  Thus, it should react fairly quickly to changes to the user
database or to its configuration.  However, you can always force the server
to refetch its configuration files by sending it a SIGHUP signal.  To help
you do this, the server stores its process id in a file \path{become.pid}
within its system configuration directory.


\subsection{Maintaining \become}

There's not much to it really, apart from updating the configuration file
when your requirements change.

The only other thing you really ought to do is to periodically change the
master key.  This should be done about once a week, I'd suspect.  The
difficult part is distributing the keys over the network: you don't really
want to trust the old keys.  I'd recommend that you investigate `ssh' for key
distribution.


\subsection{Summary of \become\ configuration}

\subsubsection{Table of the configuration files}

\begin{tabularx}{\textwidth}{@{} >{\ttfamily}l X @{}}
  \multicolumn{1}{@{}l}{\textbf{File name}} &
  \multicolumn{1}{l@{}}{\textbf{Contents}} \\
  become.conf   & Main configuration file.  See the syntax below for the
                  complete reference \\
  become.key    & Master encryption key.  Should contain a 128-bit random
                  number. \\
  become.pid    & Server's process id (so that you can kill it).  The server
                  creates this file all by itself. \\
  become.random & Random number seed for generating session keys.  Should
                  also contain a 128-bit random number.  Don't be surprised
                  if the number keeps changing -- it's meant to. \\
  become.server & Tells the \become\ client where to find the server. \\
\end{tabularx}

\subsubsection{Definitive syntax for \path{become.conf}}

The syntax for \path{become.conf} files is shown below.  This mainly reprises
the syntax shown earlier, but in a different order, and without all the
explanatory text getting in the way.

Firstly, the lexical grammar is as follows:

\begin{grammar}

<comment>       ::= \[[
  `#' \< \tok{any character other than <new-line>} \> <new-line>
\]]

<name>          ::= \[[
  \tok{letter or `_'} \< \( \tok{letter or `_'} \\ \tok{digit} \) \>
\]]

<integer>       ::= \[[ \< \tok{digit} \> \]]

<string>        ::= \[[
  `"' \< \( \tok{any character other than `"', <new-line> or `\\'} \\
            `\\' \tok{any character other than <new-line>} \) \> `"'
\]]

\end{grammar}

All \<comment>s and whitespace are ignored entirely.  What's left is parsed
as follows:

\begin{grammar}

<become-conf>   ::= \[[ \< <statement> \> \]]

<statement>     ::= \[[
  \( \( `user' \\ `command' \\ `host' \) <name> `=' <class-expr> `;' \\
     `allow' <allow-spec> `;' \\
     `port' <integer> `;' \\
     `key' <string> `;' \)
\]]

<allow-spec>    ::= \[[
   \[ `[' <host-class> `]' \]
  <user-class> `->' \[ <user-class> \]
  \[ `:' <command-class> \]
\]]

<class-expr>    ::= \[[
  \[ \< <class-minus-expr> \\ `,' \> \] <class-minus-expr>
 \]]

<class-minus-expr> ::= \[[
  \[ \< <class-or-expr> \\ `-' \> \] <class-or-expr>
\]]

<class-or-expr> ::= \[[
  \[ \< <class-and-expr> \\ `|' \> \] <class-and-expr>
\]]

<class-and-expr> ::= \[[
  \[ \< <class-primary> \\ `&' \> \] <class-primary>
\]]

<class-primary> ::= \[[
  \( `(' <class-expr> `)' \\ <name> \\ <integer> \\ <string> \)
\]]

\end{grammar}


%%%--------------------------------------------------------------------------
\section{Cryptographic trivia}


\subsection{Design requirements}

The way the system works is that the \become\ client program builds a
\emph{request block} containing all the information needed to decide whether
the user's request is valid.  It then sends this to a server, asking it
whether this request should be granted.  If the server replies `yes', then
\become\ changes its uid, and runs the user's program.

The really important point is that the client must be able to trust the
responses it gets from the server: the final decision over whether to grant
the request lies only with the client.  The server doesn't really need to
worry too much about whether it trusts a request -- it's not going to do
anything with them anyway except send a reply back.


\subsection{Notation}

Some slightly weird mathematical notation is used in the following sections.
\begin{description}
\item [$a \xor b$] denotes the exclusive-or (XOR) operation (bitwise addition
  mod 2).
\item [$(a, b, c)$] denotes concatenation of the quantities $a$, $b$ and $c$.
\item [$a[x : y]$] denotes bits $x$ up to $y$ of $a$, including bit~$x$ but
  \emph{not} bit~$y$.  For example, $a[32:64]$ is a 32-bit quantity.  The
  bits are labelled starting from the left at zero, and increasing to the
  right.
\item [$E_{k, IV}(a)$] denotes encryption of $a$, using the key $k$ and
  initialisation vector $IV$.
\item [$D_{k, IV}(a)$] denotes decryption of $a$, using the key $k$ and
  initialisation vector $IV$.
\end{description}
Encryption is performed using the IDEA algorithm, in 64-bit ciphertext
feedback mode.


\subsection{The actual protocol}

The protocol \become\ uses to communicate with the server is as follows:
\begin{enumerate}

\item The client and server share a secret key~$k$.

\item The client calculates the following:
  \begin{description}
  \item [$F$] is the `from' user id;
  \item [$T$] is the `to' user id;
  \item [$C$] is the command the user wishes to execute;
  \item [$t$] is the current time, as returned from \texttt{time}(2); and
  \item [$p$] is the client's process id.
  \end{description}
  The fields $t$ and~$p$ are to ensure that the client doesn't get confused
  by replies to the wrong requests.

\item The client generates a session key~$s$ and initialisation vector~$IV$.
  It then calculates a checksum
  \[ X = MD5(F, T, C, t, p)[0:32] \]
  and sends the server a message
  \[ \bigl(IV, E_{k, IV}(s), E_{s, IV'}(F, T, C, t, p, X)\bigr) \]
  where $IV'$ is $E_{k, IV}(s)[64:128]$ (i.e., the last block of ciphertext
  after encrypting the session key, so the whole message is encrypted as one
  ciphertext feedback job, with a key change part-way).

\item The server decrypts the message, and checks it to make sure it's valid:
  \begin{itemize}
  \item It checks that $X$ is the correct checksum.
  \item It ensures that the difference between $t$ and the true time is
    acceptable.  (The current implementation allows $t$ to be 15 seconds
    out.)
  \end{itemize}
  If either of these checks fails, the request is rejected without
  acknowledgement.

\item The server decides whether to grant the request.  If it gives its
  permission, it sets $a = 1$; otherwise it sets $a = 0$.  It calculates a
  checksum
  \[ Y = MD5(t, p, a)[0:32] \]
  and sends the client a message
  \[ \bigl(IV'', E_{s, IV''}(t, p, a, Y)\bigr) \]
  where $IV''$ is the last 64~bits of ciphertext received from the client,
  continuing the ciphertext feedback again.  (Later versions of \become\
  might use a different method for deciding on the initialisation vector.)

\item The client decrypts the reply, and verifies it:
  \begin{itemize}
  \item It checks that $Y$ is a valid checksum.
  \item It checks that the $t$ and $p$ values received match the ones in the
    original request.
  \end{itemize}
  If either fail to match, the reply is discarded, and the client continues
  to wait for a valid reply (possibly timing out).

\item The client accepts the reply.  If $a = 1$ it changes uid and executes
  the named process~$C$.

\end{enumerate}

The encryption makes it hard for an attacker to alter the data being
transmitted in any meaningful way; the 32-bit checksum means that an altered
message has a $2^{-32}$ probability of not being noticed.

The use of ciphertext feedback mode attempts to prevent chosen-plaintext
attacks, even though the user can make the client send arbitrary messages.


\subsection{The `keygen' program}

The `keygen' program attempts to take advantage of the variations in time
between your keystrokes to generate random numbers.  It's not perfect.  It
may help a little if you know exactly how it works.

Keygen keeps track of the interval between keypresses.  It exclusive-ors
adjacent interval times together, and strips off leading and trailing
sequences of one- or zero-bits.  What's left is shifted into the accumulator.
The aim of all this complexity is to measure the variation in key timings,
and then discard any uninteresting bits from the result.

This method works best on machines with very high-resolution clocks
(preferably with microsecond granularity), although even on the author's
Linux machine, which uses a clock with centisecond granularity, the number of
keystrokes required is acceptable.


\subsection{How to break \become's security}

The author can't see any obvious weaknesses in the protocol used.  Here are
some possibilities which might occur to an attacker, though:
\begin{itemize}

\item Forge a server reply packet and send it to the client.  Intercept the
  request packet and discard it before it reaches the real server.  The
  required contents of the reply packet can be guessed.  However, encrypting
  it requires knowledge of the session key sent by the client.  Obtaining
  this means you need to break the IDEA cipher, which (to the author's
  knowledge) isn't practical.

\item Send another packet to the server at the same time, altering the sender
  address so that the server replies to the wrong host or port.  This won't
  work, because the client will attempt to decrypt the fake reply with the
  wrong session key and will reject the packet when it finds that the
  checksum is incorrect.

\item Find some other back door into the client host, to become root.  Read
  the secret key file, and use that to decrypt requests and send back
  replies.  If you can already become the super-user, why bother cracking
  \become?

\item Feed the client program bad input to overflow a fixed-size buffer.  The
  bad input contains executable code which gives the attacker a privileged
  shell.  The author isn't aware of any buffers which might overflow as a
  result of user-supplied data, and has checked the source rather carefully.

\end{itemize}

The above assumes that \become\ has been set up correctly.  The following
attacks rely on misconfiguration:
\begin{itemize}

\item Watch new secret keys being transmitted over the network when the
  administrator replaces them.  Now you can decrypt request packets and send
  back replies.  Make sure that the original server's responses are
  corrupted so that the client rejects them.

\item Watch the client or server reading the secret key from a remote
  filesystem.

\item Clobber the configuration file when the server re-reads it from a
  remote filesystem, so that it gives your user account permission to become
  anyone.

\end{itemize}


%%%----- That's all, folks --------------------------------------------------

\end{document}

%%% Local Variables: 
%%% mode: latex
%%% TeX-master: t
%%% End: