121 lines
4.8 KiB
Plaintext
121 lines
4.8 KiB
Plaintext
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.
|
|
(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 wether 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.
|
|
|
|
Better look at the manpage at http://people.consol.de/~lausser/rootsh/rootsh.html
|
|
|
|
|
|
|
|
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 oder manipulate the logfiles.
|
|
With (per default) activated syslog logging you have at least a chance
|
|
to seek out suspicious traces of misbehaviour.
|
|
|
|
|
|
MAINTAINER:
|
|
luanjianhai@huawei.com
|
|
|