
Un sistema binario di autorizzazione e monitoraggio per macOS
[!NOTE] A partire dal 2025, Santa non è più mantenuto da Google. Incoraggiamo gli utenti esistenti a migrare verso un fork di Santa mantenuto attivamente, come https://github.com/northpolesec/santa.
Santa è un sistema di autorizzazione per l'accesso a binari e file per macOS. È composto da un'estensione di sistema che monitora le esecuzioni, un demone che prende decisioni di esecuzione basate sul contenuto di un database locale, un agente GUI che notifica l'utente in caso di blocco e un'utilità da riga di comando per gestire il sistema e sincronizzare il database con un server.
Si chiama Santa perché tiene traccia dei binari che sono stati cattivi o buoni.
La documentazione di Santa è memorizzata nella directory Docs e viene pubblicata su https://santa.dev.
La documentazione include opzioni di distribuzione, dettagli su come funzionano alcune parti di Santa e istruzioni per sviluppare Santa stesso.
Se hai domande o hai bisogno di aiuto per iniziare, il gruppo santa-dev è un ottimo posto.
Se ritieni di aver trovato un bug, sentiti libero di segnalare un problema e risponderemo il prima possibile.
Se ritieni di aver trovato una vulnerabilità, leggi la security policy per la segnalazione.
Modalità multiple: Nella modalità predefinita MONITOR, tutti i binari tranne quelli contrassegnati come bloccati potranno essere eseguiti, mentre vengono registrati e salvati nel database degli eventi. In modalità LOCKDOWN, solo i binari elencati possono essere eseguiti.
Registrazione degli eventi: Quando l'estensione di sistema è caricata, tutti gli avvii di binari vengono registrati. In entrambe le modalità, tutti i binari sconosciuti o negati vengono memorizzati nel database per consentire un'aggregazione successiva.
Regole basate su certificati, con livelli di override: Invece di fare affidamento sull' hash (o 'impronta digitale') di un binario, gli eseguibili possono essere consentiti/bloccati tramite il loro certificato di firma. Puoi quindi consentire/bloccare tutti i binari di un determinato editore che sono stati firmati con quel certificato attraverso gli aggiornamenti di versione. Un binario può essere consentito solo tramite il suo certificato se la firma è convalidata correttamente, ma una regola basata sull'impronta digitale del binario sovrascriverà una decisione basata sul certificato; cioè, puoi inserire in lista bianca un certificato mentre blocchi un binario firmato con quel certificato, o viceversa.
Regole basate sul percorso (tramite NSRegularExpression/ICU): Questa funzionalità è simile a quella presente in Managed Client (il precursore dei profili di configurazione, che utilizzava lo stesso meccanismo di implementazione), Restrizioni di Avvio Applicazioni tramite il binario mcxalr. Questa implementazione ha il vantaggio aggiuntivo di essere configurabile tramite regex e di non dipendere da LaunchServices. Come dettagliato nel wiki, quando si valutano le regole, questa ha la priorità più bassa.
Regole di certificato a prova di guasto: Non è possibile inserire una regola di blocco che bloccherebbe il certificato utilizzato per firmare launchd, noto anche come pid 1, e quindi tutti i componenti utilizzati in macOS. I binari in ogni aggiornamento del sistema operativo (e in alcuni casi intere nuove versioni) sono quindi automaticamente consentiti. Questo non riguarda i binari dell'App Store di Apple, che utilizzano vari certificati che cambiano regolarmente per le app comuni. Allo stesso modo, non puoi bloccare Santa stesso, e Santa utilizza un certificato distinto e separato rispetto ad altre app Google.
I componenti userland si convalidano a vicenda: ciascuno dei componenti userland (il demone, l'agente GUI e l'utilità da riga di comando) comunicano tra loro utilizzando XPC e verificano che i loro certificati di firma siano identici prima che qualsiasi comunicazione venga accettata.
Memorizzazione nella cache: i binari consentiti vengono memorizzati nella cache in modo che l' elaborazione necessaria per effettuare una richiesta venga eseguita solo se il binario non è già nella cache.
Nessun singolo sistema o processo fermerà tutti gli attacchi, né fornirà una sicurezza al 100%. Santa è stato scritto con l'intenzione di aiutare a proteggere gli utenti da sé stessi. Le persone spesso scaricano malware e si fidano di esso, fornendo al malware le credenziali, o permettendo a software sconosciuto di esfiltrare più dati sul tuo sistema. Come componente gestito centralmente, Santa può aiutare a fermare la diffusione di malware tra una grande flotta di macchine. In modo indipendente, Santa può aiutare nell'analisi di ciò che è in esecuzione sul tuo computer.
Santa fa parte di una strategia di difesa in profondità, e dovresti continuare a proteggere gli host in tutti gli altri modi che ritieni opportuni.
Santa blocca solo l'esecuzione (execve e varianti), non protegge contro
librerie dinamiche caricate con dlopen, librerie su disco che sono state
sostituite, o librerie caricate utilizzando DYLD_INSERT_LIBRARIES.
Script: Santa è attualmente programmato per ignorare qualsiasi esecuzione che non sia un binario. Questo perché, dopo aver valutato il costo amministrativo rispetto al beneficio, abbiamo ritenuto che non ne valesse la pena. Inoltre, diverse applicazioni fanno uso di script temporanei generati, che non possiamo inserire in lista bianca e non farlo causerebbe problemi. Siamo felici di rivalutare questa scelta (o almeno renderla un'opzione) se fosse utile ad altri.
Il client da riga di comando santactl include un flag per sincronizzarsi con un
server di gestione, che carica gli eventi verificatisi sulla macchina e
scarica nuove regole. Ci sono diversi server open-source con cui puoi sincronizzarti:
In alternativa, santactl può configurare le regole localmente (senza un server
di sincronizzazione).
Uno strumento come Santa non si presta molto agli screenshot, quindi ecco un video.
Le patch per questo progetto sono molto apprezzate. Consulta il documento CONTRIBUTING.
Questo non è un prodotto ufficiale di Google.