C Shell Python M4 Other Makefile
Fetching latest commit…
Cannot retrieve the latest commit at this time.
|Failed to load latest commit information.|
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.