Come registrare i comandi in un "sudo su -"?

Se io:

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

Quindi posso vedere che nei registri:

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

ma se io:

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

Non riesco a vederlo nei registri:

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

La mia domanda: come posso attivare la registrazione per i comandi all'interno di "sudo su -"?

Il sistema operativo è un Ubuntu 12.04 ma la domanda è in generale.

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]

Dato che sei su Ubuntu 12.04, dai un'occhiata alle abilità di logging I / O attivate tramite le opzioni log_inpute log_output.

log_input

Se impostato, sudoeseguirà il comando in una pseudo tty e registrerà tutti gli input dell'utente. Se l'input standard non è collegato al tty dell'utente, a causa del reindirizzamento I / O o perché il comando fa parte di una pipeline, anche l'input viene acquisito e memorizzato in un file di registro separato.

L'input viene registrato nella directory specificata iolog_dirdall'opzione ( /var/log/sudo-ioper impostazione predefinita) utilizzando un ID sessione univoco incluso nella normale riga del registro sudo, preceduto da TSID=. L' iolog_fileopzione può essere utilizzata per controllare il formato dell'ID sessione.

Si noti che l'input dell'utente può contenere informazioni riservate come password (anche se non vengono ripetute sullo schermo), che verranno archiviate nel file di registro non crittografato. Nella maggior parte dei casi, è necessario registrare l'output del comando tramite log_output.

log_output

Se impostato, sudoeseguirà il comando in una pseudo tty e registrerà tutto l'output inviato allo schermo, in modo simile al comando script (1). Se l'output standard o l'errore standard non è collegato al tty dell'utente, a causa del reindirizzamento I / O o perché il comando fa parte di una pipeline, anche l'output viene acquisito e memorizzato in file di registro separati.

L'output viene registrato nella directory specificata iolog_dirdall'opzione ( /var/log/sudo-ioper impostazione predefinita) utilizzando un ID sessione univoco incluso nella normale riga del registro sudo, preceduto da TSID=. L' iolog_fileopzione può essere utilizzata per controllare il formato dell'ID sessione.

I registri di output possono essere visualizzati con l'utilità sudoreplay (8), che può anche essere utilizzata per elencare o cercare i registri disponibili.

ATTUAZIONE: versione Sudo almeno: 1.7.4p4 necessaria.

/etc/sudoersmodifica: Tutto quello che devi fare è aggiungere due tag a tutte le voci sudoers richieste (dove "su" specificato, con comando o alias). LOG_INPUT e LOG_OUTPUT.

Esempio:

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

Aggiungere la seguente struttura di directory di registro predefinita a sudoers:

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

Il tuo grepquando lo fai sudo su -fallisce perché non sei in esecuzione echo 1234567zz, stai correndo su -, il che lancia una shell. La shell esegue quindi il tuo echo.

Questo è deliberato e la registrazione di ogni singolo comando eseguirà il tuo syslog con informazioni inutili (di solito ci sono tonnellate di programmi che vengono eseguiti dietro le quinte che normalmente non vedi).

Se cambi il grep in grep 'COMMAND=/bin/su -' *lo vedrai.

sudo su -è anche un uso inutile di su. sudo -ifa la stessa cosa.

In crescente complessità, ecco tre modi per registrare i comandi emessi all'interno di "sudo su -":

1. Affidati alla cronologia dei comandi di bash
2. Installare un wrapper di registrazione execve
3. Usa auditd di SELinux

Quanto è adatto, dipende davvero da cosa stai cercando di ottenere con la registrazione.

1) Cronologia dei comandi di Bash

Si vorrebbe configurare la cronologia della cronologia in modo da mantenere linee sufficienti, non sovrascrivere da sessioni diverse, non ignorare i comandi e timestamp appropriati. (Vedi le variabili HIST * nel manuale di bash ). Facilmente sovvertito modificando il file della cronologia, manipolando l'ambiente o eseguendo un'altra shell.

2) eseguire wrapper

snoopylogger è uno. Aggiungi un segno di spunta /etc/profileche la libreria del logger si trova nella mappa di memoria del processo ( /proc/<pid>/maps) e, in caso contrario, imposta LD_PRELOADe riavvia (con exec $SHELL --login "$@"). In alternativa puoi aggiungere una voce a /etc/ld.so.preload con $LIB/snoopy.soo percorsi equivalenti alle tue versioni di snoopy.so a 32/64 bit.

Sebbene sia più difficile, la LD_PRELOADversione della variabile di ambiente di cui sopra potrebbe ancora essere sovvertita manipolando l'ambiente di esecuzione in modo che il codice snoopy non venga più eseguito.

Syslog dovrebbe essere spedito fuori dalla scatola perché i contenuti siano affidabili.

3) auditd

Leggermente più semplice da configurare rispetto al wrapper execve, ma più difficile da cui estrarre le informazioni. Questa è la risposta alla domanda che probabilmente stai davvero ponendo: "Esiste un modo per registrare l'effetto che l'utente ha avuto su un sistema dopo il rilascio sudo su -". Syslog dovrebbe essere spedito fuori dagli schemi perché i contenuti siano affidabili.

Questa risposta Serverfault sembra essere una configurazione abbastanza completa da usare con auditd.

Ci sono altri suggerimenti per una domanda simile su serverfault .

Perché?

Perché è sudoquello che sta facendo la registrazione; registra i comandi sudo. Nel primo caso, sudo echoviene registrato. Nel secondo caso, sudo suviene eseguito l'accesso (cercarlo /var/log/auth.log).

suè "switch user", per impostazione predefinita su root. Tutto ciò che fai dopo non passa sudo. È lo stesso che se avessi effettuato l'accesso come root; il login stesso viene registrato, ma non tutti i comandi.

Come altri hanno già detto, sudonon posso farlo.

Invece, usa auditd. Se vuoi registrare tutto ciò che è stato fatto da root (incluso ad esempio cose fatte da crontab), usa questo:

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

ETA: nota che la registrazione di tutto avrà un impatto sulle prestazioni, quindi probabilmente vorrai limitarla un po '. Vedi man auditctlper esempi.

Se si desidera registrare solo i syscall in cui l'ID di accesso originale non è root, utilizzare invece questo:

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

I registri di solito finiranno in /var/log/audit/audit.log. Puoi cercarli con ausearch.

C'è di più informazioni nelle pagine man per auditctl, audit.rulese ausearch.

sudo su -sarà presente ~/.bash_historyse la tua shell è bash.

echo 1234567zzsarà presente /root/.bash_historyse la shell di root è bash.

Spiegazione di questo è già stato pubblicato da goldilocks.

Vuoi che su acceda perché pensi che sia un difetto di sicurezza? Hai pensato a questo comando? sudo bashaltrettanto male imho.

Se sei preoccupato di cosa le persone possono fare con sudo, dovrai limitarne l'uso. Puoi limitare anche i comandi che possono eseguire. Limita l'accesso a / bin / su se ti preoccupa.

Che dire di questo:

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 one-liner lungo:

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

sudo -E preserva l'ambiente PROMPT_COMMAND viene eseguito prima di ogni prompt

Se questo aiuta, puoi usare l'opzione "NOEXEC" dei sudoers.

È necessario definirlo come

USER_NAME         ALL=(ALL) NOEXEC : ALL

Questo impedirà la fuga di shell e l'utente non sarà in grado di usare sudo -i o sudo -s o sudo su -

Questo ha un aspetto negativo, tuttavia, Qualsiasi escape della shell verrà disabilitato. per l'esecuzione di script all'interno di uno script verrà negato.

Non compliciamolo: ogni volta che sudoviene chiamato, riporta questo fatto in alcuni file /var/log(sul tuo sistema è auth.log, sul mio riquadro OS X è system.log). sudoriporta i suoi argomenti da riga di comando, ma non ha conoscenza di cosa potrebbe accadere all'interno di un comando interattivo come su.

Questo non significa che non ci sia traccia di ciò che accade in una subshell di root: i comandi della shell vengono salvati nella cronologia della shell. Sul mio sistema, il salvataggio della cronologia di root è abilitato per impostazione predefinita, quindi tutto ciò che dovrei fare è cercare ~root/.sh_historyun registro di ciò che è stato fatto (a meno che qualcuno non lo abbia manomesso, ovviamente, ma potrebbero ugualmente manomettere /var/log).

Penso che questa sia la soluzione migliore per te. In caso contrario, vai in città con auditd, come suggerito da @Jenny.

PS. Se la cronologia di root non è già abilitata, l'abilitazione dipende dalla shell utilizzata. Per bash, impostare HISTORYe HISTFILESIZEsu un numero abbastanza grande (il valore predefinito è 500, il mio manuale dice). Se lo desideri, puoi specificare dove salvare la cronologia impostando HISTFILEun percorso (impostazione predefinita $HOME/.sh_history)

Potresti voler creare un dattiloscritto della tua sessione 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

Ora puoi grep(nota che i #prompt sono effettivamente registrati in /tmp/my_typescript):

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

In alternativa, puoi persino guardare di nuovo l'intera sessione con scriptreplay(1):

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

Il file /tmp/my_typescript.timingcontiene informazioni quando è stato invocato ogni comando. Ci sono altri strumenti come ttyreco shelrche hanno ancora più campane e fischietti.