The Linux Bootkit
Configuration and Basic Operation
B. Scott Burkett, scottb@intnet.net

INTRODUCTION
------------

There are two major steps needed to configure the Linux Bootkit for your
system.  The first involves some simple configuration within the menu
system itself.  The second simply involves determining which files need to
be installed on your emergency diskettes.

NOTE:  Chances are that the Linux Bootkit will not work "right out of the
box" for you.  The configuration and layout of the host on which it was
developed follows a close pattern to that of the Slackware distribution. 
Be sure to thoroughly configure the Bootkit before trying to use it.  You
won't munge anything up, but chances are it won't create useful boot disks
unless it knows where to find the goods.

INTERNAL CONFIGURATION
----------------------

Fire up the Linux Bootkit by simply running the "bootkit" program.  Within
a second or two, you should see the the main menu magically appear before 
you.  If not, chances are you aren't running version .05 or better of the
"dialog" package.  Just in case, I have provided a copy of the binary 
(a.out format) in the "./contrib" subdirectory within the distribution 
archive.  Simply copy this file (or move it) to /bin.

Once the menu appears, select the "CONFIG" option.  Another menu will appear,
containing the following options:

	 PATHS: Configure some important paths and filenames
	TOGGLE: Various bootkit toggle options
	RETURN: Return to the main menu

The following options are available under PATHS:

  FLOPPY DISK DEVICE   
  ------------------

  This option will allow you to select the device which corresponds to your
  configured floppy device.  The default is /dev/fd0.

  PATH AND FILENAME OF KERNEL
  ---------------------------


  Which kernel image do you want to boot from in an emergency?  Most folks
  will simply choose "/vmlinuz", or whatever your production kernel revision
  happens to be.  However, later you may want to create a smaller kernel,
  free of the bloat which typically accompanies TCP/IP, sound drivers, etc.
  Let's face it - if disaster strikes, my first impulse is NOT to fire up
  my CD-ROM for a rousing session of John Lennon live at the vet. :-)  
  Simply enter the full path and filename of the kernel image to boot from.  

  One more thing.  Be sure you specify a compressed kernel.  While using an
  uncompressed will (should) work, the growing size of the kernel (with
  drivers compiled in) is getting to an almost unmanagable point.

  PATH TO FLOPPY MOUNT POINT
  -------------------------- 

  This is simply the path to which the floppies should be mounted whenever  
  the Linux Bootkit needs to do some work on it.  Most folks will use a 
  path of "/mnt" or "/dos", but a "./mnt" subdirectory has been provided
  in the distribution archive, and will be the default upon your initial
  arrival to this screen.  Unless you have some scripts which use another
  path, and you want to keep things consistent, it is safe to leave this
  option alone.

  PATH/FILENAME OF LIBC LINK
  --------------------------

  This one can be a bit tricky for novice users.  Simply put, this is the
  full path and filename of the link which should point to your standard
  runtime library.  By default, it assumes a value of "/lib/libc.so.4".
  To verify this, do an "ls -l /lib/libc.so.*".  You should see at least
  two files on the listing.  One should be a link to the other.

       /lib/libc.so.4 -> libc.so.4.6.27
       /lib/libc.so.4.6.27

  The Linux Bootkit takes the "link", not the file it points to.  It will
  install both, but only requries the "link" in order to perform its job.
  Hence, in the above example, simply specify "/lib/libc.so.4", and the 
  Linux Bootkit will do the rest.

The following options are available under TOGGLE:

  RAMDISK (Use kernel RAMDISK feature?)
  -------------------------------------

  This option will enable the RAMDISK feature in the bootable kernel.  If
  you will be using a "utility" disk, in addition to the standard boot and 
  root disks, this option is required.  This is what forces the bootable 
  kernel to load your floppy-based root filesystem into RAM, allowing you 
  to use the utility diskette.
  
  COPYLIBC (Copy the runtime library to the root diskette)
  --------------------------------------------------------

  This option will force the Linux Bootkit to copy your runtime version of
  the standard library to any root diskettes you create.  Unless you know
  what you are doing, leave this puppy alone.  You need the runtime library
  to boot anyway!  If you are simply creating root filesystems for mounting
  on the side, you can disable it.  It will save you tons of bloat in that
  case.

  ADDBKUSER (Add default bootkit user)
  ------------------------------------

  This option will force the Linux Bootkit to create a new user in the
  passwd file on your root diskette.  This new user (called "bootkit")
  has a home directory of "/", no password, and uses "/bin/sh" as a
  login shell.  This is used as a secondary method of gaining access
  during an emergency.  See the next section for more details on this.
  The default is to create the "bootkit" user.  

Additional options will be added as the package grows, but this seems to be
a formidable start to things.

The options are saved into a file called "./.bootkit.config".  These options
are read in whenever bootkit starts again.  The Linux Bootkit will create
this file for you the first time you run it.  To revert back to the 
defaults, you can delete this file.  It will be recreated for you the next
time you run bootkit.

EXTERNAL CONFIGURATION AND BASIC OPERATION
------------------------------------------

Unfortunately, the Linux Bootkit doesn't provide all the configuration via
the menus.  At least at the moment.  I will add this functionality if the
package is accepted and proven to be useful to someone other than myself.

If you examine the directory tree which is preserved in the distribution
archive, it should appear somewhat reminiscent of the following diagram:



               |-contrib
               |-help
               |-mnt
|-bootkit-x-xx-|    
               |-root_conf
               |-root_skel
               |-util_conf
               |-util_skel

Here is walkthrough of what we have:

  ./contrib is used to store any contributed or non-bootkit programs.
  ./help contains all the ASCII based help files
  ./mnt is the default floppy mount point

Those were the simple ones.  Now, lets take a look at the remaining    
entries. 

  ./root_conf holds the configuration files for creating the root diskette
  ./root_skel can contain additional files or links to be installed on the
              root diskette
  ./util_conf holds the configuration files for creating the utility
              diskette
  ./util_skel can contain additional files or links to be installed on the
              utility diskette

Sounds harrowing?  Nah.  Let's take a look at how the Linux Bootkit creates
root and utility diskettes.  Its not so bad.  

When bootkit creates a root diskette, the very first thing it attempts to
do is create a new filesystem on the floppy.  Assuming that went without
a hitch, it attempts to mount the floppy on the directory you specified as
the temporary floppy mount point back during the internal configuration.

Once the floppy has been mounted, bootkit then examines the contents of
two directories, "./root/conf" and "./root_skel".

  ./root_conf (The configuration directory)
  -----------------------------------------

  Under this directory are a number of files:

     files.bin
     files.dev
     files.etc
     files.sbin
     dirs.extra
     termcap.console

  There may be others eventually, but these are the ones provided with the
  package.  Let's take a look at the ones which are prefixed with "file." 
  first.

  If you examine any of the files which are prefixed with "files.", you 
  will notice that they contain nothing more than a list of absolute paths 
  to various programs on your system.  Consider this listing of files which
  might be contained in /bin on your hard disk:

     /bin/cat
     /bin/chown
     /bin/chmod
     /bin/cp
     /bin/cut
     /bin/dd
     /bin/df
     /bin/hostname
     /bin/ln
     /bin/login
     /bin/ls
     /bin/mkdir
     /bin/more
     /bin/mv
     /bin/ps
     /bin/rm
     /bin/sh
     /bin/bash
     /bin/su
     /bin/sync
     /bin/mount
     /bin/umount

  These programs represent some of the files that you might need in the
  event of an emergency.  The Linux Bootkit will install each of these
  files onto any newly created root diskettes.  In fact, it goes through
  all files in "./root_conf" which are prefixed with "files." and installs
  all the files which are specified in them.  Note that the extension of
  the files is irrelevant.  I just called them "files.bin", "files.sbin",   
  etc, strictly as a reminder of what I placed in them.  You could place
  all the necessary files into a single file if you desired.  You could
  give it a name of "files.all" or something.  Also note that wildcards
  may be used if you need them, although I would try and stay away from 
  them as much as possible.  The last thing you need are extra files taking
  up space on your emergency boot disks.

  NOTE:  If any of the specified file names are links, they are preserved.
         See the upcoming blurb on the "./root_skel" directory for more
         information on why I chose this method, and how you can work     
         around it.

  After these files have been installed onto your root diskette, the Linux
  Bootkit then procedes to examine the "dirs.extra" file.  This filename is
  important, and should not be changed (although it can be removed if you
  don't need it).  The "dirs.extra" file should contain a list of absolute
  paths which you need created on your root diskette.  Consider this sample
  "dirs.extra":

     /usr
     /proc
     /tmp
     /mnt
     /root
     /home
     /home/scottb
     /var
     /var/adm
     /var/logs
     /var/run

  This is a list of directories that I want the Linux Bootkit to create for
  me on my root diskette.  Note that they will be empty, but at least they
  will exist.  Some of these entries, such as "/tmp" and "/proc" should
  exist anyway, as the system makes use of them.  

  You will notice that "/home/scottb" is one of the entries, as is "/root".
  Be sure you create the appropriate login directories, lest you not be
  able to log into your system during an emergency!

  Also note the fact that I specified "/home" before "/home/scottb".  This
  is required, due to the way that the Linux Bootkit creates directories.
  Not a big deal.
 
  Once the initial files have been installed, and any extra directories
  have been created, the Linux Bootkit then attempts to install a custom
  "/etc/termcap" file.  Actually, what it does is goes through the 
  "./root_conf" directory, looking for all files which are prefixed with
  "termcap.".  These files are then concatenated to create a custom 
  termcap database, and is installed as "/etc/termcap" on your emergency
  root diskette.  The reason for this is simple.  The stock "/etc/termcap"
  file which ships with Linux is almost 200K in size.  This is WAY too 
  big for an emergency boot, especially since most folks only use a handful
  of the termcap entries anyway.  If you are performing emergency services,
  chances are, you only need the termcap entry for the console.  A file
  called "termcap.console" has been provided with the Linux Bootkit
  distribution.  This file simply contains the termcap entry for the
  console, and should suffice for the majority of users.

  NOTE:  If you have made any changes to your own /etc/termcap file's entry
  for "console", you should be sure to replace the default one provided
  in "./root_conf/termcap.console"!
 
  After the termcap situation is dealt with accordingly, the Linux Bootkit
  procedes to examine the "./root_conf/devices" file.  This file should
  contain a list of device files that you need installed on your root
  diskette.  Most of the ones you should/would need have been provided in
  the sample file.  Be sure to make sure all the devices you need are 
  specified in this file!  This is of utmost importance.  If you need to
  reload Linux from a CD-ROM distribution, it will be an exercise in
  futility if your CD device files aren't there. :-)

  Once the devices have been installed, the Linux Bootkit will then attempt
  to install the runtime version of the standard library (libc) onto the
  root diskette.  It uses the link that you specified during the internal
  configuration.  Both the link and the file it points to are installed
  for you.

  That concludes the walkthrough of the "./root_conf" directory.  Pretty
  drawn out, but simple enough.



  ./root_skel (the skeleton directory)
  ------------------------------------

  The final stop for the root disk creation phase is the "./root_skel"
  directory.  Recall earlier when we discussed the fact that any links
  specified in the "files.*" entries in "./root_conf" were preserved.  
  This approach makes a lot of sense when you consider that a number of
  utilities on the system are actually links to real programs (gzip and
  gunzip, for example).  These links should be preserved, and you should
  always include both the link and the file it points to in those entries.

  However, a secondary method of installing files exists.  The files which
  exist under "./root_skel" are also installed onto the root disk.  This
  time, however, links are resolved instead of preserved.  In addition,
  the "./root_skel" directory may contain subdirectories (in fact, it
  should, since the files contained within it are installed relative to
  "/" your new floppy-based root filesystem).  Consider the following
  directory tree of the sample "./root_skel" directory which has been
  preserved in the distribution archive:

                        |-inittab  
                        |
                 |-etc--|          |-rc.0  
                 |      |-rc.d-----|-rc.K  
                 |                 |-rc.M  
     |-root_skel-|                 |-rc.S  
                 |
                 |-root-|-.profile 
                 |      
                 |                 |-chsh  
                 |-usr--|-bin------|-clear 
                 |                 |-vi    
                 |      
                 |-var--|-adm------|-utmp  
                                   |-wtmp  


  Let's break this one down a bit.  All these files and directories are
  created on the root diskette.  If you hop over on another virtual
  console and look at the files closely, you will see that some of them
  are links (chsh, clear, vi), and the others physically exist under the
  "./root_skel" tree (rc.0, rc.K, utmp, wtmp, etc).

  Any files which are links are resolved, and the files that they point
  "to" are installed, rather than the links.  This provides a handy
  mechanism for simply creating links under "./root_skel" to actual
  programs or files that exist under your normal root filesystem (on your
  hard disk).  This is great because you don't need to physically copy
  them into "./root_skel", just make links to them.

  The other advantage is inherent.  Notice that a number of system files
  have been physically located under "./root_skel".  These files include
  "/etc/inittab", "/etc/rc.d/*", and even a ".profile" in "/root".  When
  you are performing an emergency reboot, you probably don't want the 
  same "/etc/inittab" and "/etc/rc.d/*" files that you would normally use.
  This gives you a chance to create some custom ones just for use during
  any emergency services you perform.  The samples that have been enclosed
  in the archive should suffice for most folks, but be sure to take a look
  at them anyway.

  NOTE:  Be sure to look at your "inittab" and "rc.d" files carefully!
         Make sure that all of the files necessary for booting (getty, etc)
         are being handled by bootkit.


Once the "./root_conf" and "./root_skel" directories have been processed,
one final issue must be dealt with.  If you enabled the "ADDBKUSER" option
during internal configuration, the default "bootkit" user will be
created.  The reason for this is twofold.

First, if you inadvertently forget to have an /etc/passwd file installed,
this option will create one for you, with the "bootkit" user in it.  What
good is an emergency boot system if you can't log in when it runs? :-)

Secondly, if you forget to install the login shell that your superuser
account normally uses, then you won't be able to log in as "root".  The
"bootkit" user is set up to use the "/bin/sh" shell, which you should 
have installed for general purpose.  This is particularly handy if your
superuser account uses "bin/ksh", "/bin/csh", etc.

NOTE:  Don't just copy your existing /etc/passwd.  First off, this is *WAY*
       too dangerous, for obvious security reasons.  The /etc/passwd file
       (technically) should never leave your host.  Secondly, if you are
       running shadow passwords, then the shadow file must be installed as
       well.  Your best bet is to create a custom "passwd" (and possibly
       "shadow") file in ./root_skel.  This way, only the custom ones get
       installed.  I have enclosed a custom "passwd" file in ./root_skel/etc
       which has the root account, with no initial password.  Use your
       best judgement on how to handle the password situation.


  ./util_conf and ./util_skel
  ---------------------------

  When creating a utility disk, the same rules regarding these two
  directories for "./root_skel" and "./root_conf" apply.  The only
  difference is that utility disks don't use the COPYLIBC or ADDBKUSER
  options, and no "devices" or "termcap" handling is performed.  You
  only need these options when creating a root diskette.


