$Id: README,v 1.8 2004/11/15 00:26:30 hbo Exp $

Sudoscript 2.1.2

See INSTALL for installation instructions
See CHANGELOG for changes
See SUDOCONFIG for examples of how to configure sudo
See Security for notes on security implications of sudoscript

Sudoscriptd/sudoshell are a pair of Perl scripts that provide an
audited shell using sudo. If you are familiar with sudo, you might
well ask "doesn't running a shell under sudo defeat the purpose of the
tool?" Yes and no. One reason for running sudo is to limit what
commands can be run by users. These scripts do indeed defeat that
purpose. Another reason to run sudo is to maintain an audit trail of
commands issued by users with root privilege or otherwise. These
scripts preserve that audit trail by logging all terminal output to
log files.

In its default mode, sudoscript enables an audited root shell.  Though
giving a user an unrestricted root shell allows them to evade auditing
innocently (by running an xterm for example) or maliciously (by
changing the root password to give just one of way too many examples),
you may have no choice but to give your users such a shell.  This may
be because they truly need the flexibility of a root shell, or just
because they think they do and can convince their managers to let them
have it. Either way, you are stuck with losing your audit trail or
using something like this tool.

In another mode, sudoscript allows an audited shell as some user other
than root.  Though the implications for system security are less
severe than with a root shell, there are still ways for user to evade
sudoscript's audit trail, even when not running as root. See the
SECURITY document in the distribution for details.

Sudoshell (also ss) is a small Perl script that works in conjunction
with a logging daemon, sudoscriptd, to log all activity within a 
shell. It uses the Unix script(1) command to create the log. Once
invoked, all console commands and output are logged to a FIFO. The
logging daemon reads from this FIFO and manages log files to store the
data produced. The logs are rotated to ensure that they do not
overflow the disk space on the logging partition. The daemon is split
into three parts that allow tagging of each session's data with a
session ID. This means that different usrs' sessions can be
separated in the log file using grep.

Sudoshell checks to see if the daemon is running and offers to start
it if it is not.  (It does this with sudo, so you need to have sudo
access as root to perform this step.) Sudoshell then checks to see if
it has been run with root privilege, via 'sudo sudoshell' or
otherwise, or if it has been called with a -u parameter. If not, it
reinvokes itself using sudo. The script then checks the user's SHELL
environment variable. If the value of this variable doesn't match one
of the shells listed in /etc/shells, sudoshell refuses to run. Next
the logging FIFO is checked.  If it exists, sudoshell runs the script
command using the FIFO as the typescript. If it doesn't exist,
sudoshell exits

SUDO AND SHELLS

Most root tasks can be accomplished with sudo without running a shell. 
However certain tasks, such as running privileged commands in a pipeline, 
can be more difficult using sudo. Since sudo sometimes prompts for a 
password (depending on how long ago the user last authenticated) you can 
run into quirky situations like this:

  hbo@egbok|509> sudo ls | sudo more
  Password:Password:(enter password)
  (enter password)
  #sudoshell#
  CVS
  sudoscriptd
  sudoscriptd~
  sudoshell
  sudoshell~
  hbo@egbok|510>

In this case we get two password prompts, right on top of one another. We enter
the password for the first prompt, and sudo waits for the next one. Since
the prompt is on the preceding line, this can be very confusing.

Another place sudo has difficulty is with I/O redirection:

  hbo@egbok|511 > ls -l /tmp/foo
  -r--r--r--   1 root     other       1464 Mar 25 13:10 /tmp/foo
  hbo@egbok|512 > sudo ls >>/tmp/foo
  bash: /tmp/foo: Permission denied
  hbo@egbok|513 > sudo ls | sudo cat >>/tmp/foo
  bash: /tmp/foo: Permission denied

But this works:

  hbo@egbok|514 > sudo ls | sudo tee -a /tmp/foo >/dev/null

It's not very intuitive, however.

The problem occurs because the shell implements I/O redirection
before it invokes the command, which is sudo, NOT ls.

Globbing has problems for the same reason. But in this case, there's 
no good workaround, short of letting the user run a shell:

  hbo@egbok|515 > mkdir fff
  hbo@egbok|516 > chmod 700 fff
  hbo@egbok|517 > touch fff/foo
  hbo@egbok|518 > sudo chown root fff
  Password:
  hbo@egbok|519 > cd fff
  bash: cd: fff: Permission denied
  hbo@egbok|520 > sudo cd fff 
  sudo: cd: command not found
  hbo@egbok|521 > sudo rm fff/*
  rm: cannot remove `fff/*': No such file or directory

The cd fails because cd is a bash built-in, and sudo doesn't know anything
about it. The "globbing" fails because the shell tries to expand the 
wildcard before executing the command, which is sudo, not rm.

A paper describing these difficulties and lots more is included in the 
distribution. On RPM based systems, it will show up in 
/usr/share/doc/${DIST}/ along with this file. The latest version
is on the web at http://www.egbok.com/sudoscript/PORCMOLSULB.html.

The latest version of the distribution is at http://www.egbok.com/sudoscript.
You may contact the author, Howard Owen, at hbo@egbok.com

