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 casey@schaufler-ca.com

• 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.

8

Wbudowana polityka

floor

_

hat

^

kaszanka salceson

star

*

RX

RX

RWXA

RX

RWXA RWXA

RWXA

RX RX

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

28

PYTANIA?