[ Home | Liste | F.A.Q. | Risorse | Cerca... ]


[ Data: precedente | successivo | indice ] [ Argomento: precedente | successivo | indice ]


Archivio: Giugno 2007 ml@sikurezza.org
Soggetto: Re: [ml] grsecurity rbac
Mittente: Claudio
Data: Sun, 17 Jun 2007 10:42:32 +0200 (CEST)
> Sto tentando di configurare le policy rbac di grsecurity.
> Avete qualche lettura da consigliarmi??? A parte grsecurity.org e il
> policy di esempio ovviamente :-)
> Ciao ciao,
>   Gippa

Uso GRsecurity da diversi anni ormai, con risultati assolutamente molto
soddisfacenti. Il consiglio che mi sento di darti è di usare la seguente
prassi.

Installi il sistema operativo, configuri i servizi che ti occorrono e
"hardenizzi" il tutto. Ti comporti esattamente come se non dovessi usare
l'RBAC. In pratica devi far finta di arrivare al roll-out di produzione,
momento in cui tipicamente l'utenza di root viene messa "in cassaforte". A
questo punto, cioè quando ritieni di non dover far più nulla sulla
macchina (eccetto la manutenzione ordinaria, è chiaro), attivi
l'auto-learning di GRsecurity. Puoi farlo manualmente con:

   gradm -E -L /root/full-learn.log

Da questo momento in poi devi usare il server come un normale utente,
facendogli fare (almeno 3-4 volte) tutte le operazioni "normali" su tutti
i servizi che utilizzi. Al termine di ciò, fermi il learning e crei il set
di ACL:

  gradm -D  # ferma l'RBAC
  gradm -F -L /root/full-learn.log -O /root/policy

Il file /root/policy a questo punto contiene ACL che al 90-95% dovrebbero
andar bene al normale funzionamento della macchina, è sono create secondo
il seguente principio su base euristica: tutto ciò che è accaduto almeno
2-3 volte durante il learning è consentito, tutto il resto è "denied".
Inutile dire che occorre sempre ritoccare le policy manualmente!

Dirla così sembra facile, ma purtroppo ci sono alcuni fattori che
innalzano di molto la soglia della complessità. Tra questi ti segnalerei
in particolare le schedulazioni in (ana)crond e simili, spesso
"disastrose" in quanto molte operazioni non avvengono periodicamente come
ci si aspetta, quindi il learning non le registra e prima o poi arriva il
momento in cui prendi il "denied". L'esempio tipico è la rotazione dei log
quando superano una certa dimensione: non puoi essere sicuro che questa
avvenga proprio durante il periodo di learning. Analogamente accade con la
".bash_history" il cui accesso va in append fino a un certo numero di
righe, poi cambia...
Altro momento "difficile" è lo spegnimento o riavvio del server. È
evidente che in quelle fasi l'autolearning si trova nella situazione in
cui dovrebbe scrivere nel log alcuni avvenimenti, ad esempio il fatto che
alcuni processi essere "killati" da taluni altri, ma ormai il filesystem
su cui si trova il log è smontato. Infine il paradosso finale: il processo
grlearn dovrebbe registrare l'accadimento della sua morte! O_o

Ovviamente cose di questo tipo si risolvono a posteriori con la modifica
manuale delle policy, intercettando i vari "denied" nel syslog o - per
quelli più "bastardi" - direttamente sulla console.

Infine, è giusto sottolineare che ci sono diverse scuole di pensiero
relativamente al momento giusto in cui far partire il sistema RBAC.
Qualcuno sostiene che deve essere il primissimo servizio ad attivarsi al
momento del boot (e tra questi ci sono anch'io, abbastanza in contrasto
con Spender, come si evince da alcuni vecchi forum ;-)), ma su questo non
è il caso di soffermarsi ora altrimenti si rischia di far divagare troppo
il thread.

  Saluti, Claudio





[ Home | Liste | F.A.Q. | Risorse | Cerca... ]

www.sikurezza.org - Italian Security Mailing List
(c) 1999-2005