
[ Home | Liste | F.A.Q. |
Risorse | Cerca... ]
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