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 .

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?

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.

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.