AppArmor – jak dozbroić Linuksa?

Ostatnia afera z dziurą w zabezpieczeniach Firefoksa wywołała lawinę standardowych komentarzy (w typie sarkazmu lub biadolenia), również w odniesieniu do bezpieczeństwa Linuksa. Otóż exploit pozwalał na przejrzenie pliku /etc/passwd, w którym są nazwy grup i użytkowników (nazwa jest myląca, zaszyfrowane hasła znajdują się w /etc/shadow, który jest zabezpieczony przed nieautoryzowanym podglądem). Oprócz tego miał możliwość przejrzeć ostatnie polecenia wydane w terminalu (.bash_history) oraz próbował dobrać się do plików konfiguracyjnych. W sumie, mógł zdziałać niewiele, ze względu na standardowy system zabezpieczeń, czyli...

DAC

...discretionary access control, czyli metodę zabezpieczania, polegającą na przypisywaniu konkretnym podmiotom (właściciel, grupa, inni) konkretnych uprawnień. Tylko właściciel ma pełną kontrolę nad swoimi plikami. Dlatego właśnie exploit nie mógł na przykład ani przejrzeć, ani skopiować pliku z zaszyfrowanymi hasłami:

jakub@Altsin:~$ cat /etc/shadow
cat: /etc/shadow: Brak dostępu
jakub@Altsin:~$ cp /etc/shadow ~
cp: nie można otworzyć „/etc/shadow” do czytania: Brak dostępu

O ile, rzecz jasna, ktoś nie uruchomił przeglądarki jako root, ale wtedy żadne zabezpieczenie nie pomoże, ponieważ na bezmyślność nie ma lekarstwa. To jednak nie wszystko, ponieważ Linuksy mają również inne standardowe zabezpieczenia wbudowane w kernel, na przykład...

MAC

...czyli mandatory access control - metoda zabezpieczenia, która jawnie określa, które funkcje są dostępne dla danych programów. W Linuksach dwiema głównymi implementacjami tego systemu są SElinux i AppArmor. W Ubuntu domyślnie używany jest ten drugi. Od razu po świeżej instalacji system posiada uruchomiony AppArmor z zestawem podstawowych reguł dla kilku kluczowych programów. Można to sprawdzić:

sudo /etc/init.d/apparmor status

Co ważne, Firefoksa NIE MA NA TEJ LIŚCIE. Można zapytać dlaczego, ale odpowiedzi mogliby udzielić tylko deweloperzy. Żeby się przekonać, które aplikacje podlegają dodatkowej kontroli należy wpisać:

sudo aa-status

.Instalacja zestawu reguł dla Firefoksa jest bardzo prosta.Po pierwsze należy zainstalować apparmor-utlis.

sudo apt-get install apparmor-utils

lub - dla tych, którzy chcą więcej zestawów reguł i narzędzi

sudo apt-get install apparmor-*

Apparmor utils pozwala na łatwą instalację prekonfigurowanych pakietów. Ale o tym za chwilę, najpierw trzeba się zdecydować czy...

Marudzić czy działać?

Apparmor może działać w dwóch trybach:

[list] [item]complain - naruszenia bezpieczeństwa nie blokowane, ale są zbierane w postaci logów[/item][item]enforced - naruszenia bezpieczeństwa są blokowane[/item]Wydaje się, że warto od razu walnąć z grubej rury i używać trybu enforced, w razie czego utrudniającą nam życie regułę będzie można przełączyć w tryb complain.

Dodanie Firefoksa do AppArmor

Mając już zainstalowane apparmor-utils (warto również zainstalować apparmor-profiles i apparmor-profiles-extra), wystarczy, że wpiszemy w terminalu

sudo aa-enforce /etc/apparmor.d/usr.bin.firefox

Można też dla bezpieczeństwa odpalić wszystykie profile:

sudo aa-enforce /etc/apparmor.d/*

W razie gdyby któraś z aplikacji nie działała tak, jakbyśmy sobie tego życzyli można ją przełączyć w tryb complain:

sudo aa-complain nazwa_aplikacji_lub_ścieżka

Ale o co chodzi?

Właściwie jaka z tego wszystkiego korzyść? AppArmor: Zezwala aplikacji na robienie jedynie tego, do czego przyznano jest dostęp i zabronieniu wszystkiego innego. Podręcznikowy przykład. W domowym katalogu utworzę skrypt o wdzięcznej nazwie blekot. Oto jego kod:

jakub@Altsin:~$ cat blekot 
#!/bin/bash
echo "Hello World!" > /tmp/hello.txt
cat /tmp/hello.txt
rm /tmp/hello.txt

Jak widać skrypt ma proste działanie: 1. Wyświetla tekst "Hello World!", ale tekst zamiast zostać wyświetlony na ekranie, zostaje przekierowany do pliku /tmp/hello.txt, co tworzy nowy plik i zapisuje w nim tekst. 2. Wyświetla zawartość pliku /tmp/hello.txt 3. Usuwa rzeczony plik. Dodajmy uprawnienia do wykonania:

chmod +x blekot

i wykonajmy plik:

jakub@Altsin:~$ ./blekot
Hello World!

Skrypt jak widać zadziałał. W logach systemowych nie pozostanie nawet ślad po naszym "przestępczym" działaniu. Stwórzmy teraz najprostszą regułę nie zezwalająca na nic, specjalnie dla naszego skryptu. W katalogu /etc/apparmor.d stworzymy (jako root) plik home.jakub.blekot o następującej zawartości:

/home/jakub/blekot {}

Plik jest pusty, a więc nie pozwalamy temu skryptowi na wykonanie czegokolwiek. Po uruchomieniu widzimy następujący komunikat:

jakub@Altsin:~$ ./blekot
/bin/bash: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory

Ojoj, coś poszło nie tak i nasz super hakerski skrypt nie został odpalony... Sprawdzamy co słychać w logach odnośnie naszej "aplikacji":

cat /var/log/syslog | grep blekot
Aug  8 21:05:19 Altsin kernel: [ 9867.298928] audit: type=1400 audit(1439060719.833:240): apparmor="DENIED" operation="open" profile="/home/jakub/blekot" name="/lib/x86_64-linux-gnu/libtinfo.so.5.9" pid=8939 comm="blekot" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

Całe zdarzenie zostało zapisane. Spróbujmy teraz przełączyć profil na tryb complain:

jakub@Altsin:~$ sudo aa-complain /home/jakub/blekot
Setting /home/jakub/blekot to complain mode.

Co ciekawe, zmienił się automagicznie nasz profil:

/home/jakub/blekot flags=(complain) {
}

Próbujemy wykonać nasz skrypt:

jakub@Altsin:~$ ./blekot 
Hello World!

Działa! A co słychać w logach?

cat /var/log/syslog | grep blekot
Aug  8 21:10:15 Altsin kernel: [10163.197508] audit: type=1400 audit(1439061015.432:250): apparmor="ALLOWED" operation="open" profile="/home/jakub/blekot" name="/home/jakub/blekot" pid=8974 comm="blekot" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1

Skrypt został wykonany, ale AppArmor dzielnie zanotował w systemowych logach jego uruchomienie.

Czyli właściwie co robi AppArmor?

Jak wymienia Christian Boltz, jeden z deweloperów OpenSuse, AppArmor monitoruje i ogranicza:

• dostęp do plików
• dostęp do sieci
• wykonanie zadań, tzw. linux capabilities (chown, setuid, itp)

Natomiast w żaden sposób nie zmienia zasad wymienionych wyżej DAC, dlatego jeżeli wszystkie pliki w naszym systemie mają flagi 777 albo siedzimy na koncie roota, AppArmor w niczym nie pomoże.

Podsumowanie

AppArmor nie obroni nas przed wszystkimi możliwymi exploitami, ale na pewno system jest bardziej bezpieczny z włączonym AppArmorem, niż bez niego. Ponieważ do wielu programów (przeglądarka internetowa, czytnik PDF, komunikatory) mamy gotowe profile, nie potrzeba z naszej strony żadnego wysiłku. Zasada optymalizacji wysiłku w stosunku do oczekiwanych rezultatów jest zatem po naszej stronie :‑)