README

Now that sudo has the ability to log input and output, I see no reason to
continue development of rootsh.

Here are the lines that I've added to my sudoers file:

    Defaults iolog_dir=/var/log/sudo-io

    # Members of the admin group may gain root privileges
    %admin ALL=(ALL) LOG_OUTPUT:LOG_INPUT: ALL
    # prevent recursive logging
    %admin ALL=(ALL) NOLOG_OUTPUT:NOLOG_INPUT: /usr/bin/sudoreplay

This nicely logs everything that rootsh was logging and doesn't log when
I'm replaying log files. The sudoreplay tool can be used to list the
sessions that were logged and play them back.

I use the following crontab entry to clean up the old sudo log files:
    0 0 1 * * find /var/log/sudo-io -mtime +90 -print | xargs -r rm -v 
    0 0 2 * * find /var/log/sudo-io -type d -empty -delete



Introduction:
=============

rootsh is a wrapper for a shell which will make a copy of everything printed
on your terminal. Its main purpose is to give ordinary users a shell with
root privileges while keeping an eye on what they type. This is accomplished
by allowing them to execute rootsh via the sudo command. Unlike a simple
"sudo -s" which is the usual way doing this, "sudo rootsh" will send their
terminal keystrokes and output to a logfile and eventually to a remote 
syslog server, where they are out of reach and safe from manipulation.


Motivation:
===========

Sometimes users need to perform tasks on a system which are too complex
to be expressed in sudo rules. Sometimes there is management pressure
to give a user a root shell. Sometimes you're just tired arguing with
users who insist in having root privileges.
With rootsh you can give your users access to a root shell while auditing
their actions. 


Usage:
======

rootsh will be mainly used to give normal users the privilege of a
shell running under uid 0. This will mostly be accomplished by calling
it via the sudo command. 
If, for example you have to grant user usr1234 local root privileges
on his workstation ws0001, you make an entry in your /etc/sudoers like this:

usr1234		ws0001		= /bin/rootsh

He will then have to type the following to become root:

usr1234@ws0001:~> sudo rootsh
Password:
ws0001:~ # id
uid=0(root) gid=0(root) groups=0(root)
ws0001:~ # 
ws0001:~ # exit
exit
usr1234@ws0001:~>


If you compiled rootsh with the default settings, the keystrokes and output
will be sent line by line to the syslog daemon using priority local5.info
To collect the output coming from running rootsh commands in a specific file
make an entry in your /etc/syslog.conf like this:

local5.notice	/var/log/rootshell

or maybe like this:

local5.notice	@your_central_syslog_host

Wherever you send your syslog data to, the resulting output will be
like this:

Jul  2 17:44:19 ws0001 rootsh-020a: usr1234=root,/dev/pts/0: logging new rootsh session (rootsh-020a) to /var/log/rootsh/usr1234.20040702174419.020a
Jul  2 17:44:21 ws0001 rootsh-020a: 001: ws0001:~ # id 
Jul  2 17:44:21 ws0001 rootsh-020a: 002: uid=0(root) gid=0(root) groups=0(root)
Jul  2 17:44:22 ws0001 rootsh-020a: 003: ws0001:~ #  
Jul  2 17:46:03 ws0001 rootsh-020a: 004: ws0001:~ # exit 
Jul  2 17:46:03 ws0001 rootsh-020a: 005: exit 
Jul  2 17:46:03 ws0001 rootsh-020a: 006: *** rootsh session ended by user
Jul  2 17:46:03 ws0001 rootsh-020a: usr1234,/dev/pts/0: closing rootsh session (rootsh-020a) 

where the rootsh-020a is an identifier created from the program's name and
a 4 digit hex number which is the pid of the rootsh process. It will
prepend every line sent to syslog and will help you to find all the entries
in a logfile belonging to a specific session.

To find the log information for a session in syslog, first find the
"logging new..." line for the session you're interested in, take the
identifier like rootsh-020a in the example and grep all occurences of it
from your logfile. If rootsh is running on many machines, there may be
collisions if two rootsh processes have the same pid. Add the hostname to
grep's pattern in this case.  You will also find the same output locally on
the ws0001 host in a file called like this <caller's
username>.<timestamp>.<process id> Depending on your operating system and
configuration parameter --with-logdir= these files can be found in
/var/log/rootsh, /var/adm/rootsh or your own choice.  The counter after the
session identifier can help you find holes if you are not sure weather
logging was incomplete (either due to manipulation or network problems).
Finished session's logfiles get ".closed" appended to their names. This
helps you cleaning and archiving your logdir.  If the main process thinks,
the logfile was manipulated during the session, it tries to recreate the
file and ".tampered" instead of ".closed" is attached.

There is a parameter "-i", which tells rootsh to run the shell as a login
shell.

You can use the parameter -u if you want to run the shell as another
non-root user. When this option is used the logfile will show
"usr1234=root" at the start of the logging. Without using this option the
line will show "root=root" as no other user information is available.



How it works:
=============

rootsh works very much like the script utility. It forks and creates
a master/slave pseudo terminal pair. The slave pseudo terminal will
become the controlling terminal of the child process which will
execute a shell command. The parent process waits for input from the
user's terminal and sends it down the master pty. Every output including
the echoed input will be written to a logfile and to the syslog daemon.


Warning:
========
There may be methods to escape the auditing. The abuser might then delete
his traces or manipulate the logfiles.
With (per default) activated syslog logging you have at least a chance
to seek out suspicious traces of misbehaviour.
You can also use chattr on the log directory to try and thwart the abuser.