How to log commands within a "sudo su -"?

Question

If I:

[user@notebook ~] sudo echo 123456uu
123456uu
[user@notebook ~] 

Then I can see that in the logs:

[root@notebook /var/log] grep 123456uu *
auth.log:Jan  9 17:01:51 notebook sudo: user : TTY=pts/3 ; PWD=/home/user ; USER=root ; COMMAND=/bin/echo 123456uu
[root@notebook /var/log] 

but if I:

[user@notebook ~] sudo su -
[root@notebook ~] echo 1234567zz
1234567zz
[root@notebook ~] 

I cannot see it in the logs:

[root@notebook /var/log] grep 1234567zz *
[root@notebook /var/log] echo $?
1
[root@notebook /var/log] 

My question: How can I turn the logging on for the commands within the "sudo su -"?

OS is an Ubuntu 12.04 but the question is in general.

UPDATE#1:

[user@notebook ~] sudo su -
[sudo] password for user: 
[root@notebook ~] echo zizizi
zizizi
[root@notebook ~] cd /var/log
[root@notebook /var/log] grep -iIR 'zizizi' *
[root@notebook /var/log] grep 'COMMAND=/bin/su -' *
auth.log:Jan 10 15:42:42 notebook sudo: user : TTY=pts/1 ; PWD=/home/user ; USER=root ; COMMAND=/bin/su -
[root@notebook /var/log]

Answer 1

Since you are on Ubuntu 12.04, have a look at the I/O logging abilities activated via the log_input and log_output options.

log_input

If set, sudo will run the command in a pseudo tty and log all user input. If the standard input is not connected to the user's tty, due to I/O redirection or because the command is part of a pipeline, that input is also captured and stored in a separate log file.

Input is logged to the directory specified by the iolog_dir option (/var/log/sudo-io by default) using a unique session ID that is included in the normal sudo log line, prefixed with TSID=. The iolog_file option may be used to control the format of the session ID.

Note that user input may contain sensitive information such as passwords (even if they are not echoed to the screen), which will be stored in the log file unencrypted. In most cases, logging the command output via log_output is all that is required.

log_output

If set, sudo will run the command in a pseudo tty and log all output that is sent to the screen, similar to the script(1) command. If the standard output or standard error is not connected to the user's tty, due to I/O redirection or because the command is part of a pipeline, that output is also captured and stored in separate log files.

Output is logged to the directory specified by the iolog_dir option (/var/log/sudo-io by default) using a unique session ID that is included in the normal sudo log line, prefixed with TSID=. The iolog_file option may be used to control the format of the session ID.

Output logs may be viewed with the sudoreplay(8) utility, which can also be used to list or search the available logs.

IMPLEMENTATION: Sudo version at least: 1.7.4p4 needed.

/etc/sudoers modifcation: All you need to do is to add two tags to all required sudoers entries (where "su" specified, either with command or alias). LOG_INPUT and LOG_OUTPUT.

Example:

%admins         ALL=(ALL) NOPASSWD: LOG_INPUT: LOG_OUTPUT: ALL

Add the following default log dir structure to sudoers:

Defaults iolog_dir=/var/log/sudo-io/%{user}

Answer 2

Your grep when doing sudo su - fails because you're not running echo 1234567zz, you're running su -, which launches a shell. The shell is then running your echo.

This is deliberate, and logging every single command run would flood your syslog with useless info (there are usually tons of programs that get run behind the scenes that you don't normally see).

If you change your grep to grep 'COMMAND=/bin/su -' * you'll see it.

---

sudo su - is also a useless use of su. sudo -i does the same thing.

Answer 3

In increasing complexity, here's three ways of logging the commands issued within the "sudo su -":

1. Rely on bash command history
2. Install an execve logging wrapper
3. Use SELinux's auditd

As to which is suitable, it really depends on what you're trying to accomplish with the logging.

1) Bash Command History

You would want to configure the history facitlity to ensure keeping sufficient lines, not overwriting from different sessions, not ignoring commands, and appropriate timestamps. (See HIST* variables in the bash manual). Easily subverted by editing the history file, manipulating environment or running another shell.

2) execve wrapper

Snoopy Logger is one. Add a check in /etc/profile that the logger library is in the process's memory map (/proc/<pid>/maps), and if not, set LD_PRELOAD and restart (with exec $SHELL --login "$@"). Alternately you may add an entry to /etc/ld.so.preload with $LIB/snoopy.so or equivalent path(s) to your 32/64-bit versions of snoopy.so.

Though more difficult, the LD_PRELOAD environment variable version of the above could still be subverted by manipulating execution environment so that the snoopy code no longer runs.

Syslog should be sent off-box for contents to be trustworthy.

3) auditd

Slightly more straightforward to configure than the execve wrapper, but harder to extract the information from. This is the answer the question you're likely really asking: "Is there a way to log what effect the user has had on a system after they issue sudo su -". Syslog should be sent off-box for contents to be trustworthy.

This Serverfault answer appears to be a fairly comprehensive configuration for use with auditd.

There are some other suggestions to a similar question on serverfault.

Answer 4

Why?

Because it's sudo that is doing the logging; it logs sudo commmands. In the first case, sudo echo is logged. In the second case, sudo su is logged (look for it in /var/log/auth.log).

su is "switch user", by default to root. Anything you do after that does not pass through sudo. It is the much the same as if you'd logged in as root; the login itself is logged, but not each and every command.

Answer 5

As others have said, sudo can't do this.

Instead, use auditd. If you want to log everything done by root (including e.g. things done by crontab), use this:

sudo auditctl -a exit,always -F euid=0

ETA: Note that logging everything will impact performance, so you'll probably want to limit it a bit. See man auditctl for examples.

If you only want to log syscalls where the original login uid is not root, use this instead:

sudo auditctl -a exit,always -F euid=0 -F auid!=0

The logs will usually end up in /var/log/audit/audit.log. You can search them with ausearch.

There's more information in the man pages for auditctl, audit.rules and ausearch.

Answer 6

sudo su - will be in ~/.bash_history if your shell is bash.

echo 1234567zz will be in /root/.bash_history if root's shell is bash.

Explanation of this was already posted by goldilocks.

Answer 7

Do you you want su to log because you feel it is a security flaw ? Have you thought about this command ? sudo bash just as bad imho.

If you are worried about what people can do with sudo, then you will need to restrict it's use. You can restrict the commands they can execute too. Restrict access to /bin/su if it worries you.

Answer 8

What about this:

export HISTTIMEFORMAT="%d/%m/%y %T "
export PROMPT_COMMAND='builtin history 1 >> /var/log/sudo.log'
sudo -E su
unset PROMPT_COMMAND

or

export HISTTIMEFORMAT="%d/%m/%y %T "
export PROMPT_COMMAND='builtin history 1 >> /var/log/sudo.log' 
sudo -E su --preserve-environment -
unset PROMPT_COMMAND

or long one-liner:

HISTTIMEFORMAT="%d/%m/%y %T " PROMPT_COMMAND='builtin history 1 >> /var/log/sudo.log' sudo -E su

sudo -E preserves environment PROMPT_COMMAND is executed before each prompt

Answer 9

If this helps, you can use "NOEXEC" option of sudoers.

You need to define it as

USER_NAME         ALL=(ALL) NOEXEC : ALL

This will prevent shell escapes and user won't be able to use sudo -i or sudo -s or sudo su -

This comes with a downside, however, Any shell escape will be disabled. for ex- executing script from within a script will also be denied.

Answer 10

Let's not make this complicated: Whenever sudo is called, it reports this fact in some file in /var/log (on your system is auth.log, on my OS X box it's system.log). sudo reports its commandline arguments, but it has no knowledge of what might happen inside an interactive command like su.

This doesn't mean there's no record of what happens in a root subshell: Shell commands are saved in the shell's history. On my system, root's history saving is enabled by default, so all I'd have to do is look in ~root/.sh_history for a record of what was done (unless someone tampered with it, of course, but they could equally well tamper with /var/log).

I think this is the best solution for you. If not, go to town with auditd, as @Jenny suggested.

PS. If root's history is not already enabled, enabling it depends on which shell it uses. For bash, set HISTORY and HISTFILESIZE to a large enough number (default is 500, my manual says). If you wish you can specify where the history is saved by setting HISTFILE to a path (default $HOME/.sh_history)

Answer 11

You might want to create a typescript of your session using script(1):

$ sudo su -
# script -t /tmp/my_typescript 2> /tmp/my_typescript.timing
Script started, file is /tmp/my_typescript
# echo foobar
foobar
# echo hello world
hello world
# exit
exit
Script done, file is /tmp/my_typescript

Now you can grep (note that the # prompts are actually recorded in /tmp/my_typescript):

$ grep echo /tmp/my_typescript
# echo foobar
# echo hello world

Alternatively, you can even watch the whole session again with scriptreplay(1):

$ scriptreplay -t /tmp/my_typescript.timing /tmp/my_typescript

The file /tmp/my_typescript.timing contains information when each command has been invoked. There are further tools like ttyrec or shelr that have even more bells and whistles.