apparmor

Jak załadować profile AppArmor w fazie initrd/initramfs na Debian Linux

Zapewne wielu użytkowników Debiana zdążyło już zauważyć, że od wydania 10 (Buster), AppArmor jest włączony domyślnie. Nie powinien on raczej sprawiać żadnych problemów po doinstalowaniu pakietów apparmor-profiles oraz apparmor-profiles-extra , które zawierają szereg profili pod różne aplikacje użytkowe. Niemniej jednak, pewnych procesów nie da się ograniczyć przez AppArmor, przynajmniej nie w standardowy sposób. Chodzi o to, że jeśli mamy już odpalony jakiś proces, to nie ma możliwości zamknąć go w profilu AA do momentu aż zakończy on swoje działanie i zostanie uruchomiony ponownie. Profile AppArmor'a są ładowane podczas startu systemu w pewnym określonym momencie ale szereg procesów systemowych startuje sporo wcześniej w stosunku do usługi AppArmor'a. W taki sposób nawet jeśli w późniejszym czasie profile zostaną załadowane, to i tak część procesów nie będzie ograniczona bez względu na to czy zdefiniowaliśmy im zestaw reguł. Oczywiście można próbować restartować usługi lub szeregować je po apparmor.service ale nie zawsze tak się da zrobić. Alternatywnym rozwiązaniem tego problemu jest ładowanie polityki AppArmor'a w fazie initrd/initramfs, czyli w momencie, w którym nasz system nie ma jeszcze nawet uruchomionego procesu z PID z numerkiem 1 .

Capability dac_read_search i dac_override w profilu AppArmor'a

Od jakiegoś czasu tworzę dla aplikacji w moim Debianie profile pod AppArmor, tak by ograniczyć programom swobodny dostęp do plików czy urządzeń. Tych profili zebrało się już trochę i podczas pisania jednego z nich, zacząłem się zastanawiać czy wszystkie CAP'y (linux capabilities), których żądają procesy, są im faktycznie niezbędne do prawidłowego funkcjonowania. Chodzi póki co o dac_read_search i dac_override . Co ciekawe, odmowa dac_override w części aplikacji nie powodowała żadnych negatywnych konsekwencji. Idąc dalej tym tropem, postanowiłem z paru profili AA usunąć linijkę zawierającą capability dac_override, zostawiając tym samym jedynie capability dac_read_search, i zobaczyć co się stanie. Okazało się, że sporo programów już o dac_override nie prosi. Zatem co się zmieniło przez tych parę lat i czy ta zmiana dotyczy samych aplikacji, a może kernela linux'a?

Mechanizm trigger'ów dla apt/aptitude w Debianie

Czasami pewna niestandardowa konfiguracja naszego linux'a może sprawiać pewne problemy podczas aktualizacji zainstalowanych w nim pakietów. Dla przykładu, wykorzystując mechanizm AppArmor do okrojenia profilów Firefox'a, muszę tworzyć osobne twarde dowiązania do binarki tej przeglądarki. Te dowiązania mają taki problem, że jak usunie się plik, na który wskazywały, np. podczas aktualizacji paczki, to utworzenie pliku w tym samym miejscu przez menadżer pakietów apt/aptitude nie sprawi, że te dowiązania zaczną ponownie funkcjonować poprawnie (tak jak to jest w przypadku dowiązań symbolicznych). Z początku usuwałem te stare dowiązania i tworzyłem nowe ale postanowiłem w końcu poszukać rozwiązania, które by zautomatyzowało cały ten proces i uczyniło go transparentnym dla użytkownika końcowego. Tak natrafiłem na mechanizm Debianowych trigger'ów (deb-trigger), które aktywują się za każdym razem ilekroć pliki w konkretnych ścieżkach są ruszane w jakiś sposób przez menadżer pakietów. W tym artykule spróbujemy sobie zaprojektować taki trigger i obadać czy może on nam się w ogóle do czegoś przydać

Profil AppArmor'a i jego dokładna budowa

Budowanie samych profili dla AppArmor'a nie jest jakoś szczególnie trudne, zwłaszcza, gdy do tego celu wykorzystujemy narzędzia dostępne w pakiecie apparmor-utils . Dobrze jest jednak prześledzić sobie manual AppArmor'a oraz to, co twórcy piszą na swojej stronie w oficjalnej dokumentacji projektu. Poniższy wpis powstał w celu zrozumienia składni profili AppArmor'a, tak by jeszcze bardziej uprościć proces ich budowania.

Opis składni znajdujący się poniżej został zaczerpnięty z wiki AppArmor'a. Część z poniższych informacji może nie mieć zastosowania w przypadku starszych wersji samego AppArmor'a.

AppArmor i profilowanie aplikacji

Po ostatnich doniesieniach na temat błędu jaki został znaleziony w Firefox'ie , doszedłem do wniosku, że najwyższy czas nauczyć się obsługi narzędzia AppArmor . Ma ono pomóc w kontrolowaniu praw dostępu do zasobów systemu operacyjnego, np. plików, katalogów czy określonych urządzeń. Jeśli weźmiemy przytoczony wyżej błąd, to przeglądarka bez takiego profilu AppArmor'a była w stanie przeszukać lokalne pliki i wysłać je gdzieś na net, co powodowałoby udostępnienie poufnych danych, np. historia poleceń shell'owych, czy klucze prywatne.