SELinux w Androidzie: Czy polityka kontroli dostępu jest wystarczająco restrykcyjna? Jak mechanizmy zabezpieczeń mogą zostać ominięte
🔐 SELinux w Androidzie: Czy polityka kontroli dostępu jest wystarczająco restrykcyjna? Jak mechanizmy zabezpieczeń mogą zostać ominięte
📘 Wprowadzenie
System operacyjny Android, używany przez miliardy użytkowników na całym świecie, to nie tylko interfejs aplikacji i ikon. W jego wnętrzu działa wiele mechanizmów bezpieczeństwa, z których jednym z najważniejszych jest SELinux (Security-Enhanced Linux) – system kontroli dostępu oparty na politykach. Wprowadzony do Androida od wersji 4.3 (2013), a obowiązkowy od Androida 5.0, SELinux ma za zadanie zapobiegać eskalacji uprawnień i nieautoryzowanemu dostępowi do zasobów systemowych.
Ale czy SELinux w Androidzie jest wystarczająco skuteczny? Czy możliwe jest jego obejście przez zaawansowanych atakujących? I jak się to ma do rosnących zagrożeń w internecie? Przeanalizujmy to dogłębnie.
⚙️ Co to jest SELinux?
SELinux to system kontroli dostępu typu MAC (Mandatory Access Control), który umożliwia nadzorowanie każdego działania w systemie, odczytu, zapisu, uruchamiania procesów i wielu innych operacji. W odróżnieniu od tradycyjnych mechanizmów DAC (Discretionary Access Control), w których właściciel pliku decyduje o dostępie, SELinux opiera się na regułach ustalonych przez administratora lub politykę systemową.

🧠 Tryby działania SELinux
SELinux może działać w trzech trybach:
- ✅ Enforcing – Polityki są wymuszane i egzekwowane.
- 🟡 Permissive – Polityki są tylko logowane, ale nie blokują działań.
- ❌ Disabled – Mechanizm wyłączony.
Na urządzeniach produkcyjnych (komercyjnych) SELinux zawsze powinien być w trybie enforcing. Jednak podczas testów lub na zrootowanych urządzeniach często działa w trybie permissive lub jest całkowicie wyłączony – co otwiera drzwi do potencjalnych ataków.
🔍 Jak działa SELinux w Androidzie?
SELinux w Androidzie implementowany jest w kontekście „type enforcement”, który pozwala na określenie, jaki proces (np. system_server
, init
, mediaserver
) może wykonać określoną operację na konkretnym typie obiektu (np. plik, katalog, socket).
📦 Przykład reguły:
allow system_server app_data_file:file read;
Oznacza to, że system_server
może czytać pliki oznaczone jako app_data_file
.
🚨 Jak atakujący obchodzą SELinux?
Pomimo zaawansowania tego mechanizmu, SELinux nie jest „kuloodporny”. Poniżej przedstawiamy najczęstsze metody jego obejścia:
🧬 1. Złożoność polityk i błędy w ich implementacji
Niepoprawnie skonfigurowane reguły lub zbyt luźne ustawienia mogą umożliwić nieautoryzowany dostęp. Złożoność rośnie wraz z rozbudową systemu – błędy logiczne są nieuniknione.
🧨 2. Eskalacja przez exploity kernela
SELinux operuje na poziomie przestrzeni użytkownika, a nie chroni przed lukami w jądrze Linuksa. Ataki typu use-after-free, buffer overflow czy race condition mogą pozwolić na wykonanie kodu z uprawnieniami jądra – omijając całkowicie SELinux.
🧫 3. Tryb permissive – cel ataku
Atakujący może próbować zmienić tryb SELinux z enforcing
na permissive
poprzez:
- exploit jądra,
- wykorzystanie luki w
init.rc
, - modyfikację plików konfiguracyjnych (
sepolicy
).
🧿 4. Dostęp do interfejsów debugowych
Debugowe mechanizmy takie jak ADB (adb root
) lub sysfs
, procfs
mogą zostać użyte do manipulacji przestrzenią SELinux, jeśli są źle zabezpieczone.
🛡️ Jak Google próbuje przeciwdziałać tym zagrożeniom?
🔐 1. Modularność polityk (split policies)
Rozdzielenie polityk na część bazową (Google) i dostawczą (OEM) – aby uniemożliwić producentom nadmierne poluzowanie reguł.
📤 2. Automatyczne testy CTS i VTS
System Android wymusza przechodzenie testów bezpieczeństwa dla każdej wersji, aby mieć pewność, że SELinux jest poprawnie skonfigurowany.
🔁 3. Aktualizacje przez Project Mainline
Możliwość aktualizacji komponentów bezpieczeństwa (w tym SELinux) bez konieczności aktualizacji całego systemu.
📈 Przykłady podatności związanych z SELinux w Androidzie
CVE ID | Opis | Wpływ |
---|---|---|
CVE-2021-28663 | UAF w binderze, eskalacja uprawnień mimo aktywnego SELinux | root access |
CVE-2019-2215 | Race condition w binder_thread , exploity wykorzystujące perm flagi SELinux |
wykorzystywane przez NSO Group |
CVE-2020-0069 | Luka w sterowniku Wi-Fi, SELinux nie ograniczył dostępu | RCE |
💬 Czy SELinux jest wystarczający?
✅ Zalety:
- Skutecznie ogranicza przestrzeń ataku dla aplikacji.
- Utrudnia eskalację uprawnień lokalnym exploitom.
- Wspiera izolację danych i usług.
❌ Wady:
- Nie chroni przed exploitami jądra.
- Wymaga dokładności i aktualizacji polityk.
- Może być wyłączony lub obejście zależy od błędów implementacyjnych.
🧭 Najlepsze praktyki dla użytkowników i developerów
- 🔒 Nie rootuj urządzenia, jeśli nie musisz – to otwiera wektor do wyłączenia SELinux.
- ⚠️ Sprawdzaj tryb SELinux (
getenforce
) – jeśli topermissive
, urządzenie jest zagrożone. - 🔄 Utrzymuj system zaktualizowany – najnowsze poprawki są kluczowe.
- 🛠️ Programiści OEM: stosuj zasady „default deny” i testuj swoje polityki
audit2allow
bardzo ostrożnie.
🔚 Podsumowanie
SELinux w Androidzie to potężne narzędzie kontroli dostępu, które stanowi jeden z filarów bezpieczeństwa mobilnych systemów operacyjnych. Jednak nie jest ono nieomylne ani wystarczające samo w sobie. Łącząc się z zagrożeniami w internecie, SELinux wymaga wsparcia ze strony innych mechanizmów bezpieczeństwa oraz świadomego użytkownika i producenta.
SELinux może znacznie utrudnić pracę cyberprzestępcom, ale tylko wtedy, gdy jego polityki są regularnie audytowane, egzekwowane i uzupełniane przez inne warstwy ochronne.