Artykuł pochodzi z wydania: Marzec 2022
Mechanizmy rozszerzające bezpieczeństwo w systemach Linux skoncentrowały się głównie na dwóch wiodących rozwiązaniach, tworząc polaryzujący obraz sytuacji. SELinux w dystrybucjach RedHata i AppArmor w dystrybucjach Debiana.
Rozszerzona kontrola w systemie Linux, o której traktuje ten artykuł, definiowana jest mechanizmem MAC (ang. Mandatory Access Control). Pierwotnie systemy Unix, bo przecież ich kopią są dystrybucje Linuksa, oferowały podstawowy mechanizm należący do grupy DAC (ang. Discretionary Access Control). Porównując te dwa typy kontroli w najprostszy sposób, możemy stwierdzić, że DAC funkcjonuje na bardzo wąskiej grupie danych i nie uwzględnia kontekstu. Z kolei MAC podejmuje decyzję na zdecydowanie większej grupie danych, które uwzględniają kontekst. Najprostszym przykładem takiego kontekstu jest demon, np. syslog działający z uprawnieniami superużytkownika – root. Taki proces nie powinien dokonywać zmian w plikach znajdujących się w katalogach domowych zwykłych użytkowników (/home/). Problem polega na tym, że może!
Taki demon zazwyczaj pracuje również sieciowo, a to stwarza niezerowe prawdopodobieństwo, że zostanie w nim odkryta jakaś podatność. Tu pojawia się zasadniczy problem – proces działający z UID równym 0 nie będzie zablokowany, jeżeli zechce uruchomić program /bin/bash z jego podstawowymi uprawnieniami -rwxr-xr-x. Jednak nie jest to nowy problem. Jego rozwiązań jest sporo, na dodatek są rozwijane już wiele ponad 20 lat. Podobnie AppArmor to projekt, który powstał już w 1998 r., a jego główny rywal – SELinux – powstał w 2000 r.
> Koncepcja AppArmor
Główną rolą mechanizmu typu MAC jest badanie kontekstu, w jakim działa kontrolowany proces. Wracając do naszego przykładu z demonem syslog, teraz już wiemy, że jego zadaniem jest sprawdzać, czy syslog działający z uprawnieniami użytkownika root rzeczywiście robi tylko to, co powinien. Można się domyślić, że prawidłowych rozwiązań takiego zadania może być kilka. Jednak każde z nich i tak musi współpracować z tymi samymi częściami jądra systemu, którymi są funkcje systemowe (syscall). Aby uniknąć bałaganu i umożliwić implementację wielu rozwiązań mechanizmu MAC, powstał mechanizm jądra LSM (ang. Linux Security Modules).
Linux ma również mechanizm zwany ACL rozszerzający podstawowe uprawnienia dla systemu plików. Jego realizacja wymagała dodania do metadanych każdego obiektu w systemie plików rozszerzonych atrybutów (xattr). Jednak to nadal nie był MAC, lecz co najwyżej rozszerzony DAC. Przykład ten został podany nie bez powodu, gdyż prezentuje on kierunek, którym mogli kierować się twórcy AppArmor. Niemal cała kontrola miała być określana w relacji do systemu plików, z tym że AppArmor w tym celu używa wirtualnego systemu plików securityfs, który jest mapowany w /sys/kernel/security.
Z kolei twórcy SELinux podeszli do problemu zdecydowanie restrykcyjnie i metodycznie. Wynika to zapewne z bardzo prostej przyczyny – autorami SELinux byli naukowcy. Jaka jest więc różnica? Jak wiadomo, w systemach Unix wszystko jest plikiem. Jest to niezaprzeczalny fakt obecny w całej historii tych systemów. SELinux również kontroluje przeważnie pliki, jednak on identyfikuje je poprzez ich niepowtarzalny numer inode, a AppArmor do określania plików używa przyjaznych ludziom ścieżek. Przytoczony przykład wskazuje, jaka była główna intencja twórców AppArmor – miał być możliwie prosty. I taki jest.
SELinux obecnie jest najbardziej zaawansowaną implementacją mechanizmu MAC, z czego wynika jeden problem – to bardzo złożony mechanizm, co w efekcie wymaga dużo pracy w jego utrzymaniu od administratora. Niestety fakt ten zaważył na wyborze rozwiązania typu MAC do obecnie najpopularniejszej dystrybucji systemu Linux, jaką jest Ubuntu.Jednak każdy kij ma dwa końce. Okazało się, że prostota została osiągnięta kosztem możliwości. Zatem po tym, jak AppArmor trafia do Ubuntu w 2007 r., zaczyna przechodzić lekką metamorfozę. W 2009 r. Canonical przejmuje projekt od Novella i stara się z niego zrobić poważną alternatywę dla SELinuksa. Dodawanie nowych funkcji z programistycznego punktu widzenia nie stanowi problemu, trudniej z połączeniem ich z ideą ścieżek w systemie plików. W taki oto sposób suwak pomiędzy prostotą a funkcjonalnością zaczyna zbliżać się w stronę tej drugiej.
[…]
Grzegorz Kuczyński
Autor zawodowo zajmuje się informatyką. Jest członkiem społeczności open source, prowadzi blog na temat systemu GNU/Linux.
