From d1e9af1ed42efc5d5c756d8169383cebab86531a Mon Sep 17 00:00:00 2001 From: mdw Date: Thu, 18 Sep 1997 11:16:07 +0000 Subject: [PATCH] Old TeX manual unnecessary now that the Texinfo one is complete. --- manual/become.tex | 889 ------------------------------------------------------ 1 file changed, 889 deletions(-) delete mode 100644 manual/become.tex diff --git a/manual/become.tex b/manual/become.tex deleted file mode 100644 index c01fd02..0000000 --- a/manual/become.tex +++ /dev/null @@ -1,889 +0,0 @@ -%%% -*-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' \[ \[ \< \> \] \] -\end{syntdiag} -and -\begin{syntdiag} - `become' `-c' -\end{syntdiag} -The first variant allows you to execute any \ as user \, -as limited by your site's configuration. The second variant simply passes -the \ to \path{/bin/sh}, so you must have permission to -execute the shell as \. 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" "/bin/sh -c" }', 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' - \[ `[' `]' \] - `->' \[ \] - \[ `:' \] - `;' -\]] - -\end{grammar} -The items \, \ and \ 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} - - ::= \[[ - \[ \< \\ `,' \> \] - \]] - - ::= \[[ - \[ \< \\ `-' \> \] -\]] - - ::= \[[ - \[ \< \\ `|' \> \] -\]] - - ::= \[[ - \[ \< \\ `&' \> \] -\]] - - ::= \[[ - \( `(' `)' \\ \\ \) -\]] - -\end{grammar} - -\subsubsection{Naming classes} - -To save repetition, you can give names to classes, using one of the three -assignment statements: -\begin{grammar} - - ::= \[[ `user' `=' `;' \]] - - ::= \[[ `host' `=' `;' \]] - - ::= \[[ `command' `=' `;' \]] - -\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' \\ `--output' \] \> -\end{syntdiag} -If you don't specify a \ of bits, a default of 128 random bits are -generated, which is correct for IDEA keys. If you omit the \, 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" ";"}' 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" ";"}' 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} - \< \[ `:' \] \> -\end{syntdiag} -The \ 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} - - ::= \[[ - `#' \< \tok{any character other than } \> -\]] - - ::= \[[ - \tok{letter or `_'} \< \( \tok{letter or `_'} \\ \tok{digit} \) \> -\]] - - ::= \[[ \< \tok{digit} \> \]] - - ::= \[[ - `"' \< \( \tok{any character other than `"', or `\\'} \\ - `\\' \tok{any character other than } \) \> `"' -\]] - -\end{grammar} - -All \s and whitespace are ignored entirely. What's left is parsed -as follows: - -\begin{grammar} - - ::= \[[ \< \> \]] - - ::= \[[ - \( \( `user' \\ `command' \\ `host' \) `=' `;' \\ - `allow' `;' \\ - `port' `;' \\ - `key' `;' \) -\]] - - ::= \[[ - \[ `[' `]' \] - `->' \[ \] - \[ `:' \] -\]] - - ::= \[[ - \[ \< \\ `,' \> \] - \]] - - ::= \[[ - \[ \< \\ `-' \> \] -\]] - - ::= \[[ - \[ \< \\ `|' \> \] -\]] - - ::= \[[ - \[ \< \\ `&' \> \] -\]] - - ::= \[[ - \( `(' `)' \\ \\ \\ \) -\]] - -\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: -- 2.11.0