Wdrażanie bezpieczeństwa

Zespół ds. bezpieczeństwa systemu Android regularnie otrzymuje prośby o informacje dotyczące zapobiegania potencjalnym problemom związanym z bezpieczeństwem na urządzeniach z systemem Android. Od czasu do czasu sprawdzamy również urządzenia i powiadamiamy producentów urządzeń oraz partnerów, których to dotyczy, o potencjalnych problemach.

Ta strona zawiera najlepsze praktyki w zakresie bezpieczeństwa oparte na naszych doświadczeniach, rozszerzając dokumentację Designing for Security , którą udostępniliśmy programistom i zawiera szczegółowe informacje dotyczące tworzenia lub instalowania oprogramowania na poziomie systemu na urządzeniach.

Aby ułatwić przyjęcie tych najlepszych praktyk, tam, gdzie to możliwe, zespół ds. bezpieczeństwa systemu Android włącza testy do pakietu testów zgodności systemu Android (CTS) i systemu Android Lint . Zachęcamy twórców urządzeń do udostępniania testów, które mogą pomóc innym użytkownikom Androida (zobacz testy związane z bezpieczeństwem w root/cts/tests/tests/security/src/android/security/cts ).

Proces rozwoju

Skorzystaj z poniższych najlepszych praktyk w swoich procesach i środowisku programistycznym.

Przeglądanie kodu źródłowego

Przegląd kodu źródłowego może wykryć szeroki zakres problemów związanych z bezpieczeństwem, w tym te zidentyfikowane w tym dokumencie. Android zdecydowanie zachęca do ręcznego i automatycznego sprawdzania kodu źródłowego. Najlepsze praktyki:

• Uruchom Android Lint na całym kodzie aplikacji za pomocą pakietu Android SDK i napraw wszelkie zidentyfikowane problemy.
• Kod natywny należy analizować za pomocą zautomatyzowanego narzędzia, które może wykryć problemy z zarządzaniem pamięcią, takie jak przepełnienia bufora i błędy „off-by-one”.
• System kompilacji Androida obsługuje wiele środków dezynfekujących LLVM, takich jak AddressSanitizer i UnknownBehaviorSanitizer, których można użyć w tym celu.

Korzystanie z testów automatycznych

Zautomatyzowane testy mogą wykryć szeroki zakres problemów związanych z bezpieczeństwem, w tym kilka problemów omówionych poniżej. Najlepsze praktyki:

• CTS jest regularnie aktualizowany o testy bezpieczeństwa; uruchom najnowszą wersję CTS, aby sprawdzić kompatybilność.
• Regularnie uruchamiaj CTS przez cały proces programowania, aby wcześnie wykryć problemy i skrócić czas potrzebny na ich skorygowanie. Android korzysta z CTS w ramach ciągłej integracji w naszym zautomatyzowanym procesie kompilacji, który jest tworzony wiele razy dziennie.
• Producenci urządzeń powinni zautomatyzować testowanie bezpieczeństwa interfejsów, w tym testowanie ze zniekształconymi danymi wejściowymi (testy fuzz).

Podpisywanie obrazów systemu

Podpis obrazu systemu ma kluczowe znaczenie dla określenia integralności urządzenia. Najlepsze praktyki:

• Urządzenia nie mogą być podpisane kluczem, który jest publicznie znany.
• Kluczami używanymi do podpisywania urządzeń należy zarządzać w sposób zgodny ze standardowymi praktykami branżowymi dotyczącymi obsługi kluczy wrażliwych, w tym za pomocą sprzętowego modułu zabezpieczeń (HSM), który zapewnia ograniczony dostęp podlegający kontroli.

Podpisywanie aplikacji (APK)

Podpisy aplikacji odgrywają ważną rolę w bezpieczeństwie urządzenia i służą do sprawdzania uprawnień, a także aktualizacji oprogramowania. Wybierając klucz, który będzie używany do podpisywania aplikacji, należy wziąć pod uwagę, czy aplikacja będzie dostępna tylko na jednym urządzeniu, czy będzie wspólna dla wielu urządzeń. Najlepsze praktyki:

• Wnioski nie mogą być podpisane kluczem, który jest publicznie znany.
• Kluczami używanymi do podpisywania aplikacji należy zarządzać w sposób zgodny ze standardowymi praktykami branżowymi dotyczącymi obsługi kluczy wrażliwych, w tym z modułem HSM zapewniającym ograniczony dostęp podlegający kontroli.
• Wniosków nie należy podpisywać kluczem platformy.
• Aplikacje o tej samej nazwie pakietu nie powinny być podpisane różnymi kluczami. Często ma to miejsce podczas tworzenia aplikacji na różne urządzenia, szczególnie przy korzystaniu z klucza platformy. Jeśli aplikacja jest niezależna od urządzenia, użyj tego samego klucza na wszystkich urządzeniach. Jeśli aplikacja jest specyficzna dla urządzenia, utwórz unikalne nazwy pakietów dla każdego urządzenia i klucza.

Publikowanie aplikacji

Google Play zapewnia producentom urządzeń możliwość aktualizacji aplikacji bez konieczności wykonywania pełnej aktualizacji systemu. Może to przyspieszyć reakcję na problemy związane z bezpieczeństwem i udostępnienie nowych funkcji, a także zapewnić sposób zapewnienia aplikacji unikatowej nazwy pakietu. Najlepsze praktyki:

• Prześlij swoje aplikacje do Google Play, aby umożliwić automatyczne aktualizacje bez konieczności pełnej aktualizacji bezprzewodowej (OTA). Użytkownicy nie mogą bezpośrednio pobrać aplikacji, które zostały przesłane, ale nieopublikowane, ale są nadal aktualizowane. Użytkownicy, którzy wcześniej zainstalowali aplikację, mogą ją zainstalować ponownie i/lub zainstalować na innych urządzeniach.
• Utwórz nazwę pakietu aplikacji, która będzie wyraźnie powiązana z Twoją firmą, na przykład poprzez użycie znaku towarowego firmy.
• Aplikacje publikowane przez producentów urządzeń należy wgrać do sklepu Google Play, aby uniknąć podszywania się pod nazwę pakietu przez użytkowników zewnętrznych. Jeśli producent urządzenia zainstaluje aplikację na urządzeniu bez publikowania jej w Sklepie Play, inny programista może przesłać tę samą aplikację, użyć tej samej nazwy pakietu i zmienić metadane aplikacji. Gdy aplikacja jest prezentowana użytkownikowi, te niepowiązane metadane mogą powodować zamieszanie.

Reagowanie na incydenty

Podmioty zewnętrzne muszą mieć możliwość kontaktowania się z producentami urządzeń w sprawie problemów związanych z bezpieczeństwem specyficznych dla urządzenia. Zalecamy utworzenie publicznie dostępnego adresu e-mail w celu zarządzania incydentami związanymi z bezpieczeństwem. Najlepsze praktyki:

• Utwórz adres security@twoja-firma.com lub podobny i upublicznij go.
• Jeśli dowiesz się o problemie dotyczącym bezpieczeństwa systemu operacyjnego Android lub urządzeń z systemem Android pochodzących od wielu producentów, skontaktuj się z zespołem ds. bezpieczeństwa systemu Android, przesyłając raport o błędzie zabezpieczeń .

Wdrożenie produktu

Podczas wdrażania produktu zastosuj poniższe najlepsze praktyki.

Izolowanie procesów korzeniowych

Procesy root są najczęstszym celem ataków polegających na eskalacji uprawnień, dlatego zmniejszenie liczby procesów root zmniejsza ryzyko eskalacji uprawnień. CTS zawiera test informacyjny, który wyświetla listę procesów głównych. Najlepsze praktyki:

• Urządzenia powinny uruchamiać minimalny niezbędny kod jako root. Jeśli to możliwe, używaj zwykłego procesu Androida zamiast procesu rootowania. ICS Galaxy Nexus ma tylko sześć procesów głównych: vold, inetd, zygote, tf_daemon, ueventd i init. Jeśli proces musi działać na urządzeniu jako root, udokumentuj go w żądaniu funkcji AOSP, aby można było go publicznie przejrzeć.
• Jeśli to możliwe, kod root powinien być odizolowany od niezaufanych danych i dostępny za pośrednictwem IPC. Na przykład zmniejsz funkcjonalność roota do małej usługi dostępnej za pośrednictwem Bindera i udostępnij usługę z uprawnieniami do podpisu aplikacji z niskimi uprawnieniami lub bez nich do obsługi ruchu sieciowego.
• Procesy root nie mogą nasłuchiwać na gnieździe sieciowym.
• Procesy główne nie mogą zapewniać środowiska uruchomieniowego ogólnego przeznaczenia dla aplikacji (na przykład maszyny wirtualnej Java).

Izolowanie aplikacji systemowych

Ogólnie rzecz biorąc, wstępnie zainstalowane aplikacje nie powinny działać z udostępnionym systemem UID. Jeśli jednak konieczne jest, aby aplikacja korzystała ze wspólnego UID systemu lub innej uprzywilejowanej usługi, aplikacja nie powinna eksportować żadnych usług, odbiorników transmisji ani dostawców treści, do których mogą uzyskać dostęp aplikacje innych firm zainstalowane przez użytkowników. Najlepsze praktyki:

• Urządzenia powinny uruchamiać minimalny niezbędny kod jako system. Jeśli to możliwe, używaj procesu Androida z własnym UID, zamiast ponownie używać systemowego UID.
• Tam, gdzie to możliwe, kod systemowy powinien być odizolowany od niezaufanych danych i udostępniać IPC tylko innym zaufanym procesom.
• Procesy systemowe nie mogą nasłuchiwać na gnieździe sieciowym.

Izolowanie procesów

Android Application Sandbox zapewnia aplikacjom oczekiwaną izolację od innych procesów w systemie, w tym procesów root i debugerów. O ile debugowanie nie zostało specjalnie włączone przez aplikację i użytkownika, żadna aplikacja nie powinna naruszać tych oczekiwań. Najlepsze praktyki:

• Procesy root nie mogą uzyskiwać dostępu do danych w poszczególnych folderach danych aplikacji, chyba że korzystają z udokumentowanej metody debugowania systemu Android.
• Procesy root nie mogą uzyskiwać dostępu do pamięci aplikacji, chyba że korzystają z udokumentowanej metody debugowania systemu Android.
• Na urządzeniach nie mogą znajdować się żadne aplikacje uzyskujące dostęp do danych lub pamięci innych aplikacji lub procesów.

Zabezpieczanie plików SUID

Nowe programy setuid nie powinny być dostępne dla niezaufanych programów. W programach Setuid często znajdują się luki, które można wykorzystać do uzyskania dostępu do konta root, dlatego należy starać się minimalizować dostępność programu setuid dla niezaufanych aplikacji. Najlepsze praktyki:

• Procesy SUID nie mogą udostępniać powłoki ani backdoora, których można użyć do obejścia modelu zabezpieczeń Androida.
• Programy SUID nie mogą być zapisywane przez żadnego użytkownika.
• Programy SUID nie powinny być czytelne dla całego świata ani wykonywalne. Utwórz grupę, ogranicz dostęp do pliku binarnego SUID do członków tej grupy i umieść w tej grupie wszystkie aplikacje, które powinny móc wykonywać program SUID.
• Programy SUID są częstym źródłem rootowania urządzeń przez użytkowników. Aby zmniejszyć to ryzyko, programy SUID nie powinny być wykonywalne przez użytkownika powłoki.

Weryfikator CTS zawiera test informacyjny zawierający listę plików SUID; niektóre pliki setuid nie są dozwolone w testach CTS.

Zabezpieczenie gniazd podsłuchowych

Testy CTS kończą się niepowodzeniem, gdy urządzenie nasłuchuje na dowolnym porcie lub dowolnym interfejsie. W przypadku awarii system Android sprawdza, czy stosowane są następujące najlepsze praktyki:

• Urządzenie nie powinno mieć żadnych portów nasłuchowych.
• Porty nasłuchowe muszą mieć możliwość wyłączenia bez OTA. Może to być zmiana konfiguracji serwera lub urządzenia użytkownika.
• Procesy root nie mogą nasłuchiwać na żadnym porcie.
• Procesy należące do systemowego identyfikatora UID nie mogą nasłuchiwać na żadnym porcie.
• W przypadku lokalnego IPC korzystającego z gniazd aplikacje muszą korzystać z gniazda domeny UNIX z dostępem ograniczonym do grupy. Utwórz deskryptor pliku dla IPC i ustaw go na +RW dla określonej grupy UNIX. Wszelkie aplikacje klienckie muszą należeć do tej grupy UNIX.
• Niektóre urządzenia z wieloma procesorami (np. radio/modem oddzielony od procesora aplikacji) wykorzystują gniazda sieciowe do komunikacji pomiędzy procesorami. W takich przypadkach gniazdo sieciowe używane do komunikacji między procesorami musi korzystać z izolowanego interfejsu sieciowego, aby uniemożliwić dostęp do urządzenia nieautoryzowanym aplikacjom (tzn. należy użyć iptables , aby uniemożliwić dostęp innym aplikacjom na urządzeniu).
• Demony obsługujące porty nasłuchiwania muszą być odporne na zniekształcone dane. Google może przeprowadzić testy fuzz na porcie, korzystając z nieautoryzowanego klienta i, jeśli to możliwe, autoryzowanego klienta. Wszelkie awarie będą zgłaszane jako błędy o odpowiedniej wadze.

Rejestrowanie danych

Rejestrowanie danych zwiększa ryzyko ujawnienia tych danych i zmniejsza wydajność systemu. Doszło do wielu incydentów związanych z bezpieczeństwem publicznym w wyniku rejestrowania wrażliwych danych użytkowników przez aplikacje instalowane domyślnie na urządzeniach z systemem Android. Najlepsze praktyki:

• Aplikacje lub usługi systemowe nie powinny rejestrować danych dostarczanych z aplikacji innych firm, które mogą zawierać informacje wrażliwe.
• Aplikacje nie mogą rejestrować żadnych danych osobowych (PII) w ramach normalnego działania.

CTS obejmuje testy sprawdzające obecność potencjalnie wrażliwych informacji w logach systemowych.

Ograniczanie dostępu do katalogów

Katalogi z możliwością zapisu na całym świecie mogą wprowadzać słabe punkty w zabezpieczeniach i umożliwiać aplikacji zmianę nazw zaufanych plików, zastępowanie plików lub przeprowadzanie ataków opartych na dowiązaniach symbolicznych (osoby atakujące mogą użyć dowiązania symbolicznego do pliku, aby oszukać zaufany program do wykonania działań, których nie powinien). Katalogi z możliwością zapisu mogą również uniemożliwić odinstalowanie aplikacji prawidłowe wyczyszczenie wszystkich plików skojarzonych z aplikacją.

Zgodnie z najlepszą praktyką katalogi utworzone przez system lub użytkowników root nie powinny umożliwiać zapisu na całym świecie. Testy CTS pomagają w egzekwowaniu tej najlepszej praktyki poprzez testowanie znanych katalogów.

Zabezpieczanie plików konfiguracyjnych

Wiele sterowników i usług opiera się na plikach konfiguracyjnych i danych przechowywanych w katalogach takich jak /system/etc i /data . Jeśli te pliki są przetwarzane w procesie uprzywilejowanym i można je zapisywać na całym świecie, aplikacja może wykorzystać lukę w tym procesie, tworząc złośliwą zawartość w pliku, który można zapisywać na całym świecie. Najlepsze praktyki:

• Pliki konfiguracyjne używane przez procesy uprzywilejowane nie powinny być czytelne dla wszystkich.
• Pliki konfiguracyjne używane przez procesy uprzywilejowane nie mogą umożliwiać zapisu na całym świecie.

Przechowywanie natywnych bibliotek kodu

Jakikolwiek kod używany przez procesy producentów urządzeń uprzywilejowanych musi znajdować się w /vendor lub /system ; te systemy plików są montowane podczas rozruchu w trybie tylko do odczytu. Zgodnie z najlepszą praktyką biblioteki używane przez system lub inne wysoko uprzywilejowane aplikacje zainstalowane na urządzeniu powinny również znajdować się w tych systemach plików. Może to zapobiec występowaniu luki w zabezpieczeniach, która mogłaby umożliwić osobie atakującej kontrolowanie kodu wykonywanego przez proces uprzywilejowany.

Ograniczanie dostępu do sterownika urządzenia

Tylko zaufany kod powinien mieć bezpośredni dostęp do sterowników. Tam, gdzie to możliwe, preferowaną architekturą jest zapewnienie demona o jednym przeznaczeniu, który pośredniczy w wywołaniach sterownika i ogranicza dostęp sterownika do tego demona. Zgodnie z najlepszą praktyką węzły urządzeń sterownika nie powinny być czytelne ani zapisywane dla całego świata. Testy CTS pomagają egzekwować tę najlepszą praktykę, sprawdzając znane przypadki odsłoniętych sterowników.

Wyłączanie ADB

Mostek debugowania systemu Android (adb) to cenne narzędzie do programowania i debugowania, ale jest przeznaczony do użytku w kontrolowanych, bezpiecznych środowiskach i nie powinien być włączany do ogólnego użytku. Najlepsze praktyki:

• ADB musi być domyślnie wyłączone.
• ADB musi wymagać od użytkownika włączenia go przed zaakceptowaniem połączenia.

Odblokowanie bootloaderów

Wiele urządzeń z Androidem obsługuje odblokowywanie, umożliwiając właścicielowi urządzenia modyfikację partycji systemowej i/lub instalację niestandardowego systemu operacyjnego. Typowe przypadki użycia obejmują instalację pamięci ROM innej firmy i wykonywanie programowania na poziomie systemu na urządzeniu. Na przykład właściciel urządzenia Google Nexus może uruchomić fastboot oem unlock aby rozpocząć proces odblokowywania, co spowoduje wyświetlenie użytkownikowi następującego komunikatu:

Zgodnie z najlepszą praktyką odblokowane urządzenia z Androidem muszą bezpiecznie usunąć wszystkie dane użytkownika przed odblokowaniem. Nieprawidłowe usunięcie wszystkich danych podczas odblokowania może pozwolić osobie atakującej znajdującej się fizycznie blisko na uzyskanie nieautoryzowanego dostępu do poufnych danych użytkownika Androida. Aby zapobiec ujawnieniu danych użytkownika, urządzenie obsługujące odblokowywanie musi je odpowiednio zaimplementować (widzieliśmy wiele przypadków, w których producenci urządzeń nieprawidłowo wdrożyli odblokowywanie). Prawidłowo zrealizowany proces odblokowania charakteryzuje się następującymi właściwościami:

• Gdy użytkownik zatwierdzi polecenie odblokowania, urządzenie musi natychmiast rozpocząć czyszczenie danych. Flagi unlocked nie można ustawić przed zakończeniem bezpiecznego usuwania.
• Jeżeli bezpieczne usuwanie nie może zostać zakończone, urządzenie musi pozostać w stanie zablokowanym.
• Jeśli jest obsługiwane przez podstawowe urządzenie blokowe, należy użyć ioctl(BLKSECDISCARD) lub równoważnego. W przypadku urządzeń eMMC oznacza to użycie polecenia Bezpieczne usuwanie lub Bezpieczne przycinanie. W przypadku eMMC 4.5 i nowszych wersji oznacza to użycie normalnego usuwania lub przycinania, po którym następuje operacja odkażania.
• Jeśli BLKSECDISCARD nie jest obsługiwany przez bazowe urządzenie blokowe, zamiast tego należy użyć ioctl(BLKDISCARD) . Na urządzeniach eMMC jest to normalna operacja przycinania.
• Jeżeli BLKDISCARD nie jest obsługiwany, dopuszczalne jest nadpisywanie urządzeń blokowych samymi zerami.
• Użytkownik końcowy musi mieć możliwość zażądania wyczyszczenia danych użytkownika przed flashowaniem partycji. Na przykład na urządzeniach Nexus odbywa się to za pomocą polecenia fastboot oem lock .
• Urządzenie może rejestrować za pomocą efusów lub podobnego mechanizmu, czy urządzenie zostało odblokowane i/lub ponownie zablokowane.

Wymagania te zapewniają, że wszystkie dane zostaną zniszczone po zakończeniu operacji odblokowania. Niewdrożenie tych zabezpieczeń jest uważane za lukę w zabezpieczeniach umiarkowanego poziomu.

Odblokowane urządzenie można później ponownie zablokować za pomocą polecenia fastboot oem lock . Zablokowanie programu ładującego zapewnia taką samą ochronę danych użytkownika w nowym, niestandardowym systemie operacyjnym, jak była dostępna w systemie operacyjnym oryginalnego producenta urządzenia (np. dane użytkownika zostaną usunięte, jeśli urządzenie zostanie ponownie odblokowane).