Como logar comandos dentro de um “sudo su -”?

Question

Se eu:

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

Então eu posso ver isso nos 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] 

mas se eu:

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

Não consigo ver nos registros:

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

Minha pergunta: Como posso ativar o login para os comandos dentro do "sudo su -"?

OS é um Ubuntu 12.04 mas a questão é em geral.

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

Já que você está no Ubuntu 12.04, dê uma olhada nas habilidades de registro de E / S ativadas através das opções log_input e log_output .

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.

IMPLEMENTAÇÃO: Versão do Sudo, pelo menos: 1.7.4p4 necessária.

/etc/sudoers modifcation: Tudo o que você precisa fazer é adicionar duas tags a todas as entradas de sudoers necessárias (onde "su" especificado, com comando ou alias). LOG_INPUT e LOG_OUTPUT.

Exemplo:

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

Adicione a seguinte estrutura de diretórios de log padrão a sudoers :

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

    

Answer 2

Seu grep ao fazer sudo su - falhar porque você não está executando echo 1234567zz , você está executando su - , que inicia um shell. O shell está executando o seu echo .

Isso é deliberado, e o registro de cada execução de comando inundaria seu syslog com informações inúteis (geralmente há muitos programas que são executados nos bastidores que você normalmente não vê).

Se você alterar o seu grep para grep 'COMMAND=/bin/su -' * você o verá.

sudo su - também é um uso inútil de su . sudo -i faz a mesma coisa.

    

Answer 3

No aumento da complexidade, aqui estão três maneiras de registrar os comandos emitidos dentro do "sudo su -":

1. Confie no histórico de comandos do bash
2. Instale um wrapper de logging execve
3. Use o auditd do SELinux

Quanto ao que é adequado, realmente depende do que você está tentando realizar com o registro.

1) Histórico do comando Bash

Você deseja configurar o facitlity do histórico para garantir a manutenção de linhas suficientes, não sobrescrevendo de sessões diferentes, não ignorando comandos e registros de data e hora apropriados. (Veja variáveis HIST * no manual do bash ). Facilmente subvertido editando o arquivo de histórico, manipulando o ambiente ou executando outro shell.

2) wrapper execve

snoopylogger é um deles. Adicione uma verificação em /etc/profile de que a biblioteca do criador de logs está no mapa de memória do processo ( /proc/<pid>/maps ) e, se não estiver, defina LD_PRELOAD e reinicie (com exec $SHELL --login "$@" ). Alternativamente, você pode adicionar uma entrada para /etc/ld.so.preload com $LIB/snoopy.so ou caminho (s) equivalente (s) para as suas versões 32/64-bit do snoopy.so.

Embora seja mais difícil, a versão da variável de ambiente LD_PRELOAD do item acima ainda pode ser subvertida pela manipulação do ambiente de execução para que o código snoopy não seja mais executado.

O syslog deve ser enviado off-box para que o conteúdo seja confiável.

3) auditd

Ligeiramente mais simples de configurar do que o wrapper execve, mas mais difícil de extrair as informações. Esta é a resposta a pergunta que você está realmente perguntando: "Existe uma maneira de registrar o efeito que o usuário teve em um sistema depois de emitir sudo su - ". O syslog deve ser enviado off-box para que o conteúdo seja confiável.

Essa resposta do Serverfault parece ser uma configuração bastante abrangente para uso com o auditd.

Há algumas outras sugestões para uma pergunta semelhante em serverfault .

    

Answer 4

Why?

Porque é sudo que está fazendo o registro; registra comandos de sudo. No primeiro caso, sudo echo é registrado. No segundo caso, sudo su está logado (procure por /var/log/auth.log ).

su é "alternar usuário", por padrão, para raiz. Qualquer coisa que você fizer depois disso não passa por sudo . É o mesmo que se você estivesse logado como root; o login em si é registrado, mas não todo e qualquer comando.

    

Answer 5

Como outros já disseram, sudo não pode fazer isso.

Em vez disso, use auditd . Se você quiser logar tudo feito pelo root (incluindo, por exemplo, coisas feitas pelo crontab), use isto:

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

ETA: Observe que registrar tudo afetará o desempenho, portanto, você provavelmente desejará limitá-lo um pouco. Veja man auditctl para exemplos.

Se você quiser apenas registrar syscalls onde o login original não é root, use isto:

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

Os registros geralmente acabam em /var/log/audit/audit.log. Você pode pesquisá-los com ausearch .

Há mais informações nas man pages de auditctl , audit.rules e ausearch .

    

Answer 6

sudo su - estará em ~/.bash_history se seu shell for bash.

echo 1234567zz estará em /root/.bash_history se o shell do root for bash.

Explicação disso já foi postada por goldilocks.

    

Answer 7

Você quer que su registre porque acha que é uma falha de segurança? Você já pensou sobre este comando? sudo bash tão ruim quanto isso.

Se você está preocupado com o que as pessoas podem fazer com o sudo, então você precisará restringir seu uso. Você pode restringir os comandos que eles podem executar também. Restringir o acesso a / bin / su se isso o incomodar.

    

Answer 8

E sobre isso:

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

ou

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

ou um longo verso:

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

sudo -E preserva o ambiente PROMPT_COMMAND é executado antes de cada prompt

    

Answer 9

Se isso ajudar, você pode usar a opção "NOEXEC" de sudoers.

Você precisa defini-lo como

USER_NAME         ALL=(ALL) NOEXEC : ALL

Isto evitará escapes de shell e o usuário não poderá usar sudo -i ou sudo -s ou sudo su -

Isto vem com uma desvantagem, no entanto, Qualquer escape de shell será desativado. por executar o script de dentro de um script também será negado.

    

Answer 10

Não vamos tornar isso complicado: sempre que sudo for chamado, ele relata esse fato em algum arquivo em /var/log (no seu sistema é auth.log , na minha caixa do OS X é system.log ). sudo informa seus argumentos de linha de comando, mas não tem conhecimento do que pode acontecer dentro de um comando interativo como su .

Isso não significa que não há registro do que acontece em um subshell raiz: os comandos do shell são salvos no histórico do shell. No meu sistema, o histórico de armazenamento do root está habilitado por padrão, então tudo que eu tenho que fazer é procurar em ~root/.sh_history um registro do que foi feito (a menos que alguém tenha adulterado isso, é claro, mas eles poderiam igualmente mexer com /var/log ).

Eu acho que esta é a melhor solução para você. Se não, vá para a cidade com auditd , como sugerido pelo @Jenny.

PS. Se o histórico do root ainda não estiver ativado, ativá-lo depende de qual shell ele usa. Para bash , defina HISTORY e HISTFILESIZE para um número suficientemente grande (o padrão é 500, diz meu manual). Se desejar, você pode especificar onde o histórico é salvo, definindo HISTFILE para um caminho (padrão $HOME/.sh_history )

    

Answer 11

Você pode criar um texto datilografado de sua sessão 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

Agora você pode grep (observe que os prompts # estão realmente registrados em /tmp/my_typescript ):

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

Como alternativa, você pode assistir a toda a sessão novamente com scriptreplay(1) :

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

O arquivo /tmp/my_typescript.timing contém informações quando cada comando foi invocado. Existem outras ferramentas como ttyrec ou shelr que têm ainda mais sinos e assobios.