Hartowanie i RBAC, czyli Hardened Gentoo, SELinux i Grsecurity - część 1.
14 lipiec 2007, autorstwa: 
kozik Może zacznę z innej beczki: na PW na zajęciach prowadzonych przez ato przygotowywało się pod koniec sprawozdanie z projektu. Było to albo sprawko opisujące wykonaną pracę albo… sprawozdanie z porażki.
Hartując moje serwery doszedłem do bardzo ważnego punktu - implementacji RBAC i/lub MAC. Pierwsze podejście skończyło się właśnie porażką i rozpocznijmy sprawozdanie z niej. Cześć pierwsza.
Gentoo posiada swój własny projekt - Hardened Gentoo - mający pomóc administratorom w “hartowaniu”serwera. Jednym z elementów hardeningu jest zabezpieczenie przed atakami np. wykorzystującymi przepełnienie bufora czy sterty. Realizują to łaty PaX lub SSP. Zwrócić warto uwagę, że oprócz Debiana (i Adamantiksa na nim bazującego) oraz RHEL, chyba tylko Gentoo z dystrybucji Linuksowych wspiera rozwiązania hardening na tak wysokim poziomie i w takiej ilości. Argument za zastosowaniami Gentoo w rozwiązaniach produkcyjnych?
Wracając jednak do sedna - oprócz zabezpieczeń związanych bezpośrednio z błędami w oprogramowaniu ważna jest również modyfikacja kontroli dostępu w Linuksie. Standardowo Linux opiera się na DAC-u (Discretionary access control), czyli podstawą kontroli jest głównie UID/GID + prawa rwx (ew. inne) do plików/obiektów. Jednocześnie, aby móc zbindować się (oooo, ale wymyśliłem… przypiąć się?) do portu <1024 lub obsługiwać niektóre urządzenia usługi muszą startować z praw roota. A root jako UID/GID = 0 może zasadniczo wszystko. Wszystko popsuć rzecz jasna. Model ten już dawno został uznany za niebezpieczny, a jeśli komuś się wydaje, że używanie “sudo” cokolwiek poprawia, to jest w błędzie.
Rozwiązaniem jest pozbycie się kontroli w formie DAC, czyli tym samym:
- przypisanie do każdego procesu/programu/użytkownika odpowiedniego kontekstu lub roli, z którym on będzie pracował;
- przypisanie do każdego obiektu w systemie praw na jakich mogą go używać inne obiekty/procesy;
- założenie, że na co się explicite nie pozwala, to się to zabrania;
- założenie, że twórca pliku nie ma mieć domyślnych pełnych praw zarządzania nim (z tak małej zmiany tak naprawdę sporo wynika);
- założenie, że root nie jest “lepszym” kontem od innych i nie powinien mieć jakiś wybitnych przywilejów tylko z powodu posiadania dwóch liter ‘o’ w nazwie (mówiąc dobitniej - założenie, że na roota ktoś się włamał);
Listę tego typu implementuje MAC (Mandatory Access Control) i RBAC (Role-Based Access Control) - teoretycznie różne rodzaje kontroli dostępu, ale tak naprawdę mocno o siebie zahaczające (porównaj nieścisłości w definicji w Wikipedii).
Hardened Gentoo wspiera trzy takie linuksowe rozwiązania: SELinux, RSBAC i Grsecurity. Na którym z nich poległem i które udało mi się wdrożyć opowiem w następnej części :).
Literatura:
Wysłano w Blog - Linux i Unix | Tags: bezpieczeństwo, linux | 
