2. Smack
•
•
•
•
Simplified Mandatory Access Control in Kernel
Autor i maintainer: Casey Schaufler casey@schaufler-ca.com
Strona internetowa http://schaufler-ca.com/
Pierwsza wersja: 17 kwietnia 2008
2
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”
3
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
4
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
5
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.
6
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.
7
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
Manager
User
New
Closed
9
Secret
Unclass
Game
HR
Old
Off
rx
R
x
w
rRrRr
-
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!
•
10
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ł
11
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
•
•
•
•
12
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)
•
•
•
13
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
14
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
15
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
•
16
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
17
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
•
•
•
•
18
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
•
19
Maintainer otwarty na dalsze optymalizacje
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.
21
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ń
22
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!”
23
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?
24
25. Tizen 3, polityka trzech domen
system
RX
RX
app-shared
floor
25
RWXAT
system-shared
W
RX
app
RWXAT
RX
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ł)
26
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
27
