whatfiles

Whatfiles è un'utilità Linux che registra quali file un altro programma legge/scrive/crea/elimina sul tuo sistema. Traccia anche tutti i nuovi processi e thread creati dal processo target, e registra se ogni operazione è andata a buon fine.

Motivazione:

Sono da tempo frustrato dalla mancanza di una semplice utilità per vedere quali file tocca un processo da main() all'uscita. Che tu non ti fidi di un fornitore di software o sia preoccupato per il malware, è importante poter sapere cosa fa un programma o un installer al tuo sistema. lsof osserva solo un istante nel tempo e strace è grande e alquanto complicato.

Output di esempio:

mode:   exec, file: /usr/bin/cp, syscall: execve(), PID: 17004, process: sh, result: 0
mode:   read, file: /tmp/demo/copy.txt, syscall: openat(), PID: 17004, process: /usr/bin/cp, result: -1 (No such file or directory)
mode:   read, file: /etc/hostname, syscall: openat(), PID: 17004, process: /usr/bin/cp, result: 3
mode: write+create, file: /tmp/demo/copy.txt, syscall: openat(), PID: 17004, process: /usr/bin/cp, result: 4
mode:  chmod, file: /tmp/demo/copy.txt, syscall: fchmodat(), PID: 17005, process: /usr/bin/chmod, result: 0
mode: rename, file: /tmp/demo/copy.txt, to: /tmp/demo/renamed.txt, syscall: renameat2(), PID: 17006, process: /usr/bin/mv, result: 0
mode:   read, file: /tmp/demo/missing.txt, syscall: openat(), PID: 17007, process: /usr/bin/cat, result: -1 (No such file or directory)
mode: delete, file: /tmp/demo/renamed.txt, syscall: unlinkat(), PID: 17008, process: /usr/bin/rm, result: 0

Ogni riga indica cosa è stato fatto al file, il file stesso, quale syscall lo ha fatto, quale processo e thread, e cosa ha restituito il kernel. I percorsi sono sempre assoluti: i percorsi relativi vengono risolti rispetto alla directory di lavoro del processo, o rispetto alla directory passata a una syscall *at(). result è il valore di ritorno della syscall, quindi accessi falliti e riusciti possono essere distinti.

Oltre ad aprire, creare ed eliminare, whatfiles segnala rename, link, symlink, mkdir, rmdir, truncate, chmod, chown ed exec di un programma. SYSCALLS.md illustra cosa non viene ancora segnalato e perché ogni aggiunta varrebbe la pena.

Utilizzo:

• uso di base, avvia ls e scrive l'output in un file di log nella directory corrente:

  $ whatfiles ls -lah ~/Documents

• specifica la posizione del file di output con -o:

  $ whatfiles -o MyLogFile cd ..

• includi l'output di debug, stampa su stdout invece che su file di log:

  $ whatfiles -d -s apt install zoom

• collegati a un processo attualmente in esecuzione (richiede privilegi di root):

  $ sudo whatfiles -p 1234

• termina il programma tracciato se whatfiles stesso viene terminato, invece di lasciarlo continuare non tracciato:

  $ whatfiles -k ./installer.sh

Premi Ctrl-C in qualsiasi momento: whatfiles si scollega da tutto ciò che sta tracciando, lascia quei processi in esecuzione e termina di scrivere il log.

Distribuzione

Binari pronti all'uso sono nella pagina delle releases! Qualcuno lo ha anche gentilmente aggiunto al repository Arch, e letompouce ha anche configurato una pipeline GitLab.

Compilazione (richiede gcc e make):

$ cd whatfiles
$ make
$ sudo make install

Supporta le architetture x86, x86_64, ARM32 e ARM64. make install rispetta PREFIX e DESTDIR.

È richiesto Linux 3.4 o successivo. Su Linux 5.3 e successivi, whatfiles interroga direttamente il kernel su ogni stop di syscall, ed è ciò che fa decodificare correttamente le syscall a 32 bit su una macchina a 64 bit; sui kernel più vecchi ricade sulla lettura dei registri.

Android

Cross-compila con l'NDK, poi invia il binario al dispositivo:

$ make android NDK=~/Android/Sdk/ndk/<version>
$ adb push bin/whatfiles-android /data/local/tmp/whatfiles
$ adb shell chmod 755 /data/local/tmp/whatfiles
$ adb shell /data/local/tmp/whatfiles -o /data/local/tmp/ls.log ls /sdcard

ANDROID_ABI seleziona arm64, il valore predefinito, oppure arm32, x86_64 o x86. ANDROID_API imposta il livello API minimo e il valore predefinito è 21.

Su un dispositivo alcune cose differiscono:

• Metti il binario in /data/local/tmp. /sdcard è montata senza permesso di esecuzione.
• La directory di lavoro in adb shell non è scrivibile, quindi passa -o con un percorso sotto /data/local/tmp, oppure -s per scrivere su stdout.
• Eseguire un comando sotto whatfiles funziona come utente shell ordinario, e così anche collegarsi a un processo avviato da quell'utente. Collegarsi a qualsiasi altra cosa, un'app per esempio, richiede root, quindi adb root su una build userdebug. Su un emulatore Android 14 ha funzionato con SELinux in modalità enforcing; la policy di un dispositivo di produzione potrebbe comunque rifiutare.
• make test-android NDK=~/Android/Sdk/ndk/<version> compila whatfiles e i programmi di test per il dispositivo collegato, esegue i controlli lì e rimuove ciò che ha inviato.
• Un'app a 32 bit tracciata da una build arm64 viene letta con i numeri di syscall a 32 bit e i registri degli argomenti a 32 bit invece di essere presa per una a 64 bit. Quel percorso non è stato esercitato su hardware reale: l'emulatore usato per i test qui non ha ABI a 32 bit.

make test compila i programmi in tests/ e li esegue sotto whatfiles per verificarne il comportamento, inclusa la consegna dei segnali, la copertura di thread e processi figli, e la gestione degli interrupt.

Domande che potrebbero essere poste a un certo punto:

• Non è solo una reimplementazione di strace -fe trace=creat,open,openat,unlink,unlinkat ./program?

  Sì. Anche se mira a essere più semplice e più facile da usare.

• Esistono versioni per Mac e Windows?

  No. Tracciare le syscall su Mac richiede task_for_pid(), che richiede la firma del codice, cosa che non riesco a far funzionare, e comunque non ho alcun interesse a pagare ad Apple 100 $/anno per scrivere software libero. dtruss su Mac può essere usato per seguire un singolo processo e i suoi figli, anche se il flag -t sembra accettare solo una singola syscall su cui filtrare. fs_usage fa qualcosa di simile anche se non sono sicuro che segua processi/thread figli. Process Monitor per Windows è piuttosto ottimo.

Limitazioni:

• Programmi che passano il controllo a una copia di se stessi. Soprattutto i browser: se un'istanza è già in esecuzione, quella che avvii passa la tua richiesta a essa ed esce, quindi whatfiles non ha più nulla da tracciare e si ferma, mentre la finestra che hai richiesto proviene dalla copia non tracciata. Traccia invece un'istanza separata, con qualcosa come whatfiles firefox --no-remote --profile ~/ff-trace-profile e una directory di profilo che non esiste ancora, oppure chiudi prima la copia in esecuzione.

• Non è un confine di sicurezza. Un programma che non vuole essere osservato può capire che è in fase di tracciamento, e io_uring esegue operazioni sui file senza le syscall che whatfiles osserva. Considera il log come una descrizione di ciò che un programma ha fatto, non come prova di tutto ciò che avrebbe potuto fare.

• Velocità. Ogni syscall ferma il processo tracciato due volte, quindi i programmi con molte syscall girano diverse volte più lentamente del solito. È lo stesso costo che strace paga quando segue tutte le syscall.

• Il collegamento richiede privilegi. -p generalmente richiede root, o un /proc/sys/kernel/yama/ptrace_scope rilassato. Un collegamento rifiutato lascia il target in esecuzione normale.

• Se whatfiles viene terminato di netto con SIGKILL, il programma che stava tracciando continua a girare, non tracciato, a meno che non sia stato avviato con -k.

Funzionalità pianificate:

• Nessuna al momento, aperto a richieste e PR.

Grazie per il tuo interesse, e dai anche un'occhiata a Cloaker, Nestur e Flying Carpet!