Teoria a praktyka

2008-04-02

W świecie technologii często zdarza się, że względy inne niż czysto
merytoryczne decydują o tym, która technologia się upowszechni.

Miałem okazję ostatnio porównać ze sobą dwa mechanizmy zabezpieczeń
systemu Linux: SELinux (Security-Enhanced Linux) i AppArmor. Oba
przedstawiane są jako pełnoprawne rozwiązanie kontroli dostępu.

Systemy UNIX tradycyjnie opierają się na nieskomplikowanej kontroli praw
dostępu: każdy element w systemie plików ma prawa dostępu dla
użytkownika, grupy oraz wszystkich pozostałych. Nie zawsze to jednak
wystarcza -- z powodu częstych problemów z bezpieczeństwem
poszczególnych aplikacji, często potrzebne jest ograniczenie praw
dostępu konkretnym programom wyłącznie do niezbędnych dla nich plików,
czy urządzeń w systemie. Co ważniejsze, istotnym problemem w systemach
UNIX jest wszechmocny administrator (root), który ma nieograniczony
dostęp do wszystkiego.

Mechanizmy MAC (Mandatory Access Control) pozwalają na ograniczenie praw
dostępu. Poprzez zdefiniowanie polityki bezpieczeństwa można pozwolić
konkretnym aplikacjom na dostęp do konkretnych elementów systemu,
niezbędnych im do pracy. Co więcej, możliwe jest zdefiniowanie takiej
polityki bezpieczeństwa, w której nie ma wszechmocnego administratora, a
zmiana polityki bezpieczeństwa nie jest możliwa bez restartu systemu i
fizycznego dostępu do niego. Dla systemu Linux powstały dwa mechanizmy
typu MAC: SELinux i AppArmor.

SELinux jest rozwiązaniem nieco starszym. Początkowo opracowane w NSA
(National Security Agency), zostało szybko przyjęte m.in. przez Red Hata
jako rozwiązanie bezpieczeństwa dla systemów Red Hat Enterprise
Linux. Pozwala na zdefiniowanie kompletnej polityki bezpieczeństwa dla
całego systemu i całkowite wzajemne odizolowanie od siebie aplikacji.

AppArmor to alternatywne rozwiązanie, opracowane w firmie Immunix, a
następnie rozwinięte przez Novella. Cele są tu nieco inne niż dla
SELinux: AppArmor służy do chronienia systemu przed konkretnymi
zagrożeniami, ze strony konkretnych aplikacji. Z założenia niewielka
część programów w systemie będzie miała zdefiniowane profile
bezpieczeństwa. Będą to na ogół programy mające kontakt ze światem
zewnętrznym, takie jak np. serwisy sieciowe.

Najbardziej zaognionym punktem spornym w dyskusjach na temat wyższości
jednego rozwiązania nad drugim jest ich podejście do oznaczania plików w
systemie. SELinux operuje na i-węzłach -- odpowiednio oznaczonej
konkretnej zawartości w systemie plików. AppArmor używa tradycyjnych
ścieżek dostępu.

Zwolennicy SELinux twierdzą, że używanie ścieżek dostępu nie zapewnia
odpowiedniego bezpieczeństwa. Można przecież tworzyć dowiązania (hard
links), manipulować przestrzenią nazw systemu plików, czy podmieniać
zawartość plików. W końcu ścieżka do pliku to wyłącznie wskazanie --
"plik, który znajduje się pod tym adresem", nie zaś sama zawartość
pliku. Dlatego SELinux wymaga oznaczania i-węzłów, czyli konkretnej
zawartości, za pomocą specjalnych metek. Do nich później odwołuje się
polityka bezpieczeństwa.

Entuzjaści AppArmor odpowiadają na to: racja, ścieżki dostępu mają swoje
wady. Są za to nieskomplikowane, intuicyjne w użyciu, a wszyscy są do
nich przyzwyczajeni. Politykę bezpieczeństwa tworzy się więc łatwo.

Trudno jest porównać ze sobą mechanizmy, które w założeniach mają
spełniać różne role. W praktyce jednak często staje się przed wyborem,
którego z nich użyć.

Teoretycznie SELinux jest rozwiązaniem technologicznie lepszym. Pozwala
na zdefiniowanie kompletnej polityki bezpieczeństwa, odseparowanie od
siebie przepływów danych, zabezpieczenie całego systemu. Definiowanie
dostępu do konkretnych i-węzłów zabezpiecza system przed wieloma
rodzajami ataków. Są też jednak minusy: i-węzły w systemie plików trzeba
oznaczyć i pilnować, by pozostały oznaczone. Trudniej jest robić kopie
bezpieczeństwa, bo trzeba dbać o zachowanie metadanych. Politykę
bezpieczeństwa definiuje się też trudno.

W praktyce więc AppArmor, pomimo że ma mniejsze możliwości, może się
okazać znacznie lepszym rozwiązaniem. W wielu zastosowaniach lepiej mieć
dobrze wdrożony i działający AppArmor dla ograniczonej liczby aplikacji,
niż nie do końca zaimplementowany SELinux dla całego systemu.

Dochodząc do tytułu tego artykułu: w teorii SELinux jest rozwiązaniem
bardziej zaawansowanym technologicznie, ale w praktyce AppArmor spisuje
się lepiej. Wystarczającym powodem jest tu trudność użycia: są znacznie
większe szanse, że administrator poprawnie zdefiniuje profile
bezpieczeństwa w AppArmor, niż że zrobi to dobrze dla SELinux, a nawet
najlepsze technologicznie rozwiązanie przy źle zdefiniowanej polityce
bezpieczeństwa nie zabezpieczy systemu.