Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.



12.05.2022

Odszyfrowanie historii

Z inicjatywy prezesa IPN, dr. Karola Nawrockiego, powstało Biuro Nowych Technologii. Jego...
01.04.2022

Program partnerski

NGAGEFirma NFON, ogólnoeuropejski dostawca komunikacji głosowej w chmurze, ogłosił...
01.04.2022

SI w TFI PZU

Na platformie do inwestowania inPZU działa już nowa metoda identyfikacji tożsamości...
01.04.2022

Kooperacja w chmurze

To oparta na stworzonej przez NetApp technologii ONTAP i w pełni zarządzana przez...
01.04.2022

Nowe laptopy od Dynabook

Dynabook wprowadza do swojej oferty dwa laptopy z procesorami Intel Core 12. generacji,...
01.04.2022

Ryzen do stacji roboczych

AMD przedstawił nową gamę procesorów Ryzen Threadripper PRO 5000 serii WX.
31.03.2022

Serwery dla MŚP

Firma Lenovo wprowadziła nowe rozwiązania w zakresie infrastruktury IT Future Ready,...
31.03.2022

Innowacyjny kontroler SSD

Microchip zaprezentował nowe kontrolery SSD, które umożliwią obsługę napędów o pojemności...
31.03.2022

Wydajny jak Brother

Brother dodał do swojej oferty trzy nowe, atramentowe urządzenia wielofunkcyjne, które...

AppArmor w Debian GNU/Linux

Data publikacji: 03-03-2022 Autor: Grzegorz Kuczyński

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 super­uż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 upra­wnienia 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.


> Integracja


Obecnie aktualną, stabilną wersją dystrybucji Debiana jest wersja 11 (o nazwie kodowej „bullseye”), ale AppArmor został już zintegrowany ze wcześniejszą jej wersją, więc w przypadku instalacji wspomnianego builda Debiana AppArmor będzie już wstępnie skonfigurowany i uruchomiony. Mimo to przytoczymy tu kilka szczegółów technicznych tej integracji.


Po pierwsze, AppArmor jako mechanizm kontrolujący, czy dany proces systemu może wywołać określoną funkcję systemową z konkretnymi parametrami, jest integralną częścią jądra systemu Linux. Nie znajdziemy żadnego modułu jądra tego mechanizmu. Co więcej nie znajdziemy nawet zdefiniowanej opcji uruchomienia kernela security=apparmor. Wynika to z faktu, że w momencie kompilacji jądra ustawiane są flagi, które nakazują mu dodać do niego kod AppArmor. Tak samo za pomocą oddzielnych flag domyślnie do jądra dodawane są następujące parametry, których nie potrzeba wpisywać jako argumentów.

 

Aby wyłączyć AppArmor na poziomie jądra systemu, musimy jawnie dodać następujące parametry, które nadpiszą te skompilowane w jądrze: apparmor=1 security=apparmor. Oczywiście kontrolę AppArmor nad systemem możemy wyłączyć w o wiele prostszy sposób za pomocą jego narzędzi konfiguracyjnych lub systemowych. Na poziomie systemu możemy zarządzać AppArmor jak zwykłą usługą:


# systemctl disable apparmor.service


Podejście to wymaga ponownego uruchomienia systemu. Oba przedstawione do tej pory rozwiązania w rzeczywistości nie powodują wyłączenia mechanizmu AppArmor, lecz nie ładują jego polityk bezpieczeństwa – profili.


> Narzędzia


Wraz z systemem operacyjnym instalowana jest tylko niezbędna liczba paczek dla AppArmor. Poniżej prezentujemy, które paczki należy jeszcze doinstalować, aby móc w pełni zarządzać jego mechanizmami:


# apt install apparmor-utils apparmor-profiles auditd


Pierwsza z nich zawiera dodatkowe narzędzia pozwalające głównie na wprowadzanie zmian w konfiguracji. Druga zawiera dodatkowy zestaw profili służących do ograniczania konkretnych aplikacji. Profile są również dostarczane wraz z aplikacjami, tzn. paczka danego programu zawiera jego profil AppArmor. Ostatnia paczka instaluje demona logowania zdarzeń bezpieczeństwa w systemie Linux.


> Tryby działania


Jeżeli dany profil ma być uruchamiany przy starcie systemu, to jest on kopiowany do katalogu /etc/apparmor.d/. W przypadku gdy chcemy wyłączyć ładowanie profilu, który się tam znajduje, możemy to zrobić poprzez stworzenie linku symbolicznego do niego w katalogu /etc/apparmor.d/disable/. Pozostałe profile zostaną załadowane w jednym z dwóch trybów – complain i enforce. To, który z nich zostanie wybrany, określa polityka zapisana w profilu.


Tryb complain jest przeznaczony do wdrażania nowych profili. Możemy wtedy przetestować, czy polityka w nim określona rzeczywiście opisuje wszystkie działania niezbędne do prawidłowej pracy danego procesu. Działania, na które profil nie zezwala, będą tylko logowane. Wyjątkiem są jawne reguły blokujące – reguły deny.


Tryb enforce zezwala tylko na to, co określa polityka w profilu, reszta działań jest bezwzględnie blokowana i logowana. Jest to docelowy tryb dla procesów, które mamy już dobrze przetestowane.


> Zarządzanie profilami


Podstawowym narzędziem, z którego dowiemy się, jakie profile są załadowane, jakie używane i w jakich trybach działają, jest aa-status:


# aa-status
apparmor module is loaded.
32 profiles are loaded.
15 profiles are in enforce mode.
...
17 profiles are in complain mode.
...
6 processes have profiles defined.
0 processes are in enforce mode.
6 processes are in complain mode.
...
0 processes are unconfined but have a profile defined.


Trzy pierwsze pozycje dotyczą tego, jakie profile zostały załadowane. Kolejne trzy pokazują, ile z nich rzeczywiście w danym momencie jest używanych i w jakich trybach. Ostatnia, siódma pozycja informuje o tym, czy jakiś proces nie jest chroniony, mimo że istnieje dla niego profil. Taka sytuacja może mieć miejsce, jeżeli AppArmor zostanie zresetowany podczas pracy chronionych aplikacji lub zostaną dodane nowe profile podczas pracy demona.

 

(...)

 

Autor zawodowo zajmuje się informatyką. Jest członkiem społeczności open source, prowadzi blog na temat systemu GNU/Linux.

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

prenumerata Numer niedostępny Spis treści

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"