Come posso tracciare gli eseguibili creati dal mio utente su Linux?


11

Usando Linux, vorrei tracciare gli eseguibili che sono eseguiti a mio nome, inclusa l'intera riga di comando (in pratica, ogni exec * () fatto come il mio utente). Si suppone che un programma che non controllo, al fine di gestire un'attività, esegua il programma che passo, ma voglio assicurarmi che lo faccia e quali opzioni utilizza. Il programma che non controllo è subdolo e sembra cambiare comportamento a seconda del nome del programma che dovrebbe eseguire per l'attività, quindi non posso passare uno script shell che registrerebbe le informazioni e invocherebbe il reale programma.

È possibile per me essere informato di tutti i exec * () eseguiti come utente sul sistema su Linux, inclusa la riga di comando completa? A corto di corsa psin un ciclo, cioè. Preferirei farlo direttamente sul sistema su cui lavoro e non richiedere l'accesso root, ma se necessario posso generare un sistema su cui ho accesso root, installare i programmi e indagare lì.

Usando Ubuntu 12.4 LTS.


Sto chiedendo qui piuttosto che porre Ubuntu, poiché è più una domanda Unix / Linux che una vera domanda Ubuntu.
Pierre Lebeaupin,

1
Quanto è subdolo il programma? Tenta di rilevare o bypassare i debugger? È collegato dinamicamente? Se è troppo subdolo, potrebbe essere necessario utilizzare una macchina virtuale in cui sei root. (Questo può essere la strategia più semplice anche per un programma che non è particolarmente subdolo.)
Gilles 'stop SO-essere malvagio'

@Gilles Questa è davvero una possibilità, ho intenzione di provare una macchina virtuale, quindi aggiornare la domanda se risulta essere fattibile.
Pierre Lebeaupin,

Nota: sembra che tu voglia effettivamente il nome del programma e gli argomenti, con cui auditdà la risposta , ma una 'intera riga di comando' nella shell potrebbe anche influenzare il processo figlio usando le impostazioni di reindirizzamento / piping e envvar oltre a contenere sostituzioni / espansioni, quotazioni non significative e spaziatura e strutture di controllo simili doa && dob, e non le otterrai.
dave_thompson_085,

Risposte:


10

È necessario configurare auditdper registrare execveeventi. Esempio su RHEL5:

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

Ignoro l'avvertimento dell'arco e non sembra importare ma puoi usarlo -F arch=b64o -F arch=b32impostarlo se vuoi.

Il risultato di quanto sopra è:

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

Questo è ovviamente veloce e sporco, ma sono le basi di come lo fai. Quello che devi fare esattamente probabilmente dipende fortemente da ciò che stai cercando di fare esattamente. Puoi ridurre il flusso di controllo usando vari filtri nel auditctlcomando ma non conosco nessuna di queste informazioni, quindi non so cosa includere. Se hai bisogno di qualcosa di più specifico, ti suggerisco di controllare la pagina man o pubblicare un commento a questa risposta e lo aggiornerò ancora.

Spero che ti aiuti a spingerti nella giusta direzione.

MODIFICARE:

Poiché la tua domanda riguarda l'esame di un determinato utente, posso mostrarti che:

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

Identico a quanto sopra, ma viene registrato solo execveda qualcuno che esegue con l'ID utente effettivo di 16777216. Se è necessario specificare il loginuidvalore dell'utente (da chi ha effettuato inizialmente l'accesso al sistema), filtrare auidinvece per:

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

I filtri AUID / loginuid sarebbero utili, ad esempio, se l'utente eseguirà un root suo sudo. In quella situazione ci saranno molte cose in esecuzione come root, ma ti preoccupi solo delle cose che sono state lanciate dall'utente in questione. auditctlti consente anche di impilare i filtri in modo da poter filtrare per entrambi 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
"Nota che non ho accesso come root". (Altrimenti questa sarebbe una buona risposta.)
Gilles 'SO- smetti di essere malvagio' l'

Accidenti ... così vicino ...
Bratchley,

Grazie, ha funzionato. Dovrei aggiungere che ho dovuto installare auditctl da apt-get, non era preinstallato su Ubuntu.
Pierre Lebeaupin,

Grazie. Bei esempi. Ma esiste un modo per estrarre il codice di uscita dal registro di controllo?
Kaos,

0

Hai chiesto qualcosa di semplice. Ho fatto un esempio con mplayerma immagino che possa essere adattato ad altre situazioni:

#! /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 "$@"

Come puoi vedere, è molto semplice: analizza il primo argomento, poiché si tratta di un file, un registro viene creato nel file centrale $LOGe concatenato in un file (che ha sempre lo stesso nome mplayer.lognella stessa directory.

Quindi, l'utente può ottenere l'ultimo film che ha letto su ogni directory.


Il Q ha affermato in particolare che la sostituzione di uno script non funzionerebbe.
dave_thompson_085,

Possibile, ma questo si adatta meglio alla mia situazione: non ho problemi di sicurezza e posso scegliere lo script che eseguo. Per quanto incredibile possa sembrare, ho pensato a questa soluzione più semplice e semplice, forse qualcun altro sarà interessato a non occuparsi di cose per soli geek. Ammetto che la soluzione precedente è più sicura!
MUY Belgio,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.