¿Cómo registrar comandos dentro de un "sudo su -"?

Si yo:

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

Entonces puedo ver eso en los registros:

[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] 

pero si yo:

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

No puedo verlo en los registros:

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

Mi pregunta: ¿Cómo puedo activar el inicio de sesión para los comandos dentro de "sudo su -"?

El sistema operativo es un Ubuntu 12.04 pero la pregunta es en general.

ACTUALIZACIÓN # 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]

Como está en Ubuntu 12.04, eche un vistazo a las capacidades de registro de E / S activadas a través de las opciones log_inputy log_output.

log_input

Si está configurado, sudoejecutará el comando en un pseudo tty y registrará todas las entradas del usuario. Si la entrada estándar no está conectada al tty del usuario, debido a la redirección de E / S o porque el comando es parte de una tubería, esa entrada también se captura y almacena en un archivo de registro separado.

La entrada se registra en el directorio especificado por la iolog_diropción ( /var/log/sudo-iopor defecto) usando una ID de sesión única que se incluye en la línea de registro de sudo normal, con el prefijo TSID=. La iolog_fileopción puede usarse para controlar el formato de la ID de sesión.

Tenga en cuenta que la entrada del usuario puede contener información confidencial, como contraseñas (incluso si no se repiten en la pantalla), que se almacenará en el archivo de registro sin cifrar. En la mayoría de los casos, todo lo que se requiere es registrar el resultado del comando a través de log_output.

log_output

Si está configurado, sudoejecutará el comando en un pseudo tty y registrará todos los resultados que se envían a la pantalla, de manera similar al comando script (1). Si la salida estándar o el error estándar no está conectado al tty del usuario, debido a la redirección de E / S o porque el comando es parte de una tubería, esa salida también se captura y almacena en archivos de registro separados.

La salida se registra en el directorio especificado por la iolog_diropción ( /var/log/sudo-iode forma predeterminada) utilizando una ID de sesión única que se incluye en la línea de registro de sudo normal, con el prefijo TSID=. La iolog_fileopción puede usarse para controlar el formato de la ID de sesión.

Los registros de salida se pueden ver con la utilidad sudoreplay (8), que también se puede usar para enumerar o buscar los registros disponibles.

IMPLEMENTACIÓN: Sudo versión al menos: 1.7.4p4 necesario.

/etc/sudoersModificación: todo lo que necesita hacer es agregar dos etiquetas a todas las entradas de sudoers requeridas (donde se especifica "su", ya sea con comando o alias). LOG_INPUT y LOG_OUTPUT.

Ejemplo:

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

Agregue la siguiente estructura de directorio de registro predeterminada a sudoers:

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

Tu grepcuando haces sudo su -falla porque no estás corriendo echo 1234567zz, estás corriendo su -, lo que lanza un shell. El shell está ejecutando su echo.

Esto es deliberado, y el registro de cada ejecución de comando inundaría su syslog con información inútil (generalmente hay toneladas de programas que se ejecutan detrás de escena que normalmente no se ven).

Si cambias tu grep a grep 'COMMAND=/bin/su -' *lo verás.

sudo su -También es un uso inútil de su. sudo -ihace lo mismo

Para aumentar la complejidad, aquí hay tres formas de registrar los comandos emitidos dentro del "sudo su -":

1. Confíe en el historial de comandos de bash
2. Instale un contenedor de registro execve
3. Utilice el auditado de SELinux

En cuanto a cuál es adecuado, realmente depende de lo que intente lograr con el registro.

1) Historial de comandos de Bash

Desea configurar la facilidad del historial para garantizar mantener suficientes líneas, no sobrescribir desde diferentes sesiones, no ignorar comandos y marcas de tiempo apropiadas. (Ver HIST * variables en el manual bash ). Se subvierte fácilmente editando el archivo de historial, manipulando el entorno o ejecutando otro shell.

2) envoltorio execve

snoopylogger es uno. Agregue una comprobación de /etc/profileque la biblioteca del registrador se encuentra en el mapa de memoria del proceso ( /proc/<pid>/maps) y, si no, configure LD_PRELOADy reinicie (con exec $SHELL --login "$@"). Alternativamente, puede agregar una entrada a /etc/ld.so.preload con $LIB/snoopy.soo rutas equivalentes a sus versiones de 32/64-bit de snoopy.so.

Aunque es más difícil, la LD_PRELOADversión de variable de entorno de lo anterior aún podría subvertirse manipulando el entorno de ejecución para que el código de snoopy ya no se ejecute.

Syslog debe enviarse fuera de la caja para que los contenidos sean confiables.

3) auditado

Un poco más sencillo de configurar que el contenedor execve, pero más difícil de extraer la información. Esta es la respuesta a la pregunta que probablemente te estés haciendo: "¿Hay alguna forma de registrar qué efecto ha tenido el usuario en un sistema después de emitirlo sudo su -". Syslog debe enviarse fuera de la caja para que los contenidos sean confiables.

Esta respuesta de Serverfault parece ser una configuración bastante completa para usar con auditado.

Hay algunas otras sugerencias para una pregunta similar sobre serverfault .

¿Por qué?

Porque es lo sudoque está haciendo el registro; registra comandos sudo. En el primer caso, sudo echose registra. En el segundo caso, sudo suse registra (búscalo en /var/log/auth.log).

sues "cambiar usuario", por defecto a root. Cualquier cosa que hagas después de eso no pasa sudo. Es lo mismo que si hubiera iniciado sesión como root; el inicio de sesión en sí está registrado, pero no todos y cada uno de los comandos.

Como han dicho otros, sudono puedo hacer esto.

En cambio, use auditd. Si desea registrar todo lo hecho por root (incluyendo, por ejemplo, cosas hechas por crontab), use esto:

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

ETA: tenga en cuenta que registrar todo afectará el rendimiento, por lo que probablemente desee limitarlo un poco. Ver man auditctlpara ejemplos.

Si solo desea registrar syscalls donde el uid de inicio de sesión original no es root, use esto en su lugar:

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

Los registros generalmente terminarán en /var/log/audit/audit.log. Puedes buscarlos con ausearch.

Hay más información en las páginas de manual para auditctl, audit.rulesy ausearch.

sudo su -estará dentro ~/.bash_historysi su shell es bash.

echo 1234567zzestará adentro /root/.bash_historysi el shell de root es bash.

La explicación de esto ya fue publicada por goldilocks.

¿Desea iniciar sesión porque cree que es una falla de seguridad? ¿Has pensado en este comando? sudo bashigual de malo, en mi humilde opinión.

Si le preocupa lo que la gente puede hacer con sudo, deberá restringir su uso. Puede restringir los comandos que pueden ejecutar también. Restrinja el acceso a / bin / su si le preocupa.

¿Qué hay de esto?

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

o

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

o larga línea:

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

sudo -E conserva el entorno PROMPT_COMMAND se ejecuta antes de cada solicitud

Si esto ayuda, puede usar la opción "NOEXEC" de sudoers.

Necesitas definirlo como

USER_NAME         ALL=(ALL) NOEXEC : ALL

Esto evitará fugas de shell y el usuario no podrá usar sudo -i o sudo -s o sudo su -

Esto viene con una desventaja, sin embargo, se deshabilitará cualquier escape de shell. para la ejecución de un script desde dentro de un script también será denegado.

No hagamos esto complicado: cada vez que sudose llama, informa este hecho en algún archivo /var/log(en su sistema auth.log, en mi cuadro OS X es system.log). sudoinforma sus argumentos de línea de comandos, pero no tiene conocimiento de lo que podría suceder dentro de un comando interactivo como su.

Esto no significa que no haya un registro de lo que sucede en un subshell raíz: los comandos de Shell se guardan en el historial del shell. En mi sistema, el guardado del historial de root está habilitado de manera predeterminada, por lo que todo lo que tengo que hacer es buscar ~root/.sh_historyun registro de lo que se hizo (a menos que alguien lo haya manipulado, por supuesto, pero también podrían manipularlo /var/log).

Creo que esta es la mejor solución para ti. Si no, ve a la ciudad con auditd, como sugirió @Jenny.

PD. Si el historial de la raíz aún no está habilitado, habilitarlo depende del shell que utilice. Para bash, establecer HISTORYy HISTFILESIZEen un número lo suficientemente grande (el valor predeterminado es 500, dice mi manual). Si lo desea, puede especificar dónde se guarda el historial configurando HISTFILEuna ruta (predeterminado $HOME/.sh_history)

Es posible que desee crear un mecanografiado de su sesión usando 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

Ahora puede grep(tenga en cuenta que las #indicaciones se registran en realidad /tmp/my_typescript):

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

Alternativamente, incluso puede ver toda la sesión nuevamente con scriptreplay(1):

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

El archivo /tmp/my_typescript.timingcontiene información cuando se ha invocado cada comando. Hay otras herramientas como ttyreco shelrque tienen aún más campanas y silbatos.