1 Szczyrk, 11-13 października 2013 Smack - prosta alternatywa dla SELinux Rafał Krypa
2
Smack
• Simplified Mandatory Access Control in Kernel
• Autor i maintainer: Casey Schaufler [email protected]
• Strona internetowa http://schaufler-ca.com/
• Pierwsza wersja: 17 kwietnia 2008
3
Mandatory Access Control (MAC)
• Kontrola dostępu zarządzana centralną polityką systemu
• Tylko administrator może konfigurować politykę i atrybuty
bezpieczeństwa
• Podmiot (subject) – element wykonujący dostęp: proces, wątek,
użytkownik
• Obiekt (object) – element do którego dostaje się podmiot
• Dostęp (access) – rodzaj dostępu, akcja
• MAC vs. DAC (Discretionary Access Control)
• “Separation is easy, sharing is diffcult”
4
Linux Security Module (LSM)
• Warstwa abstrakcji dla podsystemów bezpieczeństwa w jądrze
Linuksa
• Moduł dostarcza wskaźniki do funkcji, które weryfikują dostęp
• Utworzony, gdyż Linus Torvalds nie chciał wybrać „jedynego
słusznego” podsystemu bezpieczeństwa
• Przez pewien czas SELinux jako jedyny używał tego API
• Kolejne moduły LSM: Smack, TOMOYO, AppArmor, Yama
• Proponowano obsługę stackowania kilku modułów LSM
5
Który moduł bezpieczeństwa jest najlepszy?
If you guys had been able to argue on hard data and be in
agreement, LSM wouldn't have been needed in the first place.
When I see the security people making sane arguments and
agreeing on something, that will change. Quite frankly, I expect
hell to freeze over before that happens, and pigs will be nesting in
trees. But hey, I can hope.
Linus Torvalds
6
Dlaczego powstał Smack – słowami autora
• I respect the design decisions that SELinux has made regarding
granularity without agreeing with them myself.
• My understanding of the current SELinux philosophy is that policy
should only be written by professionals (…). For policy that requires
the level of sophistication that SELinux does I would have a hard
time arguing otherwise.
• I am interested in seeing what an SELinux policy to do what Smack
does would look like. I personally though it would be easier to write
an LSM than to write that policy.
7
Zasady działania
• Subject – proces (nie wątek)
• Object – obiekt systemu plików, inny proces
• Każdy subject i object identyfikowany etykietą
• Napis ASCII do 255 znaków (wcześniej 23)
• Kilka etykiet wbudowanych
• Access: standardowe typy uprawnień: R, W, X, A (append) oraz
T (transmute)
• Rule – reguła definiująca prawa dostępu danego podmiotu do
obiektu. Dla każdej pary (subject, object) najwyżej jedna.
9
Reguły użytkownika
• Reguły wpisywane do /smack/load2 (ulotne)
• Pliki konfiguracyjne w /etc/smack/accesses.d/
• Ładowane przy starcie przez program smackload
• Przykładowe reguły:
TopSecret Secret rx
Secret Unclass R
Manager Game x
User HR w
New Old rRrRr
Closed Off -
10
Jaki to rodzaj dostępu?
• Przykłady:
• kill() – zapis
• sendmsg() – zapis (druga strona nie potrzebuje odczytu)
• ptrace() – odczyt i zapis
• flock() – zapis (wymiana informacji?)
• rename() – odczyt i zapis do katalogu źródłowego i docelowego
• bind() – nic
• Use the source, Luke!
• security/smack/smack_lsm.c
11
Skąd się biorą etykiety
• Proces init otrzymuję etykietę _ (floor)
• Proces potomny otrzymuje etykietę taką jak rodzic
• Proces uprzywilejowany może zmienić swoją (tylko) etykietę
• Etykieta procesu dostępna w /proc/PID/attr/current
• Dla plików i katalogów zapisane w rozszerzonych atrybutach
(security.SMACK64 xattr)
• Każdy nowy plik otrzymuję etykietę procesu, który go utworzył
• Dla komunikacji sieciowej etykiety przesyłane jako opcja IP
(CIPSO (ab)use)
• Smack trzyma w pamięci wszystkie etykiety, które napotkał
12
Przejścia etykiet
• Dostępne od kernela 2.6.38
• Zmiana etykiety procesu w przypadku execve()
• Gdy wykonywany program ma atrybut security.SMACK64EXEC
• Zmiana etykiety pliku utworzonego w specjalnym katalogu
• Gdy katalog ma atrybut security.SMACK64TRANSMUTE
• Wartość „TRUE” (!!)
• Nowy plik otrzyma etykietę katalogu, a nie procesu
• Tworzący proces musi mieć uprawnienie transmute na katalogu
13
Co może root
• POSIX capabilities
• Uprawnienie CAP_MAC_OVERRIDE pozwala obchodzić politykę
• Uprawnienie CAP_MAC_ADMIN pozwala konfigurować politykę
(pośrednio także obchodzić)
• Domyślnie root nie jest ograniczany
• Użycie /smack/onlycap (kernel >= 2.6.28)
• Wpisanie specjalnej etykiety do tego pliku
• Tylko procesy z tą etykietą mogą korzystać z CAP_MAC_OVERRIDE i
CAP_MAC_ADMIN
• Bug kernel < 3.8
14
Logi
• Konfiguracja w /smack/logging
• Maska dwóch bitów, logowanie odmów (1) i zezwoleń (2)
• Domyślnie loguje odmowy
• Logi trafiają w podsystem audit, domyślnie dostępne w dmesg
audit(1239127909.223:22): lsm=SMACK
fn=smack_inode_permission action=denied
subject="FOO" object="_" requested=wx pid=6699
comm="rm" name="etienne" dev=sda8 ino=1236993
15
Jak zacząć (1)
• Wersja kernela >= 2.6.25 (rekomendowana przynajmniej 3.5)
• Konfiguracja kernela
• CONFIG_SECURITY
• CONFIG_NETLABEL (kernel < 3.8)
• CONFIG_SECURITY_NETWORK (kernel < 3.8)
• CONFIG_SMACK
• System działa z domyślną polityką i etykietami
16
Jak zacząć (2)
• Pseudo system plików do konfiguracji (smackfs)
• mount -t smackfs smackfs /smack (kernel < 3.8)
• mount -t smackfs smackfs /sys/fs/smack (kernel >= 3.8)
• Smack userspace (https://github.com/smack-team/smack)
• libsmack, smack-utils, skrypty startowe
• Konfiguracja w /etc/smack
• Skrypt startowy montuje smackfs i ładuje reguły z plików
• Biblioteka libsmack do konfiguracji z poziomu C/C++
• Systemd natywnie obsługuje Smacka od wersji 198
• Montuje smackfs i ładuje reguły (własna implementacja systemd)
17
Interfejs jądra
• /smack/load, /smack/load2
• Zapis reguł w postaci <SUBJECT> <OBJECT> <ACCESS>
• Odczyt pełnej polityki (wszystkich reguł)
• /smack/access, /smack/access2
• Zapytania o dostęp z przestrzeni użytkownika, format jak /smack/load
• /smack/change-rule
• Zmiana reguły zamiast nadpisywania
• Format <SUBJECT> <OBJECT> <ACCESS_ADD> <ACCESS_DEL>
• /smack/logging, /smack/onlycap, inne
• → Documentation/security/Smack.txt
18
Problemy, pułapki
• SQLite i blokady plików
• Program potrzebuje bazy tylko do odczytu
• SQLite zakłada blokadę dla zapewnienia spójności
• Smack traktuje blokady jak zapis
• Proponowany nowy poziom dostępu – L (lock)
• Ptrace i SMACK64EXEC
• Nie można śledzić procesu z inną etykietą
• Nawet root nie może
• Smack nic nie loguje
• Workaround, poprawka logowania w jądrze
19
Wydajność
• Etykiety i reguły nigdy nie usuwane z pamięci
• Struktura danych – skierowana lista (dwupoziomowa)
• Wydajność sprawdzania dostępu poprawiana jądrze 3.2 i 3.11
• Ładowanie reguł do systemu w postaci tekstowej
• Wydajność ładowania poprawiona w jądrze 3.12
• Brak znanych problemów wydajnościowych w tej chwili
• Maintainer otwarty na dalsze optymalizacje
20
Tworzenie polityki
Zachowanie aplikacji pokryte przez politykę
Potencjalne niedziałanie
aplikacji
Potencjalne naruszenia
bezpieczeństwa
21
Tworzenie polityki dla zmieniającego się systemu
• Analiza statyczna
• Jakich dostępów wymaga program?
• Jakich dostępów wymagają użyte biblioteki?
• Jak obsłużyć zmianę kodu w bibliotece?
• Analiza dynamiczna
• Uruchomić program, zebrać logi, dodać reguły. Czynność powtórzyć.
• Pokrycie aplikacji testami.
• Nadmiarowe reguły, problem z rozrostem polityki.
22
Tworzenie polityki, duża granularność
• Tizen 2
• Każda aplikacja ma osobną etykietę
• Wiele różnych etykiet dla zasobów
• 600-700 etykiet
• 25000 reguł
• Trudno opisać złożone współdzielenie danych
• Wykorzystanie logów dla dodawania reguł
• Duża polityka, trudna analiza, wiele zbędnych uprawnień
23
Problemy z tworzeniem polityki w Tizen 2
• Późne aplikowanie Smacka dla wygody programistów.
• Bezpieczeństwo jako moduł, który można „włączyć”.
• Stałe zmiany w platformie.
• Brak akceptacji dla czasowego niedziałania platformy (daily release)
• „Security broke me code!”
24
Tworzenie polityki, mała granularność
• Tizen 3
• Polityka podstawa – tylko trzy poziomy
• „floor” – co każdy proces czytać powinien (/, /dev/, /bin/sh, etc.)
• „system” – demony systemowe, z uprawnieniem do czytania i pisania
zasobów systemu
• „application” – wszystkie aplikacje, nie izolowane od siebie przez
Smacka
• Dodatkowe domeny możliwe dla odseparowania wrażliwych aplikacji
(np. manager haseł)
• Jaka jest użyteczność Smacka na tym poziomie?
25
Tizen 3, polityka trzech domen
system-shared system
floor
app app-shared
RWXAT
RX
RX
RWXAT
RX
RX
W
26
Historia Smacka w Linuksie
• 2.6.25: Pierwsza wersja
• 2.6.28: Opcjonalne ograniczanie procesów uprzywilejowanych
• 2.6.31: Obsługa logowania dostępów
• 2.6.38: Obsługa atrybutów SMACK64EXEC, SMACK64TRANSMUTE
• 2.6.39: Obsługa atrybutu SMACK64MMAP
• 3.2: Obsługa /smack/access (zapytania z przestrzeni użytkownika)
• 3.5: Wydłużenie etykiet z 23 do 255 znaków
• 3.7: Obsługa /smack/revoke-subject
• 3.8: Nowy punkt montowania smackfs (/sys/fs/smack)
• 3.10: Obsługa /smack/change-rule (modyfikacja reguł)
27
Literatura
• Dokumentacja jądra Linuksa Documentation/security/Smack.txt
• Prezentacja autora na Linux.conf.au
http://mirror.linux.org.au/pub/linux.conf.au/2008/Thu/mel8-092.ogg
• Smack for simplified access control, LWN
http://lwn.net/Articles/244531/
• Talking Smack for Tizen Security, LWN
http://lwn.net/Articles/552787/
• Prezentacja na Tizen Devcon 2013
http://download.tizen.org/misc/media/conference2013/slides/TDC20
13-It_May_Be_Simple_But_How_Is_It_Useful-Smack_Me_Now.pdf