Como registrar comandos dentro de um "sudo su -"?

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 vê-lo nos logs:

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

Minha pergunta: como ativar o logon dos comandos no "sudo su -"?

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

ATUALIZAÇÃO # 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 você está no Ubuntu 12.04, veja as habilidades de registro de E / S ativadas através das opções log_inpute log_output.

log_input

Se definido, sudoexecutará o comando em uma pseudo tty e registrará todas as entradas do usuário. Se a entrada padrão não estiver conectada ao tty do usuário, devido ao redirecionamento de E / S ou porque o comando faz parte de um pipeline, essa entrada também será capturada e armazenada em um arquivo de log separado.

A entrada é registrada no diretório especificado pela iolog_diropção ( /var/log/sudo-iopor padrão) usando um ID de sessão exclusivo que está incluído na linha de log sudo normal, com o prefixo TSID=. A iolog_fileopção pode ser usada para controlar o formato do ID da sessão.

Observe que a entrada do usuário pode conter informações confidenciais, como senhas (mesmo que não sejam ecoadas na tela), que serão armazenadas no arquivo de log sem criptografia. Na maioria dos casos, é necessário registrar a saída do comando via log_output.

log_output

Se definido, sudoexecutará o comando em uma pseudo tty e registrará toda a saída enviada para a tela, semelhante ao comando script (1). Se a saída padrão ou o erro padrão não estiver conectado ao tty do usuário, devido ao redirecionamento de E / S ou porque o comando faz parte de um pipeline, essa saída também será capturada e armazenada em arquivos de log separados.

A saída é registrada no diretório especificado pela iolog_diropção ( /var/log/sudo-iopor padrão) usando um ID de sessão exclusivo incluído na linha de log normal do sudo, prefixada com TSID=. A iolog_fileopção pode ser usada para controlar o formato do ID da sessão.

Os logs de saída podem ser visualizados com o utilitário sudoreplay (8), que também pode ser usado para listar ou pesquisar os logs disponíveis.

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

/etc/sudoersmodificação: Tudo que você precisa fazer é adicionar duas tags a todas as entradas necessárias do sudoers (onde "su" foi 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ório de log padrão a sudoers:

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

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

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

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

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

Para aumentar a complexidade, aqui estão três maneiras de registrar os comandos emitidos no "sudo su -":

1. Confie no histórico de comandos do bash
2. Instalar um wrapper de log de execução
3. Use a auditoria do SELinux

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

1) Histórico de comandos Bash

Você deseja configurar a facilidade do histórico para garantir a manutenção de linhas suficientes, sem sobrescrever a partir de sessões diferentes, sem ignorar comandos e carimbos de data / hora apropriados. (Veja variáveis ​​HIST * no manual do bash ). Subvertido facilmente editando o arquivo de histórico, manipulando o ambiente ou executando outro shell.

2) invólucro execve

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

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

O syslog deve ser enviado fora da caixa para que o conteúdo seja confiável.

3) auditoria

Um pouco mais simples de configurar do que o wrapper execve, mas mais difícil de extrair as informações. Esta é a resposta à pergunta que você provavelmente está realmente perguntando: "Existe uma maneira de registrar qual efeito o usuário teve no sistema após a emissão sudo su -". O syslog deve ser enviado fora da caixa para que o conteúdo seja confiável.

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

Existem outras sugestões para uma pergunta semelhante sobre a falha do servidor .

Por quê?

Porque é isso sudoque está fazendo o log; ele registra comandos do sudo. No primeiro caso, sudo echoé registrado. No segundo caso, sudo sué registrado (procure-o /var/log/auth.log).

sué "alternar usuário", por padrão, para root. Tudo o que você faz depois disso não passa sudo. É o mesmo que se você tivesse feito login como root; o login em si é registrado, mas não todo comando.

Como outros já disseram, sudonão posso fazer isso.

Em vez disso, use auditd. Se você deseja registrar tudo o que é feito pelo root (incluindo, por exemplo, o feito pelo crontab), use o seguinte:

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

ETA: Observe que o registro de tudo afetará o desempenho, portanto, você provavelmente desejará limitar um pouco. Veja man auditctlpara exemplos.

Se você deseja registrar apenas os syscalls nos quais o uid de login original não é root, use este:

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

Os logs geralmente terminam em /var/log/audit/audit.log. Você pode procurá-los com ausearch.

Há mais informações nas páginas man para auditctl, audit.rulese ausearch.

sudo su -estará dentro ~/.bash_historyse o seu shell for bash.

echo 1234567zzestará dentro /root/.bash_historyse o shell do root for bash.

A explicação disso já foi publicada por goldilocks.

Deseja que o su faça logon porque considera uma falha de segurança? Você já pensou nesse comando? sudo bashtão ruim imho.

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

Que tal 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 uma linha longa:

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

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

Você precisa defini-lo como

USER_NAME         ALL=(ALL) NOEXEC : ALL

Isso impedirá que o shell escape e o usuário não poderá usar sudo -i ou sudo -s ou sudo su -

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

Não vamos complicar: sempre que sudochamado, ele informa esse fato em algum arquivo /var/log(no seu sistema auth.log, na caixa do OS X system.log). sudorelata 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 salvamento do histórico do root é ativado por padrão, então tudo o que preciso fazer é procurar ~root/.sh_historyum registro do que foi feito (a menos que alguém tenha mexido nele, é claro, mas eles também podem mexer /var/log).

Eu acho que essa é a melhor solução para você. Caso contrário, vá à cidade com auditd, como @Jenny sugeriu.

PS. Se o histórico do root ainda não estiver ativado, a ativação dependerá de qual shell ele usar. Para bash, defina HISTORYe HISTFILESIZEcom um número grande o suficiente (o padrão é 500, diz o meu manual). Se desejar, você pode especificar onde o histórico é salvo, definindo HISTFILEum caminho (padrão $HOME/.sh_history)

Você pode criar um texto datilografado da 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 /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.timingcontém informações quando cada comando foi chamado. Existem outras ferramentas como ttyrecou shelrque têm ainda mais sinos e assobios.