Monitoraggio delle chiamate di sistema (in modo affidabile e sicuro)

Su Linux, puoi monitorare in modo affidabile una selezione di chiamate di sistema o accessi ai file con il sottosistema di controllo . Assicurati che il daemon auditd sia in esecuzione, quindi configura ciò che vuoi registrare con auditctl . Ogni operazione registrata viene registrata in /var/log/audit/audit.log (su configurazioni tipiche).

Troverai semplici esempi di auditctl di utilizzo su questo sito , su Errore server e su Scambio pila Unix .

strace o programmi associati che utilizzano ptrace sono metodi affidabili per monitorare le chiamate di sistema, ma sarei prudente nell'usarli su un programma dannoso. Non potrei dirti quanto è fuori di testa, ma dovrebbe essere possibile che un programma monitorato compia il giusto ptrace di chiamate per evitare il monitoraggio.

Si noti che un programma dannoso potrebbe generare un processo che non è controllato e può eseguire codice che non verrà registrato. Ad esempio, potrebbe utilizzare mmap per scrivere su un file senza che il contenuto del file appaia come argomento delle chiamate di sistema, rendere questo file eseguibile e generare un processo che lo esegue. Generalmente il processo generato può interrompere la struttura del processo con qualcosa come ssh localhost . Se controlli tutti i processi eseguiti da un determinato utente (al contrario di un singolo processo e i suoi discendenti), sarai in grado di registrare tutto.

If yes, Is there another reliable, secure method of "monitoring" system calls (and, maybe receiving signals), that process can not break (assuming proper Linux implementation) ?

Per reiterare in un modo leggermente diverso ciò che D.W. ha già detto, ptrace è una chiamata di sistema che strace , gdb e simili fanno per monitorare le azioni di un processo. Ci sono due problemi con questo approccio:

1. Come probabilmente sapete, le chiamate di sistema di hooking sono una tecnica preferita degli autori di rootkit. È del tutto possibile sostituire ptrace , fornire l'output di un altro processo o di qualche altro tipo di malfunzionamento.

2. I processi non sono sempre scritti per presentare volontariamente ai debugger. Ti potrebbe interessare leggere questo set di sfida (incentrato su win32 - guarda la primissima voce e continua a leggere per renderla difficile) da una società appec (non ho collegamenti con loro). Pur concentrandosi sul meccanismo IsDebuggerPresent() , simili soluzioni esistono per ptrace . Se vuoi vedere questo in the wild e avere skype installato su una macchina Linux, prova a eseguirne il debug.

   Ripetendo queste tecniche qui, ci sono due chiari meccanismi anti-ptrace:

   if (ptrace(PTRACE_TRACEME, 0, 0, 0) < 0) {
       printf("being ptraced\n");
       exit(1);
   }
   

   Questo metodo si basa sul fatto che un processo non può essere tracciato due volte. Se non riesci a stabilirti, ti stai preparando.

   struct timespec spec;
   
   signal(SIGALRM, SIG_IGN);
   alarm(1);
   spec.tv_sec = 2;
   spec.tv_nsec = 0;
   if (nanosleep(&spec, NULL) < 0) {
       /* EINTR */
       printf("being ptraced\n");
       exit(1);
   }
   

   Per spiegarlo, dai un'occhiata a nanosleep() e leggi l'articolo originale. In termini semplici, nanosleep() è una chiamata di sistema non riavviabile e ritornerà in anticipo quando un processo viene gestito da un segnale. Questo particolare processo, quando non viene eseguito il debug, non gestirà quel particolare segnale e quindi non verrà risvegliato. Tuttavia, un processo precostituito lo gestirà, causando il ritorno di nanosleep in anticipo. Un altro esempio in cui ciò accade è la chiamata di sistema select() .

In definitiva, puoi mitigare gli effetti di 1 assicurando l'integrità del tuo sistema prima di iniziare e applicare misure di sicurezza sufficienti e un kernel adeguatamente configurato.

Che cosa puoi fare in modo affidabile su 2? Non molto senza modificare il codice binario originale, dal momento che qualsiasi tecnica per il debug introdurrà incoerenze osservabili o problemi di implementazione da qualche parte.

tl; dr ptrace ti aiuterà se il processo di destinazione non è stato scritto pensando ai debugger.

Il Linux Audit Framework supporta il monitoraggio syscall - Credo che sia quello che stai cercando.

Sì. strace è un modo ragionevole per monitorare le chiamate di sistema e i loro argomenti, purché il processo monitorato non sia dannoso. Se il processo che si sta monitorando è malevolo ed è stato scritto per eludere strace, mi aspetto che possa farlo. strace non è stato scritto come uno strumento di sicurezza e posso ipotizzare diversi modi in cui il processo potrebbe sconfiggerlo. Vedi, ad esempio, Robert Watson, sfruttamento delle vulnerabilità di concorrenza nei System Call Wrappers o Tal Garfinkel, Trappole e insidie: problemi pratici negli strumenti di sicurezza basati sull'intervallo di chiamata di sistema .

Se sei preoccupato per il codice dannoso, ti consigliamo di utilizzare una sandbox progettata per la sicurezza, piuttosto che uno strumento come strace che non è stato progettato per la sicurezza. L'approccio generale alla creazione di tale sandbox consiste nell'utilizzare l'interposizione di chiamata di sistema sia per contenere il processo monitorato, sia per monitorare le sue azioni. Un metodo portatile consiste nell'utilizzare ptrace, sebbene questo possa introdurre un overhead delle prestazioni non banale in quanto impone un cambio di contesto su ogni chiamata di sistema. Su Solaris, puoi usare / proc; / proc ti consente di specificare il sottoinsieme di chiamate di sistema che ti interessano nel wrapping, che ti consente di ottenere prestazioni migliori a costo di compatibilità.

Dai un'occhiata a Plash, Systrace e Subterfugue, per vedere alcuni sistemi funzionanti che usano questo tipo di metodi. Guarda anche la sandbox di Chrome, che usa una varietà di meccanismi (incluso seccomp su Linux).