Como posso rastrear executáveis ​​criados pelo meu usuário no Linux?


11

Usando o Linux, gostaria de acompanhar os executáveis ​​executados em meu nome, incluindo toda a linha de comando (na prática, todos os exec * () feitos como meu próprio usuário). Supõe-se que um programa que eu não controle não seja, para lidar com uma tarefa, para executar o programa que passo, mas quero ter certeza de que o faz e quais opções ele usa. O programa que eu não controlo é sorrateiro e parece mudar o comportamento, dependendo do nome do programa que ele deve executar para a tarefa, por isso não posso passar um shell script que registre as informações e invoque o real programa.

É possível que eu seja informado de todos os exec * () s como meu usuário no sistema no Linux, incluindo a linha de comando completa? Falta correr psem um loop, é isso. Prefiro fazê-lo diretamente no sistema em que trabalho e não exigir acesso root, mas, se necessário, posso gerar um sistema no qual tenho acesso root, instalar os programas e investigar lá.

Usando o Ubuntu 12.4 LTS.


Estou perguntando aqui, em vez de perguntar ao Ubuntu, pois é mais uma questão do Unix / Linux do que uma questão real do Ubuntu.
Pierre Lebeaupin

1
Quão furtivo é o programa? Ele tenta detectar ou ignorar depuradores? É dinamicamente vinculado? Se for muito sorrateiro, talvez você precise usar uma máquina virtual onde é root. (Essa pode ser a estratégia mais simples, mesmo para um programa que não seja particularmente furtivo.)
Gilles 'para de ser mau'

@ Gilles Essa é realmente uma possibilidade, vou tentar uma VM e, em seguida, atualizar a pergunta, se isso for viável.
22613 Pierre Lebeaupin

Nota: você parece realmente querer o nome do programa e os argumentos, os quais a resposta auditfornece, mas uma 'linha de comando inteira' no shell também pode afetar o processo filho usando as configurações de redirecionamento / tubulação e envvar, além de conter substituições / expansões, citações não significativas e espaçamento, e estruturas de controle como doa && dob, e você não as receberá.
Dave_thompson_085

Respostas:


10

Você precisa configurar auditdpara gravar execveeventos. Exemplo no RHEL5:

[root@ditirlns01 ~]# auditctl -a always,entry -S execve
WARNING - 32/64 bit syscall mismatch, you should specify an arch
[root@ditirlns01 ~]#

Ignoro o aviso de arco e ele não parece importar, mas você pode usá-lo -F arch=b64ou -F arch=b32configurá-lo, se quiser.

O resultado do exposto acima é:

[root@ditirlns01 ~]# ls /tmp/whatever
ls: /tmp/whatever: No such file or directory
[root@ditirlns01 ~]# grep whatever /var/log/audit/audit.log
type=EXECVE msg=audit(1386797915.232:5527206): argc=3 a0="ls" a1="--color=tty" a2="/tmp/whatever"
type=EXECVE msg=audit(1386797927.133:5527241): argc=3 a0="grep" a1="whatever" a2="/var/log/audit/audit.log"
[root@ditirlns01 ~]#

Isso é obviamente rápido e sujo, mas é o básico de como você faz isso. O que você precisa fazer exatamente depende muito do que você está tentando fazer exatamente. Você pode reduzir o fluxo de auditoria usando vários filtros no auditctlcomando, mas eu não conheço nenhuma dessas informações e não sei o que incluir. Se você precisar de algo mais específico, sugiro que você verifique a página de manual ou poste um comentário para esta resposta, e eu a atualizarei um pouco mais.

Espero que ajude a empurrá-lo na direção certa.

EDITAR:

Como sua pergunta envolve a visualização de um usuário em particular, posso mostrar a você que:

[root@ditirlns01 ~]# auditctl -a always,entry -S execve -F euid=16777216
WARNING - 32/64 bit syscall mismatch, you should specify an arch

Idêntico ao anterior, mas somente execvepor alguém executando com o ID de usuário efetivo de 16777216será registrado. Se você precisar especificar o loginuidvalor do usuário (com quem eles inicialmente efetuaram login no sistema), filtre auid:

[root@ditirlns01 ~]# auditctl -a always,entry -S execve -F auid=16777216
WARNING - 32/64 bit syscall mismatch, you should specify an arch

Os filtros AUID / loginuid seriam úteis, por exemplo, se o usuário fizer um suou sudofazer root. Nessa situação, haverá muitas coisas sendo executadas como root, mas você só se preocupa com as coisas que foram iniciadas pelo usuário em questão. auditctltambém permite empilhar filtros para que você possa filtrar por ambos euide auid:

[root@ditirlns01 ~]# auditctl -a always,entry -S execve -F auid=16777216 -F euid=0
WARNING - 32/64 bit syscall mismatch, you should specify an arch
[root@ditirlns01 ~]# ls /tmp/nashly -ltar
ls: /tmp/nashly: No such file or directory
[root@ditirlns01 ~]# grep nashly /var/log/audit/audit.log
type=EXECVE msg=audit(1386798635.199:5529285): argc=4 a0="ls" a1="--color=tty" a2="/tmp/nashly" a3="-ltar"
type=EXECVE msg=audit(1386798646.048:5529286): argc=3 a0="grep" a1="nashly" a2="/var/log/audit/audit.log"

1
"Observe que eu não tenho acesso root". (Caso contrário, isso seria uma boa resposta.)
Gilles 'para de ser mau' (

Droga ... tão perto ...
Bratchley 12/12

Obrigado, isso funcionou. Devo acrescentar que eu tive que instalar o auditctl pelo apt-get, ele não foi pré-instalado no Ubuntu.
Pierre Lebeaupin

Obrigado. Bons exemplos. Mas existe alguma maneira de obter o código de saída do log de auditoria?
Kaos

0

Você pediu algo simples. Fiz um exemplo, mplayermas acho que pode ser adaptado a outras situações:

#! /bin/sh
# This executable must be used instead of /usr/bin/mplayer
# do not forget the chmod +x filename...
LOG=/tmp/mplayer.log
echo "$@" >> $LOG
if [ -n "$1" ] && [ -f "$1" ] ; then
        filename="$1"
        echo "$(date "+%F %T") $(basename "$filename")" \
        | tee -a "$(dirname "$filename")/mplayer.log"  >> $LOG
fi
/usr/bin/mplayer "$@"

Como você pode ver, isso é muito simples: ele analisa o primeiro argumento, pois é um arquivo, um log é criado no arquivo central $LOGe concatenado em um arquivo (que sempre tem o mesmo nome mplayer.logno mesmo diretório).

Assim, o usuário pode obter o filme mais recente que leu em cada diretório.


O Q disse especificamente que substituir um script não funcionaria.
Dave_thompson_085

Possível, mas isso se encaixa melhor na minha situação: não tenho problemas de segurança e posso escolher o script que corro. Por mais incrível que possa parecer, eu tenho essa solução mais simples e mais simples, talvez alguém esteja interessado em não entrar em coisas apenas para geeks. Admito que a solução anterior é mais segura!
MUY Belgium
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.