From 7a53967aba4cbc63f7108760490bf5afe616d350 Mon Sep 17 00:00:00 2001 From: mdw Date: Thu, 18 Sep 1997 11:16:34 +0000 Subject: [PATCH] Brand new Texinfo manual, with wider scope than the original LaTeX one. --- manual/become.texi | 1592 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1592 insertions(+) create mode 100644 manual/become.texi diff --git a/manual/become.texi b/manual/become.texi new file mode 100644 index 0000000..4854b14 --- /dev/null +++ b/manual/become.texi @@ -0,0 +1,1592 @@ +\input texinfo @c -*-texinfo-*- +@c +@c $Id: become.texi,v 1.1 1997/09/18 11:16:34 mdw Exp $ +@c +@c Documentation for `become' +@c +@c (c) 1997 EBI +@c + +@c ----- Revision history --------------------------------------------------- +@c +@c $Log: become.texi,v $ +@c Revision 1.1 1997/09/18 11:16:34 mdw +@c Brand new Texinfo manual, with wider scope than the original LaTeX one. +@c + +@c ----- Standard boilerplate ----------------------------------------------- + +@c %**start of header +@setfilename become +@settitle Become +@setchapternewpage odd +@footnotestyle end +@paragraphindent 0 +@iftex +@c @smallbook +@afourpaper +@c @parindent=0pt +@end iftex +@c %**end of header + +@c ----- Useful macros ------------------------------------------------------ + +@set version 1.2--pre + +@c ----- Copyright matters -------------------------------------------------- + +@c --- The `Info' version --- + +@ifinfo + +This file documents Become version @value{version}. + +Copyright (c) 1997 European Bioinformatics Institute. + +Permission is granted to make and distribute verbatim copies of this +manual provided the copyright notice and this permission notice are +preserved on all copies. + +@ignore +Permission is granted to process this file through TeX and print the +results, provided the printed document carries a copying permission +notice identical to this one except for the removal of this paragraph +(this paragraph not being relevant to the printed manual). + +@end ignore +Permission is granted to copy and distribute modified versions of this +manual under the conditions for verbatim copying, provided also that the +sections entitled `Copying' and `GNU General Public License' are +included exactly as in the original, and provided that the entire +resulting derived work is distributed under the terms of a permission +notice identical to this one. + +Permission is granted to copy and distribute translations of this manual +into another language, under the above conditions for modified versions, +except that this permission notice may be stated in a translation +approved by the European Bioinformatics Institute. + +@end ifinfo + +@c --- Printed title page --- + +@titlepage + +@title The Become program +@subtitle Become version @value{version} +@author Mark Wooding (@email{mdw@@ebi.ac.uk}) +@page + +@vskip 0pt plus 1filll + +Copyright @copyright{} 1997 European Bioinformatics Institute. + +Permission is granted to make and distribute verbatim copies of this +manual provided the copyright notice and this permission notice are +preserved on all copies. + +Permission is granted to copy and distribute modified versions of this +manual under the conditions for verbatim copying, provided also that the +sections entitled `Copying' and `GNU General Public License' are +included exactly as in the original, and provided that the entire +resulting derived work is distributed under the terms of a permission +notice identical to this one. + +Permission is granted to copy and distribute translations of this manual +into another language, under the above conditions for modified versions, +except that this permission notice may be stated in a translation +approved by the European Bioinformatics Institute. + +@end titlepage + + +@c -------------------------------------------------------------------------- +@ifinfo +@node Top, Copying, (dir), (dir) +@top Become + + +Become is a system for managing shared accounts. It allows users to +`become' other users in order to do useful work. It can be managed on a +central server (or a small number of central servers), or it can run +standalone. + +This file documents Become version @value{version}. + +@end ifinfo + +@menu +* Copying:: Your rights to distribute and modify +* Introduction:: A brief introduction to Become +* Becoming someone else:: How to become somebody else +* Administering Become:: How to maintain Become +* Invoking Become:: Reference to Become's command line options + + --- The Detailed Node Listing --- + +Becoming someone else + +* Terminology:: Some important terms defined +* Environment:: Login styles and environment variables +* Group permissions:: How Become handles group permissions +* X authority:: Problems with X authority files +* Running commands:: Running commands other than a shell + +How Become sets up the environment + +* New environment variables:: Become adds some useful environment variables +* Login styles:: Choose how Become sets the environment +* Tweaking the environment:: Altering individual environment variables +* Removed variables:: Some environment variables aren't passed on +* Shared environments:: Tips for handling shared accounts + +Login styles + +* The preserve style:: Preserve the current environment +* The set-user style:: Set user-specific variables (like @code{su}) +* The login style:: Clear the environment (like @code{login}) + +How Become handles groups + +* Primary group selection:: Setting the new primary group +* Subsidiary groups:: Setting subsidiary group memberships + +Considerations for X authority + +* The user-group method:: A secure method for handling X authority +* Using xauth:: A less secure method, which might be easier + +Become administration + +* Configuration files:: Overview of Become's configuration files +* Standalone or networked:: The two main types of Become installations +* The configuration file:: How to define who's allowed to do what +* Networked configuration:: + +The configuration file + +* Basic syntax:: Quick overview of Become's syntax +* Classes:: Defining classes of things +* Predefined classes:: Become predefines some (maybe) useful classes +* Allow statements:: Allow users to become other users +* Other statements:: Some other useful statements +* Example configuration file:: An example, showing a few features. +* Complete grammar:: Complete grammar for Become config files + +Networked configuration + +* Choosing servers:: Which servers Become tries to talk to +* Setting up keys:: How to generate keys for Become +* Random number files:: Become keeps random number state around +* Issuing a new key:: How to issue new keys without disruption + +Setting up keys + +* Invoking keygen:: How to use the @code{keygen} program + +Invoking Become + +* Becoming another user:: Options for becoming another user +* Starting Become daemons:: Options for starting Become daemons +* Debugging options:: Options to use when Become goes wrong +@end menu + +@c -------------------------------------------------------------------------- +@node Copying, Introduction, Top, Top +@unnumbered The GNU General Public License + + +@include gpl.texi + + +@c -------------------------------------------------------------------------- +@node Introduction, Becoming someone else, Copying, Top +@unnumbered Introduction + + +It's often useful to be able to share accounts between a number of +users. For example, a group maintaining an externally visible service +need to be able to start and kill the server process. Giving such a +shared account a password is a fairly bad plan: such passwords tend not +to get changed very often, and they have a habit of spreading beyond the +group of legitimate users. + +The Become program presented here offers a solution to the problems of +shared accounts. It allows the system adminstrator to define which +users are allowed access to which accounts, on which hosts, and to +execute which commands. Such shared accounts can then, in general, have +their passwords removed. + +This coincidentally has another advantage: when `becoming' to a shared +account, a user can retain her@footnote{Or his. I'll choose one or the +other fairly randomly throughout this manual.} own environment, which +she's carefully crafted and honed over the years, rather then being +presented with some lowest-common-denominator setup which probably +doesn't even use the right shell. + +The configuration file for Become can either be distributed to all the +various hosts in a network or a few carefully set up and secure servers +(@pxref{Standalone or networked}). + + +@c -------------------------------------------------------------------------- +@node Becoming someone else, Administering Become, Introduction, Top +@chapter Becoming someone else + + +The simplest way to become someone else is to say + +@example +become @var{user} +@end example + +@noindent +Become will check to see whether you're allowed to become @var{user}. If you +are, it starts a shell process with the user-id set to @var{user}. Any +commands you type are executed with the privileges of @var{user}. + +The full invocation is slightly more complicated: + +@example +become [@var{option}@dots{}] [@var{env-var}@dots{}] @var{user} [@var{command} [@var{arg}@dots{}]] +@end example + +Actually, the @var{option}s, @var{env-var}s and @var{user} can be in any +order -- the important point is that all of them appear before the +@var{command}, if there is one. + +@menu +* Terminology:: Some important terms defined +* Environment:: Login styles and environment variables +* Group permissions:: How Become handles group permissions +* X authority:: Problems with X authority files +* Running commands:: Running commands other than a shell +@end menu + + + +@node Terminology, Environment, Becoming someone else, Becoming someone else +@section Terminology + +The following terms get used quite a bit in the following text: + +@table @asis +@item request +An invocation of Become, asking permission to become another user. + +@item old user +The (real) user id of the process which invoked Become; usually, this will be +your normal user id. + +@item target user +The user whom you want to become, named in a request. +@end table + + + +@node Environment, Group permissions, Terminology, Becoming someone else +@section How Become sets up the environment + +There are thorny problems with handling the user's environment. It seems +that (the author's initial assessment notwithstanding) there is no single +best way of handling environment variables. As a result, Become can do just +about everything you might want it to. This gets slightly complicated. +Don't worry: it's not as hard as all that. + +@menu +* New environment variables:: Become adds some useful environment variables +* Login styles:: Choose how Become sets the environment +* Tweaking the environment:: Altering individual environment variables +* Removed variables:: Some environment variables aren't passed on +* Shared environments:: Tips for handling shared accounts +@end menu + + +@node New environment variables, Login styles, Environment, Environment +@subsection Environment variables created by Become + +To help you (and, more importantly, your startup scripts) keep track of who +you are, and who you were originally, Become adds some variables to the +environment of any processes it starts. + +@table @code +@item BECOME_USER +The name of the target user (i.e., the user you are now). It might be useful +to test this value in shell startup scripts, for example. + +@item BECOME_HOME +The home directory of the target user. It can be handy to read startup and +other configuration files from here. + +@item BECOME_OLD_USER +The name of the user who invoked Become. + +@item BECOME_OLD_HOME +The home directory of the `old' user. + +@item BECOME_ORIGINAL_USER +This is intended to be the name you logged in with. If it's unset, Become +sets it to be the same as @code{BECOME_OLD_USER}; otherwise it leaves it +unchanged. + +@item BECOME_ORIGINAL_HOME +This is intended to be the home directory you logged in with. If it's unset, +Become sets it to be the same as @code{BECOME_OLD_HOME}; otherwise, it leaves +it unchanged. +@end table + +Don't even think about relying on these variables as a form of +authentication. It won't work. They're provided only to help organise +startup scripts. + + + +@node Login styles, Tweaking the environment, New environment variables, Environment +@subsection Login styles + +Originally, Become always tried to preserve your environment. There's a +rational explanation for this approach, which is given in the description of +the `preserve' style below. Unfortunately, not everyone liked this +approach. As a result, there's now a collection of different login styles. + +Login styles are selected by giving command line arguments: + +@table @code +@item -p +@itemx --preserve +The original style: try to preserve the existing user's environment as much +as possible. + +@item -s +@itemx --set-user +Set some user-specific variables, like @code{USER} and @code{HOME} to reflect +the target user rather than the old user. All other variables are preserved. + +@item -l +@itemx --login +Attempts to make the `become' process as much like a real login as possible. +All variables not explicitly preserved are deleted, and a new environment is +built, reflecting the target user. +@end table + +The various styles, and the reasons behind them, are described below. + +@menu +* The preserve style:: Preserve the current environment +* The set-user style:: Set user-specific variables (like @code{su}) +* The login style:: Clear the environment (like @code{login}) +@end menu + + +@node The preserve style, The set-user style, Login styles, Login styles +@subsubsection The `preserve' login style + +You've spent many hours (days? weeks, even?) customising and honing your +startup files, learning how to use your shell, and tweaking your favourite +text editor until it's just the way you like it. So there can be few things +more annoying than logging into a shared account to find out that the shell's +wrong, your editor startup files are ignored, and nothing works quite the way +you'd like it to. Typically you can't change this without annoying the other +users: the result is a horrible compromise which dissatisfies everyone +equally. + +The `preserve' style lets you take your standard environment with you when +you become someone else. It tries hard not to modify any environment +variables. + +Become starts your standard shell. If you have an environment variable +@code{SHELL} defined, than this is executed. Otherwise, the shell specified +in your entry in the password file is used. (You must have permission to +execute whatever shell is chosen as the target user, or you'll just be given +an error message.) + +Most programs look at environment variables in preference to looking up +entries in the password database; e.g., they tend to use @code{USER} or +@code{LOGNAME} for the user name, and @code{HOME} for your home directory. +As a result, most programs will continue to find their configuration files in +your home directory. Also, systems like RCS will use your real name, rather +than the name of the user that you have become. + +To make best use of this login style, you may need to adjust your login +scripts to notice when @code{BECOME_USER} is someone else, and read in +appropriate definitions. For example, a `bash' user might say something like +this in her @file{.bashrc}: + +@example +if [ -n "$BECOME_HOME" ]; then . $BECOME_HOME/.bashrc +@end example + +@noindent +Similarly, a C shell user (either `tcsh' or `csh') might say something like + +@example +if ($?BECOME_HOME) source $@{BECOME_HOME@}/.cshrc +@end example + +(Note that plain Bourne shell users have a slight problem, because the Bourne +shell only reads configuration things on a login, not when a normal +interactive shell is started.) + + +@node The set-user style, The login style, The preserve style, Login styles +@subsubsection The `set-user' login style + +The author sees the main use of Become as allowing a user to acquire the +privileges associated with a shared account without all the problems which +shared accounts usually cause. To the author's way of thinking, one of the +main problems is that your environment gets replaced by something alien and +wrong. People disagree with me over this point, and for this reason the +`set-user' style exists. + +The objective of `set-user' style is to behave similarly to the standard +@code{su} command. Unless they've been preserved explicitly (@pxref{Tweaking +the environment}), `set-user' mode sets the following environment variables: + +@table @code +@item USER +@itemx LOGNAME +The name of the target user. + +@item HOME +The home directory of the target user. + +@item SHELL +The target user's default shell +@end table + +The result of this is that the shell will read the target user's +configuration files and present you with the environment set up there. + +I can't think of this style as being anything other than a migration aid +while users are getting used to the freedom offered by the `preserve' style. + + +@node The login style, , The set-user style, Login styles +@subsubsection The `login' login style + +The `login' style causes Become to attempt to emulate a full login. Become +will empty the environment of any variables which aren't explicitly preserved +(@pxref{Tweaking the environment}). It will then set the following +variables: + +@table @code +@item USER +@itemx LOGNAME +The name of the target user. + +@item HOME +The home directory of the target user. + +@item SHELL +The target user's default shell + +@item MAIL +An educated guess at where the target user's mailbox is. +@end table + +By default, it runs the target user's shell, informing it that this is a +login by setting the first character of @code{argv[0]} to @samp{-}. + +Become makes no entries in the @file{utmp} and @file{wtmp} files. + + + +@node Tweaking the environment, Removed variables, Login styles, Environment +@subsection Tweaking individual environment variables + +Become's login styles provide a sort of course-grained control over the +environment. Sometimes the control isn't fine enough. Become lets you tweak +individual variables: you can set, delete, or preserve named variables from +modification. + +There are three different things you can do with environment variables: + +@itemize @bullet +@item +Set a variable called @var{var} to a value @var{value}, by saying + +@example +@var{var}=@var{value} +@end example + +@noindent +The variable is preserved from automatic deletion by the login-style rules. + +@item +Delete a variable called @var{var} from the environment, by saying + +@example +@var{var}- +@end example + +@item +Preserve a variable @var{var} from being deleted or modified by Become's +login-style rules, but not change its value, by saying + +@example +@var{var}! +@end example +@end itemize + +Just to try and make this slightly more sensible, here's an example. Suppose +I want my @code{XAUTHORITY} variable to be set when I become user `fred': + +@example +become XAUTHORITY=$HOME/.Xauthority fred +@end example + +@noindent +should do the job nicely. Similarly, if I want to log in as `bob', but don't +want my @code{EDITOR} variable to change: + +@example +become --login EDITOR! bob +@end example + +@noindent +(Of course, in this example, I'm at the mercy of Bob's shell init files as to +whether his choice of editor overrides mine.) + + + +@node Removed variables, Shared environments, Tweaking the environment, Environment +@subsection Variables removed from the environment + +Some variables are removed from the environment which Become passes to a +program for security reasons: + +@table @code +@item LD_* +@itemx SHLIB_PATH +@itemx LIBPATH +@itemx _RLD_* +These variables are used on various systems as a search path for shared +libraries. Clearly, by manipulating these search paths, an attacker could +replace a standard shared library with one of his own. + +@item IFS +The shell input field separator. Modifying this variable radically alters +the way shells parse their inputs. (In particular, consider the case where +@code{IFS} contains @samp{/}.) + +@item ENV +@itemx BASH_ENV +Used by some shells: it contains the name of a file to read on every shell +invocation. + +@item KRB_CONF +@ignore +I'm not really sure what's going on here, so I'll just have to bluff my way +through. I think that the following is more-or-less accurate, having browsed +a small amount of Kerberos-related documentation. +@end ignore +Contains the name of a Kerberos configuration file. By manipulating this +variable, an attacker could persuade a program to believe the wrong +authentication server. +@end table + +Also note that the @code{PATH} variable is modified: any items which aren't +absolute pathnames are removed from the path. This check may become stricter +in future, although getting the balance between security and convenience is +particularly hard here. + + + +@node Shared environments, , Removed variables, Environment +@subsection Handling common environments for shared accounts + +FIXME: this needs writing. + + + +@node Group permissions, X authority, Environment, Becoming someone else +@section How Become handles groups + +As well as handling changes of user id, Become also changes group ids. +The exact changes Become makes are under user control. + +@menu +* Primary group selection:: Setting the new primary group +* Subsidiary groups:: Setting subsidiary group memberships +@end menu + + +@node Primary group selection, Subsidiary groups, Group permissions, Group permissions +@subsection Choosing a new primary group + +By default, the primary group is chosen according to the login style +(@pxref{Login styles}): the `preserve' style retains the current primary +group, while `set-user' and `login' styles choose the target's primary group. + +You can override Become's default choice using the @code{--group} (@code{-g} +for short) option: + +@example +become --group=@var{group} @dots{} +@end example + +The chosen @var{group} may be either a group name or a numeric gid. The +group must be one of the following: + +@itemize @bullet +@item +Your current primary group. +@item +One of your current subsidiary groups. +@item +The target user's primary group. +@item +One of the target user's subsidiary groups. +@end itemize + +Become will raise an error if this isn't the case. + + +@node Subsidiary groups, , Primary group selection, Group permissions +@subsection Handling subsidiary group memberships + +Subsidiary group memberships are a powerful tool for managing permissions +under Unix. Traditionally, they tend to be tied to particular users. Become +tries to be sightly more intelligent about group memberships. + +Become has a concept of @dfn{group style}, analogous to login style +(@pxref{Login styles}). The styles are selected by giving command line +arguments: + +@table @code +@item -k +@itemx --keep-groups +Retain the existing group memberships; don't add any new groups. + +@item -m +@itemx --merge-groups +Merge group memberships of the target user with the exiting memberships. + +@item -r +@itemx --replace-groups +Replace the existing group memberships with the target user's memberships. +@end table + +Again, the defaults are dependent on the chosen login style. Both `preserve' +and `set-user' merge group memberships; the `login' style replaces the set of +groups. + +Note that you can do perverse things like replace all the subsidiary groups +but retain your primary group (using the @code{--group} option; +@pxref{Primary group selection}) if you like: Become won't try to stop you. + + + +@node X authority, Running commands, Group permissions, Becoming someone else +@section Considerations for X authority + +Other users can't read your @file{.Xauthority} file, if you have one. This +is as it should be: anyone who can read it can connect to your X server and +read or generate events. However, once you've become another user, you can't +open any X windows; this can be annoying if your favourite editor is X-based. + +There are two basic approaches. Either you can send the shared account a +copy of your display's magic cookie, or you can retain permission to read the +cookie file. + +@menu +* The user-group method:: A secure method for handling X authority +* Using xauth:: A less secure method, which might be easier +@end menu + + +@node The user-group method, Using xauth, X authority, X authority +@subsection The user-group method for handling X authority + +This method is completely secure only if your site uses the `user-group' +system. In this system, each user is allocated a group containing only that +user. Usually this is made the user's default primary group, although that's +not necessary here. + +When you start a new X session, ensure that your cookie file is owned by you +and your private group. Change the file's permissions so that it's group +readable. Finally, ensure that your private group is retained when you +become someone else (@pxref{Group permissions}), and that the +@code{XAUTHORITY} variable is set correctly. + +The following Bourne shell code in a @file{.xinitrc} should do most of the +work: + +@example +XAUTHORITY="$HOME/.Xauthority" +export XAUTHORITY +chgrp mygroup $XAUTHORITY +chmod 640 $XAUTHORITY +@end example + +@noindent +In a C shell, this becomes + +@example +setenv XAUTHORITY $@{HOME@}/.Xauthority +chgrp mygroup $XAUTHORITY +chmod 640 $XAUTHORITY +@end example + +The @code{XAUTHORITY} file is preserved by both the `preserve' and `set-user' +login styles, so this isn't a problem. You can now become other users, and +your X permissions will follow you around correctly. + +It's probably worth noting that the @code{xauth} program annoyingly resets +the permissions on the cookie file every time it writes to it. This will be +particularly irritating if you use @code{ssh}'s X forwarding capabilities, +because every @code{ssh} connection will reset the permissions. You can deal +with this problem by putting a line + +@example +chmod 640 $@{XAUTHORITY-$HOME/.Xauthority@} 2>/dev/null +@end example + +@noindent +in your @file{.bashrc} or @file{.profile} (for Bourne-like shell users) or + +@example +if ($?XAUTHORITY) then + chmod 640 $XAUTHORITY >&/dev/null +else + chmod 640 $@{HOME@}/.Xauthority >&/dev/null +endif +@end example + +@noindent +in @file{.cshrc} for C shell users. + + + +@node Using xauth, , The user-group method, X authority +@subsection The `xauth' method for handling X authority + +This method sends your X cookie to the shared account. It's therefore +intrinsically dangerous: you must be able to trust the other users of the +shared account not to take undue advantage of this situation. + +The following (Bourne) shell snippet illustrates how you might send an +authorisation cookie to the shared account, to allow it to connect to your +display: + +@example +if test -n "$BECOME_HOME"; then + XAUTHORITY="$BECOME_HOME/.Xauthority"; export XAUTHORITY +elif test -n "$DISPLAY" && test -z "done_xauth_cookie"; then + case "$DISPLAY" in + :0.0) display=`hostname`:0.0 ;; + *) display="$DISPLAY" ;; + esac + xauth extract - $display | \ + become someone -c 'xauth -f $BECOME_HOME/.Xauthority merge -' + done_xauth_cookie=yes; export done_xauth_cookie +fi +@end example + +The equivalent C shell code is + +@example +if ($?BECOME_HOME) then + setenv XAUTHORITY "$@{BECOME_HOME@}/.Xauthority +else if ($?DISPLAY && ! $?done_xauth_cookie) then + if ($DISPLAY == :0.0) then + set display="`hostname`:0.0" + else + set display="$DISPLAY" + endif + xauth extract - $display | \ + become someone -c 'xauth -f $BECOME_HOME/.Xauthority merge -' +endif +@end example + +It works as follows: + +@itemize @bullet +@item +If the variable @code{BECOME_HOME} is set, then we're probably really someone +else, so point to the shared account's authority file. + +@item +Otherwise, check to see whether we have a display, and the authorisation has +not already been sent. If this is so, resolve a local display name into a +remote one (just in case) and then send it to the shared account. +@end itemize + + + +@node Running commands, , X authority, Becoming someone else +@section Executing specific commands + +As well as starting shells, Become can run single commands. This can be +useful in two ways: + +@itemize @bullet +@item +It enables Become to be used in scripts. + +@item +It allows access to shared accounts to be controlled on the basis of the +command to be run. +@end itemize + +To run a command as another user, say: + +@example +become @var{user} @var{command} [@var{argument}@dots{}] +@end example + +If the request is granted, Become runs @var{command}, passing it any +arguments following the command name. Become doesn't run a shell, so there's +no extra escaping which needs to be done. + +If you really want to run a shell command as another user, you can use the +@code{-c} option: + +@example +become @var{user} -c @var{shell-command} +@end example + +This is exactly equivalent to + +@example +become @var{user} /bin/sh -c @var{shell-command} +@end example + +in every way. In particular, you must have permission to run @file{/bin/sh} +as @var{user} for it to work: Become doesn't attempt to interpret the shell +command in any way. Also note that Become always uses the Bourne shell, +regardless of your current shell preference, or @var{user}'s default shell. +(This is done to provide a stable programming interface which works +irrespective of changes to the shared account's configuration.) + + +@c -------------------------------------------------------------------------- +@node Administering Become, Invoking Become, Becoming someone else, Top +@chapter Become administration + + +This chapter will explain how Become is administrated and maintained. + +@menu +* Configuration files:: Overview of Become's configuration files +* Standalone or networked:: The two main types of Become installations +* The configuration file:: How to define who's allowed to do what +* Networked configuration:: Considerations for networked installations +@end menu + + + +@node Configuration files, Standalone or networked, Administering Become, Administering Become +@section Configuration files + +Become keeps its configuration and administrative files in a directory +usually named @file{/etc/become}, although this can be changed with the +@code{--with-etcdir} option to the configuration script when you build +Become. + +Not all of the files are needed on all machines. + +@table @file +@item become.conf +The main configuration file, containing a description of which users are +allowed to become which other users, where, and what they're allowed to run +when they get there. Only needed on servers or standalone machines. + +@item become.server +A list of servers to contact. Only needed on client machines. + +@item become.key +The encryption key to use when sending requests to servers. Needed on +clients and servers, but not on standalone machines. + +@item become.pid +The process id of the server. Created automatically by Become's server when +in starts up. + +@item become.random +Contains state information for Become's random number generator. Created +automatically if it doesn't exist. +@end table + + +@node Standalone or networked, The configuration file, Configuration files, Administering Become +@section Installation types + + +Become can be installed in two different ways, depending on how you want to +administer it: + +@itemize @bullet +@item +In a @dfn{standalone} installation, each Become request is dealt with +locally: the program reads the configuration file, and decides whether it +should grant or deny permission. + +Standalone installations don't depend on servers being available, or even on +the existance of a network. They're useful for small sites, or sites with a +small number of users. The disadvantages are that reading the configuration +file takes a while, so the program doesn't feel as responsive as it should, +and ensuring that all the hosts' configuration files are synchronised becomes +difficult when you have lots of machines. + +@item +In a @dfn{network} installation, any Become requests are sent on to a +collection of servers. The servers analyse the request and send a reply back +which either authorises or forbids access. + +A networked installation clearly depends on the servers' reliability. The +client reacts only to the first reply it receives, so as long as there is one +server running, everything should continue as normal. + +A networked installation is useful when you have a large number of client +machines, particularly ones which may not be awake all the time. The full +configuration file only needs to be installed on a small number of servers; +the clients require only a list of server machines to contact, and an +encryption key to use. +@end itemize + + + +@node The configuration file, Networked configuration, Standalone or networked, Administering Become +@section The configuration file + +The main configuration file, usually called @file{/etc/become/become.conf}, +contains all the rules which Become uses to decide whether to grant or deny +requests. It may also contain additional information for the benefit of +Become daemons, if you're using a networked installation. + +@menu +* Basic syntax:: Quick overview of Become's syntax +* Classes:: Defining classes of things +* Predefined classes:: Become predefines some (maybe) useful classes +* Allow statements:: Allow users to become other users +* Other statements:: Some other useful statements +* Example configuration file:: An example, showing a few features. +* Complete grammar:: Complete grammar for Become config files +@end menu + + +@node Basic syntax, Classes, The configuration file, The configuration file +@subsection Basic configuration file syntax + +The configuration file consists of a sequence of statements, each terminated +by a semicolon. + +Comments begin with a @samp{#} character, and continue to the end of the +line. This is the only time newlines behave specially: newlines behave just +like any other whitespace characters within statements. + +Strings are enclosed in double-quote characters (@samp{"}). Within a string, +a backslash causes the following character to be treated literally, whatever +it may be (including quotes, backslashes and newlines). + +Names begin with an alphabetic character or an underscore, and consist of +letters, digits and underscores. + +In general, ... + + + +@node Classes, Predefined classes, Basic syntax, The configuration file +@subsection Classes + +A @dfn{class} in Become is a set of users, hosts or commands. You can define +and name your own classes using statements of the form: + +@example +user @var{name} = @var{class-expr} ; +command @var{name} = @var{class-expr} ; +host @var{name} = @var{class-expr} ; +@end example + +A @var{class-expr} is an expression defining a class. You can build a +complex class out of simple classes using the operators (in ascending +precedence order) @samp{,}, @samp{-}, @samp{|} and @samp{&}, which represent +the set options `union', `subtraction', `union' (again!), and `intersection'. +Subexpressions can be parenthesised to override the default precedence. +Once a class name has been defined, as shown above, it can be used in +subsequent class expressions. + +A single user may be designated by either a user name (in quotes) or an +integer uid. Commands and hosts may be designated by quoted strings which +may contain wildcards. Host strings are matched against both numeric (dotted +quad) IP addresses and the reverse-resolved hostname. Command strings are +matched against the absolute pathname of the command the user wants to +execute. + + + +@node Predefined classes, Allow statements, Classes, The configuration file +@subsection Predefined classes + +In an attempt to make life a bit easier, Become creates a collection of +predefined classes. + +The standard classes @code{all} and @code{none} match anything and nothing +respectively. The @code{all} class is useful in some contexts: it gives you +a way of saying `everything except@dots{}', for example: + +@example +user MUNDANES = all - SYSHACKS; +@end example + +@noindent +The @code{none} class isn't particularly useful in itself. It's there for +completeness. + +Become also defines some other classes: + +@itemize @bullet +@item +For each username @var{user}, Become adds a class called @samp{@var{user}} +which matches just that user. + +@item +For each group name @var{group}, Become creates a class called +@samp{@var{group}} which matches any user who is a member of that group. + +@item For each netgroup @var{netgroup}, Become creates two classes: +@samp{u_@var{netgroup}} which matches any user listed in the netgroup, and +@samp{h_@var{netgroup}} which matches any host listed in the netgroup. +@end itemize + +If a name is used for both a user @emph{and} a group, then corresponding +class ends up containing the user together with all of the group members. +For this reason, it's probably better to use the predefined classes for +groups rather than individual users -- use quoted user names for individual +users. + +Note that users and groups are read using the standard @code{get*ent} calls +@emph{and} directly from the NIS server (if there is one). The idea here is +that a Become server can be run on a machine which allows restricted logins. +It still needs to know about all the users known to the outside world. + +Netgroups are read only from the NIS servers. In particular, although GNU +systems allow netgroup databases to be stored in local files, Become wonn't +read them because there's no defined interface for enumerating netgroups. + + +@node Allow statements, Other statements, Predefined classes, The configuration file +@subsection Allow statements + +Defining classes is just a means to an end. The end is to specify which +users are allowed to do what, where, and as whom. This is done with an +@code{allow} statement: + +@example +allow [[@var{host-class}]] [@var{user-class}] -> [@var{user-class}] [ : @var{command-class}] +@end example + +(The @var{host-class} is optional, but must be enclosed in square brackets if +present.) + +The four classes in an allow statement are called, respectively, the `host', +the `to-user', the `from-user' and the `command'. Any of the four classes +may be omitted, and an omitted class defaults to `all'. + +When a request is received, Become checks the fields in the request against +the classes in each allow statement of the configuration file. If a +statement matches, the request is granted; if there are no full matches, +the request is denied. + + +@node Other statements, Example configuration file, Allow statements, The configuration file +@subsection Other statements + +Two other statement types are defined. They only have an effect on Become in +daemon mode: + +@example +port @var{port} ; +keyfile @var{key-file} ; +@end example + +@noindent +The @code{port} statement specifies the port to which the server should +listen; the @var{port} may be be an integer or a quoted service name. The +@code{keyfile} statement instructs Become to use the key from the file named +@var{key-file}, which must be a quoted string. + + +@node Example configuration file, Complete grammar, Other statements, The configuration file +@subsection An example configuration file + +@example +# +# become.conf +# +# Example configuration file +# + +allow wheel -> "root"; + +user NEWS = "fred", "jim"; +allow NEWS -> "news"; + +user HTTP = "jim", "bob"; +allow HTTP -> "httpd" : "/bin/kill", "/etc/init.d/httpd"; +@end example + + +@node Complete grammar, , Example configuration file, The configuration file +@subsection Complete grammar for configuration files + +@format +@var{file} ::= @var{file} @var{statement} + +@var{statement} ::= @var{class-def} + | @var{allow-spec} + | @var{port-spec} + | @var{key-spec} + +@var{class-def} ::= @samp{user} @var{name} = @var{class-expr} @samp{;} + | @samp{command} @var{name} = @var{class-expr} @samp{;} + | @samp{host} @var{name} = @var{class-expr} @samp{;} + +@var{allow-spec} ::= @samp{allow} @var{opt-host-spec} @var{opt-user-spec} + @samp{->} @var{opt-user-spec} @var{opt-command-spec} @samp{;} + +@var{opt-host-spec} ::= @samp{[} @var{class-expr} @samp{]} + | @var{empty} + +@var{opt-user-spec} ::= @var{class-expr} + | @var{empty} + +@var{opt-command-spec} ::= @samp{:} @var{class-expr} + | @var{empty} + +@var{port-spec} ::= @samp{port} @var{integer} @samp{;} + | @samp{port} @var{string} @samp{;} + +@var{key-spec} ::= @samp{keyfile} @var{string} @samp{;} + +@var{class-expr} ::= @var{class-diff-expr} + | @var{class-expr} @samp{,} @var{class-diff-expr} + +@var{class-diff-expr} ::= @var{class-isect-expr} + | @var{class-diff-expr} @samp{-} @var{class-union-expr} + +@var{class-union-expr} ::= @var{class-isect-expr} + | @var{class-union-expr} @samp{|} @var{class-isect-expr} + +@var{class-isect-expr} ::= @var{class-primary} + | @var{class-isect-expr} @samp{&} @var{class-primary} + +@var{class-primary} ::= @samp{(} @var{class-expr} @samp{)} + | @var{string} + | @var{integer} + +@var{integer} ::= one or more digits (@samp{0}--@samp{9}) + +@var{name} ::= an alphabetic character or underscore, followed by zero or + more alphanumeric characters or underscores + +@var{string} ::= @samp{"} @var{string-chars} @samp{"} + +@var{string-chars} ::= @var{string-chars} @var{string-char} + | @var{empty} + +@var{string-char} ::= a @samp{\} followed by any character + | any character other than @samp{"}, @samp{\} or newline + +@var{empty} ::= +@end format + + +@node Networked configuration, , The configuration file, Administering Become +@section Networked configuration + +If you're planning to use Become in a standalone way, you can skip this +section. + +@menu +* Choosing servers:: Which servers Become tries to talk to +* Setting up keys:: How to generate keys for Become +* Random number files:: Become keeps random number state around +* Issuing a new key:: How to issue new keys without disruption +@end menu + + +@node Choosing servers, Setting up keys, Networked configuration, Networked configuration +@subsection Choosing servers + +Become notices that it's meant to send requests to a server if it finds a +@file{become.server} file. This file contains entries of the form + +@example +@var{host} [: @var{port}] +@end example + +If the @var{port} is omitted, Become chooses a port by looking at the +services database for a service which matches the name by which Become was +invoked: normally this will be @samp{become}. + +Become sends a request to all of the servers and believes the first valid +reply it receives. Since servers ignore requests they believe to be invalid, +this enables you to change Become's key without disrupting service +(@pxref{Issuing a new key}). + +If you're using NIS, you should try to ensure that Become servers runs only +on NIS servers; the NIS master is probably a good choice. + +Become isn't particularly processor-intensive, and doesn't seem to require +very much memory. + + +@node Setting up keys, Random number files, Choosing servers, Networked configuration +@subsection Setting up keys + +Communication between Become clients and the server is encrypted to ensure +that it's not feasible to gain unauthorised privilege by subverting the +network. Become uses simple symmetric cryptography -- it's not necessary to +use complicated public key techniques in this case. + +Each client machine, and the server, must have a copy of the same key. The +key is usually stored in @file{/etc/become/become.key}. Become's keys are +128 bits long. + +The key file can be generated using the @code{keygen} program, supplied. The +command + +@example +keygen --bits=128 --output=/etc/become/become.key +@end example + +@noindent +generates a 128-bit key and writes it to @file{/etc/become/become.key} in a +format which Become can read. + +The @code{keygen} program works by measuring the time between keystrokes. It +also tries to obtain some randomness from the environment, and mixes all of +this noise together before it outputs the key file. + +Having generated a key, it must be distributed to all of the other hosts +which will use this server. The author recommends using the @code{scp} +program, distributed with the @code{SSH} (Secure Shell) package, for doing +this. + +Being able to read a key file enables a user to assume root privileges. The +author recommends that only the super-user be able to read key files. + +@menu +* Invoking keygen:: How to use the @code{keygen} program +@end menu + + +@node Invoking keygen, , Setting up keys, Setting up keys +@subsubsection Invoking @code{keygen} + +@example +keygen [@var{option}@dots{}] +@end example + +By default, @code{keygen} generates a 128-bit key, and writes it to standard +output in a hexadecimal format. This behaviour can be modified by passing +options: + +@table @code +@item -h +@itemx --help +Write a summary of @code{keygen}'s usage instructions to standard output and +exits. + +@item -b @var{bits} +@itemx --bits=@var{bits} +Generate a @var{bits}-bit key, instead of the default 128 bits. + +@item -o @var{file} +@itemx --output=@var{file} +Write the key to @var{file} instead of standard output. + +@item -f @var{format} +@itemx --format=@var{format} +Set the format in which @code{keygen} outputs the generated key. If the +@var{format} is @samp{hex} (or @samp{tx}), the key is output in Become's +hexadecimal format; @samp{binary} writes the key as a raw binary dump; and +@samp{base64} writes the key using the Base64 encoding. +@end table + + + +@node Random number files, Issuing a new key, Setting up keys, Networked configuration +@subsection Random number files + +Become uses random numbers to generate session keys when it's communicating +with a server. When it's finished, it stores the state of its random number +generator in a file, usually @code{/etc/become/become.random}. If this file +doesn't exist, Become creates it automatically, using noise collected from +the environment. It's probably not worth your while creating randomness +files by hand. + + +@node Issuing a new key, , Random number files, Networked configuration +@subsection Issuing a new key + +When you're sending out a new key, you run a risk of disrupting service. The +server reads a new key; the clients still have the old one. + +The author's recommendation is to run two servers. Update the key on one. +Then send the new key to all of the clients. Finally, update the key on the +other server. Because of the way Become works, a client will always get a +response from one of the servers, depending on whether the new key has +reached it yet. + +A similar method is handy if Become's protocol ever changes. (This is quite +likely at the moment. The current protocol doesn't include any version +information, and the MAC isn't as good as it could be.) + + +@c -------------------------------------------------------------------------- +@node Invoking Become, , Administering Become, Top +@chapter Invoking Become + + +This chapter provides an exhaustive description of Become's command line +options, organised in a reference-manual sort of way. + +@menu +* Becoming another user:: Options for becoming another user +* Starting Become daemons:: Options for starting Become daemons +* Debugging options:: Options to use when Become goes wrong +@end menu + + + +@node Becoming another user, Starting Become daemons, Invoking Become, Invoking Become +@section Becoming another user + +@subsection Synopsis + +@example +become [@var{option}@dots{}] [@var{env-var}@dots{}] @var{user} [@var{command} [@var{argument}@dots{}]] +@end example + +Actually, you can put the @var{option}s, @var{env-var}s and @var{user} in any +order you like; the important thing is that all of them appear before the +command, if any. + + +@subsection Usage + +The @var{option}s appropriate for this mode are as follows: + +@table @code +@item -h +@itemx --help +Display a (fairly verbose) help message describing the various command line +options and exits successfully. + +@item -u +@itemx --usage +Display a terse summary of the command line options and exits successfully. + +@item -v +@itemx +Display's Become's version number and exits successfully. + +@item -e +@item --preserve-environment +Selects the `preserve' login style (@pxref{The preserve style}). All +environment variables are preserved. The default command is the current +user's own shell. The default primary group becomes the current primary +group; the default group style is set to `merge'. + +@item -s +@itemx --su +@itemx --set-user +Selects the `set-user' login style (@pxref{The set-user style}). Most +environment variables are preserved, but @code{USER}, @code{LOGNAME}, +@code{HOME} and other user-specific variables are altered to reflect the +target user's configuration. The default command is the target user's shell. +The default primary group becomes the target user's primary group; the +default group style is set to `merge'. + +@item -l +@itemx --login +Selects the `login' login style (@pxref{The login style}). The environment +is cleared and rebuilt, in a similar way to the behaviour of @code{login}. +The default command is the target user's shell. The default primary group +becomes the target user's primary group; the default group style is set to +`replace'. + +@item -g @var{group} +@itemx --group=@var{group} +Selects @var{group} as the primary group; it may be either a group name or a +numeric group id. Note that @var{group} must be the primary group or +a subsidiary group of either the current user or the target user. + +@item -k +@itemx --keep-groups +Selects the `keep' group style (@pxref{Subsidiary groups}). The current set +of subsidiary group memberships are passed on unchanged. + +@item -m +@itemx --merge-groups +Selects the `merge' group style (@pxref{Subsidiary groups}). The current set +of subsidiary group memberships are merged with the subsidiary groups of the +target user. + +@item -r +@itemx --replace-groups +Selects the `replace' group style (@pxref{Subsidiary groups}). The target +user's subsidiary group memberships are passed on; the current subsidiary +groups are discarded. + +@item -c @var{shell-cmd} +@itemx --command=@var{shell-cmd} +Sets the @var{command} and @var{argument}s to invoke +@code{/bin/sh -c @var{shell-cmd}}; i.e., to execute a Bourne shell command +instead of just @code{exec}ing a program. Note that permissions are checked +for executing the Bourne shell @code{/bin/sh}; the contents of the +@var{shell-cmd} are not inspected. +@end table + +The @var{env-var} arguments fine-tune the environment passed to the command. +Each @var{env-var} setting must be one of the following: + +@table @code +@item @var{var}=@var{value} +Assign the variable named @var{var} the value @var{value}. Protect the +variable @var{var} from modifications by the login style. + +@item @var{var}! +Protect the variable @var{var} from modifications by the login style, but +don't change its value. + +@item @var{var}- +Remove the variable @var{var} from the environment; do not pass it on. +@end table + +The @var{user} specifies the user as whom the @var{command} should be +executed (i.e., the @dfn{target user}). It may be a user name or a numeric +user id. + +The @var{command} specifies a command to execute. If @var{command} does not +contain a path, it is looked for using the current @code{PATH} environment +variable. The resulting pathname is canonified if necessary, to produce an +absolute pathname. Note that symbolic links are @emph{not} resolved -- this +prevents an attack whereby a user could invoke a program, passing it an +unusual @code{argv[0]} which might cause unusual behaviour. + +The @var{command} name is used both as the command to execute and passed to +the command as @code{argv[0]}. It is not possible to specify an alternative +calue to be passed as @code{argv[0]}. Subsequent arguments, if supplied, are +passed as @code{argv[1]} upwards. + +If no @var{command} is given, a shell is invoked; the particulars of the +shell are determined by the login style (see above). + +The @var{command} is executed as follows: + +@itemize @bullet +@item +The subsidiary groups are chosen as determined by the group style. +@item +The real and effective gids are set. +@item +The real and effective uids are set. +@item +The @var{command} is called using the standard @code{execve} system call. +@end itemize + + + +@node Starting Become daemons, Debugging options, Becoming another user, Invoking Become +@section Starting Become daemons + +@subsection Synopsis + +@example +become --daemon [@var{option}@dots{}] +@end example + + +@subsection Usage + +The following options are appropriate to this mode: + +@table @code +@item -h +@itemx --help +Display a (fairly verbose) help message describing the various command line +options and exits successfully. + +@item -u +@itemx --usage +Display a terse summary of the command line options and exits successfully. + +@item -v +@itemx +Display's Become's version number and exits successfully. + +@item -d +@itemx --daemon +Start a Become server, instead of processing a request. Become will read its +command line options, read in the configuration file (and verify that it's +correct) and then fork into the background to wait for incoming requests. +Become relinquishes all setuid privileges (by setting all uids to the real +uid) when it enters daemon mode. It is therefore only really useful to run a +daemon as the superuser. + +@item -p @var{port} +@itemx --port=@var{port} +Listen for requests on @var{port}. This option is overridden by the +@code{port} option in the configuration file. + +@item -f @var{file} +@itemx --config-file=@var{file} +Read configuration from @var{file}, instead of the default (usually +@file{/etc/become/become.conf}). +@end table + +The syntax of the configuration file is described in @ref{The configuration +file}. + + +@node Debugging options, , Starting Become daemons, Invoking Become +@section Debugging options + +Some options are only useful when trying to find out why Become is +misbehaving. Of course, this never happens, so here are the options which +you won't need to use: + +@table @code +@item -T[@var{file}] +@itemx --trace[=@var{file}] +Write trace information to @var{file} (or to standard output, if no +@var{file} is specified). You must be able to create the file and open it +for writing. + +@item -L[@var{feature}...] +@itemx --trace-level[=@var{feature}] +Selects which features Become ought to trace. Each feature is allocated a +letter; simply string together the letters for the features you want to +debug. The letters @samp{D} and @samp{A} stand respectively for `default' +and `all' features; you can subtract from them by saying, for example, +@samp{A-xyz} to select all features except @samp{x}, @samp{y} and @samp{z}. +The exact list of features supported at any one time can be listed by giving +the @code{--trace-level} option without an argument. + +@item -I @var{user} +@itemx --impersonate=@var{user} +Pretend to be @var{user} instead of yourself when the request is checked. +This option can only be used if it wasn't disabled at compile-time and if +Become is not running setuid. Even so, Become will only inform you of the +outcome; it will not execute any commands. +@end table + + + +@c -------------------------------------------------------------------------- + +@c --- No index yet --- +@c +@c @node Concept index, , Invoking Become, Top +@c @unnumbered Concept index +@c @printindex cp +@c +@c @contents + +@bye + +@c ----- That's all, folks -------------------------------------------------- -- 2.11.0