Il sottosistema di audit in Mac OS X (e non solo)

Avvertenza: questo post è stato redatto piuttosto rapidamente a corollario di  un’attività reale (sorta di appunti di lavoro) e non pretende di essere esaustivo dell’argomento ne’ scevro da imprecisioni. Il solo scopo per cui è stato redatto è la condivisione di informazioni potenzialmente utili a chi si occupa di amministrazione di sistemi IT.

Oltre al consueto hardening, è utile e in alcuni frangenti necessario, abilitare l’audit del sistema. Qualche esempio di come possa esser utile l’audit?

• sicurezza: accertamenti successivi ad accessi non autorizzati
• sicurezza: monitoraggio, eventualmente in tempo reale,  di uno specifico utente o gruppo di utenti (non entro nel merito delle implicazioni di privacy relative a questo tipo di utilizzo del sottosistema, poichè questo vuol essere un post tecnico)
• debug & tuning: supporto in fase di installazione, configurazione, troubleshooting di applicazioni complesse

Per fare ciò si ricorre al sottosistema di auditing integrato che è basato su una implementazione del Solaris BSM (Base Security Module) sviluppata da McAfee tempo addietro per tener conto dei Common Criteria (maggiori dettagli qui e qui e qui) in ambiente OSX:

“HISTORY
The OpenBSM implementation was created by McAfee Research, the security division of McAfee Inc., under
contract to Apple Computer Inc. in 2004. It was subsequently adopted by the TrustedBSD Project as the
foundation for the OpenBSM distribution.”

Da questo sono derivate altre implementazioni di BSM, quali ad esempio OpenBSM.

Data la profonda similarità tra le implementazioni Solaris e le altre, quanto detto in questo post può essere facilmente adattato a sistemi di altra natura, purchè il sottosistema di audit sia basato su BSM.

Alcune considerazioni preliminari:

• è opportuno dedicare una partizione dedicata al file di trail generato dal sistema di audit, per evitare di bloccare il sistema qualora il file di trail sia particolarmente voluminoso ed arrivi ad esaurire lo spazio disco
• La complessità nell’utilizzo del sistema di audit non è insita nell’utilizzo dei comandi base, ma nell’individuazione di quali classi di eventi registrare al fine di non trovarsi con una massa di informazioni di scarsa utilità pratica e/o riempire velocemente lo spazio disco, cosa questa piuttosto probabile qualora si abiliti un auditing dettagliato su sistemi molto utilizzati. In pratica, la parte di progettazione dell’auditing cambia a seconda del tipo di sistema che si vuole controllare, del tipo di dati che vengono trattati in esso e delle minacce di sicurezza cui sono soggetti. A grandi linee il procedimento da adottare si può riassumere in:

1. Selezione iniziale delle classi di audit per l’intero sistema
2. Individuazione e dimensionamento iniziale della directory dove verranno scritti i trail file generati dal sottosistema di audit
3. Impostazione delle eccezioni per utente rispetto a quanto previsto per l’intero sistema
4. Dopo un iniziale funzionamento del sottosistema di audit, valutazione dei trail file generati per ridurre il numero di record generati, mediante creazione di nuove classi di audit e/o mediante il cambiamento della mappatura tra eventi e classi di audit

In cosa BSM differisce da syslog e varianti? Syslog et similia lavorano a livello applicativo, mentre audit a livello kernel.

BSM consta del supporto kernel, che raccoglie i segnali dal kernel stesso e registra gli eventi in un audit trail file (altrimenti detto log) e di una suite di programmi in user-space, di cui fan parte il demone auditd che attende l’invio degli eventi trigger (trigger events) da parte del kernel e gli eventi di controllo (control events) che provengono invece dai programmi a livello utente mediante audit, utilizzabile da commandline.

I file che compongono il sottosistema di audit in Mac OS X Snow Leopard sono i seguenti:

eseguibili

• /usr/sbin/auditd
• /usr/sbin/audit
• /usr/sbin/auditreduce
• /usr/sbin/praudit

Trail file

• /var/audit [è possibile cambiare questo path dal file di configurazione]

Configurazione

• /etc/security/rc.audit
• /etc/security/audit_control
• /etc/security/audit_class
• /etc/security/audit_event
• /etc/security/audit_user
• /etc/security/audit_warn
• /etc/security/audit_messages

Le funzionalità di auditing vengono attivate configurando il file /etc/hostconfig aggiungendo la variabile AUDIT corredata dell’appropriato selettore, che può essere impostata a:

• -YES- abilita l’auditing all’avvio del sistema
• -NO- non abilitare l’auditing all’avvio del sistema
• -FAILSTOP- abilita l’auditing con il comando audit e l’opzione -s che fa sì che qualora il file dove vengono registrati i log sia a corto di spazio il sistema di audit viene fermato
• -FAILHALT- abilita l’auditing con il comando audit e l’opzione -h, che fa sì che il sistema venga fermato se non è possibile scrivere nel file di log (questa opzione può esser utilizzata nei sistemi per i quali è richiesto un livello di sicurezza particolarmente elevato, ma vanno accuratamente selezionati gli eventi da registrare e deve essere dedicato un opportuno spazio per i file di log)

Il file audit_class indica, nella forma maschera:nome:descrizione, quali classi di eventi vengono registrate:

• all tutti gli eventi
• ad administrative events
• cl file close events
• fa file attribute access events
• fc file create events
• fm file attribute modify
• lo login/logout events
• …ecc…

[suggerimento: man audit_class]

Come registrare gli eventi suindicati è specificato dai prefissi seguenti:

• + registra gli eventi che hanno avuto successo
• - registra gli eventi che non hanno avuto successo
• ^ registra sia gli eventi che hanno avuto successo che quelli che no
• ^+ non registra gli eventi che hanno avuto successo
• ^- non registra gli eventi che non hanno avuto successo

Il file audit_control indica:

• dove viene creato il file di trail, che normalmente è configurato nella directory /var/audit
• quali classi di eventi vengono registrati per l’intero sistema e per qualsiasi utente. Gli eventi che vengono registrati su base di specifici utenti sono indicati nel file audit_user
• lo spazio libero minimo, espresso in percentuale, che deve essere disponibile per il sistema di audit affinchè scriva il file di trail
• quali classi di eventi debbono essere registrate pure se non attribuibili a utenti specifici

Il file di trail (ve ne è solo uno aperto per volta) è in formato binario e per rendere comprensibili agli umani i messaggi che in esso sono scritti si utilizza il comando praudit. Ad esempio:

ab$ sudo praudit /var/audit/20101028174243.crash_recovery
…
trailer,143
header,143,11,unlink(2),0,Thu Oct 28 19:49:21 2010, + 539 msec
path,/Users/ab/Library/Application Support/Skype/ab/userxxxxx.dbb
subject,ab,ab,abgroup,ab,abgroup,157,2177027,50331650,0.0.0.0
return,failure : No such file or directory,4294967295
trailer,143
header,144,11,unlink(2),0,Thu Oct 28 19:49:21 2010, + 539 msec
path,/Users/ab/Library/Application Support/Skype/ab/userxxxxxx.dbb
subject,ab,ab,abgroup,ab,abgroup,157,2177027,50331650,0.0.0.0
return,failure : No such file or directory,4294967295
trailer,144
header,144,11,unlink(2),0,Thu Oct 28 19:49:21 2010, + 539 msec
path,/Users/ab/Library/Application Support/Skype/ab/userxxxx.dbb
subject,ab,ab,abgroup,ab,abgroup,157,2177027,50331650,0.0.0.0
return,failure : No such file or directory,4294967295
trailer,144
header,144,11,unlink(2),0,Thu Oct 28 19:49:21 2010, + 539 msec
path,/Users/ab/Library/Application Support/Skype/ab/userxxxx.dbb
subject,ab,ab,abgroup,ab,abgroup,157,2177027,50331650,0.0.0.0
return,failure : No such file or directory,4294967295
trailer,144
header,144,11,unlink(2),0,Thu Oct 28 19:49:21 2010, + 539 msec
path,/Users/ab/Library/Application Support/Skype/ab/userxxxx.dbb
subject,ab,ab,abgroup,ab,abgroup,157,2177027,50331650,0.0.0.0
return,failure : No such file or directory,4294967295
trailer,144
header,145,11,unlink(2),0,Thu Oct 28 19:49:21 2010, + 539 msec
path,/Users/ab/Library/Application Support/Skype/ab/userxxxx.dbb
subjectab,ab,abgroup,ab,abgroup,157,2177027,50331650,0.0.0.0
return,failure : No such file or directory,4294967295
trailer,145
header,145,11,unlink(2),0,Thu Oct 28 19:49:21 2010, + 539 msec
path,/Users/ab/Library/Application Support/Skype/ab/userxxxx.dbb
subject,ab,ab,abgroup,ab,abgroup,157,2177027,50331650,0.0.0.0
return,failure : No such file or directory,4294967295
…

Un interessante aspetto è la possbilità di monitorare in tempo reale il sistema, mediante il comando “praudit /dev/auditpipe”, il cui output è però meno affidabile di quello proveniente dal trail file, specie in sistemi molto caricati.

Le manpages dei comandi del sottosistema di audit sono particolarmente esplicative del loro utilizzo e dell’architettura del sottosistema di cui fanno parte (ad esempio, man audit.log contiene molte utili informazioni su come sono costruiti gli audit trails).

Link per approfondire l’argomento:
Alcuni, se non molti, dei seguenti link di approfondimento sono relativi a BSM in ambiente Sun Solaris, ma le informazioni in essi contenute possono essere utili a comprenderne l’implementazione ed interagire con il sottosistema in Mac OS X. Enjoy!

• man pages: $man -k audit
• Dal sito apple
• Dal sito Oracle
• Solaris BSM auditing
• Solarsi C2 Auditing with BSM
• Monitoring user commands using BSM audit logs
• Compliant Security Event Audit System for Mac OS X and FreeBsd
• Altro dal sito Oracle (sebbene redatto per la configurazione su sistemi Solaris con db Oracle, fornisce utili indicazioni di pianificazione)

Aggiornato il 5 agosto 2011: aggiunto link alla guida Apple alla configurazione sicura di Mac OS X 10.6