Zainstalowałem pewną pamięć ROM, która jest dostarczana z SELinux w trybie „Permissive”. To jedyna (dobra) pamięć ROM, która poprawnie pasuje do mojego urządzenia i nie ma możliwości zmiany stanu SELinuksa.

Teraz nie jestem do końca pewien, jakie są konsekwencje takiej decyzji i byłbym szczęśliwy, gdyby ktoś mógł mi to wyjaśnić (przejrzałem ją i wiem, co to teoretycznie ... po prostu nie w praktyce). Wspomniany ROM ma swój „root” na „wyłączony”, więc urządzenie prawdopodobnie nie jest wyrejestrowane, ale nie wiem, jak to pasuje do SELinuksa.

TL; DR: Jeśli chcesz, możesz przejść bezpośrednio do konkluzji na dole :)!

Celem SELinuksa jest zapobieganie eskalacji uprawnień poprzez egzekwowanie obowiązkowych zasad, które ograniczają możliwe działania zarówno nieuprzywilejowanych, jak i uprzywilejowanych użytkowników.

Termin „użytkownicy” obejmuje tutaj również dowolny proces uruchomiony na urządzeniu, bez względu na to, czy jest on bezpośrednio związany z fizycznymi akcjami użytkownika (człowiek, ty;)), ponieważ każdy proces działa przy użyciu konta systemowego „użytkownika”.

Historycznie, uprawnienia w systemach uniksowych są obsługiwane przy użyciu tak zwanego systemu uznaniowej kontroli dostępu (DAC). W tym modelu:

• Zasoby takie jak pliki mają właścicieli, którzy mogą definiować prawa dostępu do zasobów, które posiadają: pozwala to im zdecydować, czy dany zasób powinien być prywatny (tylko właściciel może uzyskać do niego dostęp), czy też powinien być udostępniany innym użytkownikom.
• Ponadto masz superużytkownika (nazywanego rootw systemach uniksowych), który jest użytkownikiem administracyjnym i ma dostęp do wszystkiego w systemie. To konto może być używane interaktywnie przez człowieka (zazwyczaj administratora systemu) do konserwacji lub naprawy urządzenia, ale zwykle z tego konta będą w większości korzystać usługi w tle lub usługi niskiego poziomu, które wymagają takiego poziomu uprawnień: sterowniki urządzeń, usługi konfiguracji sieci, usługi potrzeba dostępu do plików od każdego użytkownika lub obsługa wewnętrznej komunikacji między użytkownikami.

Jest to bardzo miłe i już zapewnia dobre bezpieczeństwo. A co z okolicznościami takimi jak te:

1. Co by się stało, gdyby rootznaleziono błąd w działającej usłudze, która zostałaby znaleziona, co pozwoliłoby atakującemu oszukać taką usługę w celu uruchomienia dowolnego kodu? Taki atakujący uzyskałby pełny dostęp do urządzenia. Aby podać konkretne przykłady, taki błąd można wywołać, wysyłając do telefonu specjalnie spreparowane informacje o konfiguracji sieci ( DHCP ) lub MMS .
2. Co by się stało, gdyby jakiś użytkownik nie chronił poprawnie zasobów prywatnych? Wówczas zasoby te mogłyby zostać złośliwie udostępnione (odczytane, może nawet zmodyfikowane lub usunięte) innym nieuprzywilejowanym użytkownikom. Zwykle dzieje się tak, gdy na Twoim telefonie działa złośliwa aplikacja (bez względu na to, czy zostałeś oszukiwany, aby ją zainstalować, czy też przyszedł tu sam, wykorzystując błąd w innej nieuprzywilejowanej aplikacji, przeglądarce lub kliencie poczty dla wystąpienie), a ta złośliwa aplikacja próbuje uzyskać bezpośredni dostęp do danych innych aplikacji lub lokalizacji przechowywania (może to zrobić, aby uzyskać dostęp do normalnie niedostępnych danych lub zainstalować się w kilku miejscach, aby utrudnić ich usunięcie).

Nadchodzi SELinux.

SELinux to system obowiązkowej kontroli dostępu (MAC). Podczas gdy we wcześniej opisanym systemie DAC użytkownicy byli odpowiedzialni za odpowiednie ustawienie własnych zasobów, w systemie MAC zasady systemowe (dostarczane wraz z systemem operacyjnym) są egzekwowane zarówno dla użytkowników uprzywilejowanych, jak i nieuprzywilejowanych.

To rozwiązuje dwa wyżej wymienione problemy w następujący sposób:

1. Jak powiedziałem, ta zasada dotyczy również uprzywilejowanych użytkowników. Oznacza to, że przy odpowiednio zaprojektowanych zasadach usługa zaprojektowana do obsługi konfiguracji sieci urządzenia nie będzie mogła zrobić nic innego: na przykład nie będzie miała dostępu do SMS-ów, a usługa obsługująca SMS-y nie będzie miała dostępu do konfiguracji sieci , i żadne z nich nie będzie miało dostępu do danych użytkownika, mimo że oba działają przy użyciu konta superużytkownika.
2. Android ostatnio zawiera funkcję wielu użytkowników, która jest egzekwowana przez SELinux, uniemożliwiając każdemu użytkownikowi dostęp do danych innego użytkownika. Ale poza tym polityka SELinuksa jest również odpowiedzialna za opisywanie dozwolonych zachowań aplikacji, i najprawdopodobniej nawet jeśli niektóre zasoby nie są odpowiednio chronione za pomocą systemu DAC, SELinux przyjdzie na ratunek i nadal uniemożliwi złośliwemu programowi bezpośredni dostęp do nich.

Systemy DAC i MAC nie wykluczają się wzajemnie, wręcz przeciwnie, system MAC (SELinux) działa jako druga warstwa obrony za systemem DAC (tradycyjne uprawnienia uniksopodobne). Zadaniem SELinuksa jest blokowanie wszelkich działań sprzecznych z polityką, która w przypadku systemu DAC zostałaby zaakceptowana.

Trudne jest to, że taka polityka może być bardzo złożona do napisania: musi ona rzeczywiście obejmować komponenty każdego urządzenia dla każdego możliwego zastosowania w każdej sytuacji. W rzeczywistości, bez względu na to, czy jakieś działanie może być uzasadnione w twojej sytuacji: jeśli nie ma tego w polisie, jest zabronione . Źle zaprojektowane zasady mogą mieć zatem losowe konsekwencje, takie jak awarie aplikacji, bezużyteczna funkcjonalność itp.

Dlatego pierwsze wersje systemu Android SELinux w wersji domyślnej zawierały go w trybie „Permissive”. W tym trybie SELinux rejestruje naruszenia zasad, ale nie będzie próbował blokować powiązanej aktywności. Analizując wynikowe pliki dziennika, możliwe jest poprawienie i udoskonalenie zasad aż do momentu, gdy jedynym pozostałym naruszeniem zasad są rzeczywiście złośliwe lub niepożądane zachowania. W tym momencie SELinux można zmienić w tryb „Egzekwowania”: będzie teraz nie tylko rejestrować, ale także blokować każdą szkodliwą akcję.

Wniosek

SELinux jest techniką ograniczającą ryzyko. Nie przeszkadza to atakującym w wejściu do twojego telefonu, ale zapewnia, że ​​gdy tam będą mogli zrobić tak mało rzeczy, jak to możliwe, idealnie nic użytecznego, tym samym eliminując wszelkie zainteresowanie atakowaniem telefonu.

Im starsza pamięć ROM, tym większa liczba błędów bezpieczeństwa, które otworzyłyby taki dostęp. SELinux byłby skutecznym sposobem na utrzymanie minimalnego bezpieczeństwa pomimo tych znanych luk, jednak prawidłowe działanie SELinux opiera się na złożonej polityce.

Jeśli ROM jest domyślnie wyposażony w SELinux w trybie „Permissive”, prawdopodobnie oznacza to, że zawarte w nim zasady nie są wystarczająco niezawodne, aby można je było bezpiecznie przełączyć w tryb „Enforcing”.

Jeśli jesteś wystarczająco zaawansowany technicznie i masz dostęp do dziennika telefonu ( dmesgprzynajmniej, ale zwykle są one również kopiowane logcat: istnieją aplikacje pozwalające zobaczyć ten ostatni, ale w zależności od wersji Androida mogą wymagać dostępu do konta root), możesz sprawdzić, czy znajdziesz wpisy „avc”: są to wiadomości informujące, że SELinux właśnie wykrył działanie niezgodne z polityką.

Oto przykład takiego wpisu zaczerpniętego ze strony internetowej CyanogenMod :

type=AVC msg=audit(1363289005.532:184): avc: denied { read } for pid=29199 comm="Trace" 
name="online" dev="sysfs" ino=30 scontext=staff_u:staff_r:googletalk_plugin_t 
tcontext=system_u:object_r:sysfs_t tclass=file

Jeśli nie ma żadnych, tylko kilka z nich lub z jakiegokolwiek powodu, który uważasz, że mogą nie powstrzymywać cię przed używaniem telefonu, możesz spróbować przełączyć SELinux w tryb „Egzekwowania”. W starszych ROMach CyanogenMod było to łatwe i możliwe po prostu za pomocą ukrytej opcji w GUI (nie trzeba rootować telefonu ani instalować żadnej konkretnej aplikacji), nie wiem, czy inne ROMy oferowały tę samą funkcję, ale ponieważ używałeś CyanogenMod tag Przypuszczam, że możesz mieć szczęście;).