NAME

  sudoshell, ss - Run a shell with logging

SYNOPSIS

sudoshell|ss [-] [-u|--user username]

VERSION

This manpage documents version 2.1.2 of sudoshell.

DESCRIPTION

sudoshell runs the script command with a fifo as the typescript. Used in conjunction with sudoscriptd(8) and sudo(8), it provides a way to maintain the sudo audit trail while running a shell.

README

sudo is a tool used for running programs with privileges other than those normally possessed by the user. Often, the privileges are those of the root account, but they could as well be those of any other user. One of sudo's major benefits is the audit trail it provides, as it logs each invocation with the command name, its arguments and the user who ran it. Because this audit trail is lost if a user runs a shell (e.g. bash or csh) with sudo, many sites restrict sudo to not allow such usage. Since this can cause problems, (see "SUDO AND SHELLS") many users prefer to retain the root password, even if it means forgoing support. This outcome also results in a loss of the audit trail, while increasing the chances that an unmanaged system will become a support problem later.

Sudoshell is a small Perl script that works in conjunction with a logging daemon (see sudoscriptd(8)) 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.

When started, sudoshell checks to see if sudoscriptd(8) is running and offers to start it if it is not. (It does this with sudo, so you need to have sudo root access to perform this step. See CONFIGURATION below) Sudoshell then checks to see if it has been run as the correct user (either root or some other user with the -u switch. See below.) via 'sudo sudoshell' or otherwise. If not, it reinvokes itself using sudo. The script then checks the user's shell. If the SHELL environment variable is set, sudoshell uses that. If not, the shell entry from the passwd file is used. If the value thus obtained doesn't match one of the shells listed in /etc/shells, sudoshell refuses to run. Finally, sudoshell execs script(1), pointing the output to a logging FIFO maintained by sudoscriptd(8), which gives the user a shell as the desired user.

CONFIGURATION

sudoshell uses sudo(8) to perform all its authentication and privilege escalation. The sudoshell user must therefore be in the sudoers file (See sudoers(5).) with an entry that allows running sudoshell as the desired user. See the SUDOCONFIG file in the distribution for details. (On Linux, this will be in /usr/share/doc/sudoscript-VERSION. Everywhere else, it's in /usr/local/doc/sudoscript-VERSION.)

SWITCHES

-: Like 'su -'. This switch will load the environment of the user you become, rather than retaining yours.

-u <user>

If this switch is given along with a username, sudoshell will ask sudo to give the ss user the identity of the user named with the -u switch. If no -u switch is given, sudoshell will ask for a root shell.

Example:

sudoshell -u oracle

The idea of running shells as users other than root came from Donny Jekels.

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 builtin, 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.

BUGS

Please let me know if you find any.

PREREQUISITES

sudo - <http://www.courtesan.com/sudo/index.html>

OSNAMES

"Solaris"

"Linux"

"OpenBSD"

"FreeBSD"

"HP-UX"

SCRIPT CATEGORIES

UNIX/System_administration

CONTRIBUTORS

The following people offered helpful advice and/or code:

   Dan Rich       (drich@emplNOoyeeSPAMs.org)
   Alex Griffiths (dag@unifiedNOcomputingSPAM.com)
   Bruce Gray     (bruce.gray@aNOcSPAMm.org)
   Chan Wilson    (cwilson@coNrOp.sSgPi.cAoMm>
   Tommy Smith    (tsNmOith@eSaPtAeMl.net)
   Donny Jekels   (donny@jNOeSkPeAlMs.com

AUTHOR

Howard Owen, <hbo@egbok.com>

COPYRIGHT AND LICENSE

sudoscript is free software; you can redistribute it and/or modify it under the same terms as Perl itself.