AppArmor – jak dozbroić Linuksa?
08.08.2015 | aktual.: 09.08.2015 11:59
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 :‑)
