Piaskownica aplikacji

Platforma Android wykorzystuje ochronę opartą na użytkownikach systemu Linux w celu identyfikowania i izolowania zasobów aplikacji. To izoluje aplikacje od siebie i chroni aplikacje i system przed złośliwymi aplikacjami. Aby to zrobić, Android przypisuje unikalny identyfikator użytkownika (UID) do każdej aplikacji Androida i uruchamia ją w ramach własnego procesu.

Android używa identyfikatora UID do skonfigurowania piaskownicy aplikacji na poziomie jądra. Jądro wymusza bezpieczeństwo między aplikacjami a systemem na poziomie procesu za pomocą standardowych funkcji systemu Linux, takich jak identyfikatory użytkowników i grup przypisane do aplikacji. Domyślnie aplikacje nie mogą ze sobą współdziałać i mają ograniczony dostęp do systemu operacyjnego. Jeśli aplikacja A próbuje zrobić coś złośliwego, na przykład odczytać dane aplikacji B lub wybrać numer telefonu bez pozwolenia, nie może tego zrobić, ponieważ nie ma odpowiednich domyślnych uprawnień użytkownika. Piaskownica jest prosta, możliwa do kontrolowania i oparta na znanym od kilkudziesięciu lat systemie UNIX, polegającym na separacji procesów i uprawnień do plików przez użytkowników.

Ponieważ piaskownica aplikacji znajduje się w jądrze, ten model zabezpieczeń rozciąga się zarówno na kod natywny, jak i aplikacje systemu operacyjnego. Całe oprogramowanie znajdujące się powyżej jądra, takie jak biblioteki systemu operacyjnego, środowisko aplikacji, środowisko wykonawcze aplikacji i wszystkie aplikacje, działają w piaskownicy aplikacji. Na niektórych platformach programiści są ograniczeni do określonego środowiska programistycznego, zestawu interfejsów API lub języka. W systemie Android nie ma żadnych ograniczeń dotyczących sposobu pisania aplikacji, które są wymagane do egzekwowania bezpieczeństwa; pod tym względem kod natywny jest w takim samym stopniu piaskownicą jak kod interpretowany.

Zabezpieczenia

Generalnie, aby wyrwać się z Application Sandbox na odpowiednio skonfigurowanym urządzeniu, trzeba naruszyć bezpieczeństwo jądra Linuksa. Jednakże, podobnie jak w przypadku innych funkcji zabezpieczeń, indywidualne zabezpieczenia wymuszające działanie piaskownicy aplikacji nie są niezniszczalne, dlatego też dogłębna ochrona jest ważna, aby zapobiec sytuacji, w której pojedyncze luki mogłyby doprowadzić do naruszenia bezpieczeństwa systemu operacyjnego lub innych aplikacji.

Android opiera się na szeregu zabezpieczeń, aby wymusić działanie piaskownicy aplikacji. Te środki egzekwowania prawa były wprowadzane z biegiem czasu i znacząco wzmocniły pierwotną piaskownicę dyskrecjonalnej kontroli dostępu (DAC) opartą na UID. Poprzednie wersje Androida zawierały następujące zabezpieczenia:

  • W systemie Android 5.0 SELinux zapewnił obowiązkową separację kontroli dostępu (MAC) między systemem a aplikacjami. Jednak wszystkie aplikacje innych firm działały w tym samym kontekście SELinux, więc izolacja między aplikacjami była wymuszana głównie przez UID DAC.
  • W systemie Android 6.0 piaskownica SELinux została rozszerzona, aby izolować aplikacje poza granicami poszczególnych użytkowników fizycznych. Ponadto system Android ustawił także bezpieczniejsze ustawienia domyślne dla danych aplikacji: w przypadku aplikacji z targetSdkVersion >= 24 domyślne uprawnienia DAC w katalogu domowym aplikacji zmieniono z 751 na 700. Zapewniło to bezpieczniejsze ustawienie domyślne dla prywatnych danych aplikacji (chociaż aplikacje mogą zastąpić te ustawienia domyślne). .
  • W systemie Android 8.0 wszystkie aplikacje zostały ustawione tak, aby działały z filtrem seccomp-bpf , który ograniczał wywołania systemowe, z których mogły korzystać aplikacje, wzmacniając w ten sposób granicę aplikacja/jądro.
  • W systemie Android 9 wszystkie nieuprzywilejowane aplikacje z targetSdkVersion >= 28 muszą działać w indywidualnych piaskownicach SELinux, zapewniając adres MAC dla każdej aplikacji. Ta ochrona poprawia separację aplikacji, zapobiega zastępowaniu bezpiecznych ustawień domyślnych i (co najważniejsze) uniemożliwia aplikacjom udostępnianie ich świata danych.
  • W systemie Android 10 aplikacje mają ograniczony surowy widok systemu plików, bez bezpośredniego dostępu do ścieżek takich jak /sdcard/DCIM. Jednak aplikacje zachowują pełny dostęp do ścieżek specyficznych dla pakietu, zwracanych przez odpowiednie metody, takie jak Context.getExternalFilesDir() .

Wytyczne dotyczące udostępniania plików

Ustawianie danych aplikacji jako dostępnych dla całego świata jest słabą praktyką w zakresie bezpieczeństwa. Dostęp ma każdy i nie ma możliwości ograniczenia dostępu tylko do zamierzonego odbiorcy. Praktyka ta doprowadziła do ujawnienia informacji i niejasnych zastępczych luk w zabezpieczeniach, a także jest ulubionym celem złośliwego oprogramowania, którego celem są aplikacje zawierające wrażliwe dane (takie jak klienci poczty e-mail). W systemie Android 9 i nowszych wersjach udostępnianie plików w ten sposób jest jawnie zabronione w przypadku aplikacji z targetSdkVersion>=28 .

Zamiast udostępniać dane aplikacji całemu światu, podczas udostępniania plików skorzystaj z następujących wskazówek:

  • Jeśli Twoja aplikacja musi udostępniać pliki innej aplikacji, skorzystaj z dostawcy treści . Dostawcy treści udostępniają dane z odpowiednią szczegółowością i bez wielu wad dostępnych na całym świecie uprawnień UNIX (aby uzyskać szczegółowe informacje, zobacz Podstawowe informacje o dostawcach treści ).
  • Jeśli Twoja aplikacja zawiera pliki, które naprawdę powinny być dostępne dla całego świata (takie jak zdjęcia), muszą one być specyficzne dla multimediów (tylko zdjęcia, filmy i pliki audio) i przechowywane przy użyciu klasy MediaStore . (Aby uzyskać więcej informacji na temat dodawania elementu multimedialnego, zobacz Dostęp do plików multimedialnych z pamięci współdzielonej .)

Uprawnienie środowiska uruchomieniowego magazynu kontroluje dostęp do kolekcji o jednoznacznie określonym typie za pośrednictwem MediaStore . Aby uzyskać dostęp do plików o słabym typie, takich jak pliki PDF i klasa MediaStore.Downloads , aplikacje muszą używać intencji, takich jak intencja ACTION_OPEN_DOCUMENT .

Aby włączyć zachowanie systemu Android 10, użyj atrybutu manifestu requestLegacyExternalStorage i postępuj zgodnie ze sprawdzonymi metodami dotyczącymi uprawnień aplikacji .

  • Domyślna wartość flagi manifestu ma wartość true w przypadku aplikacji przeznaczonych dla systemu Android 9 (i starszych).
  • Wartość domyślna to false w przypadku aplikacji przeznaczonych dla systemu Android 10. Aby tymczasowo zrezygnować z widoku filtrowanej pamięci w aplikacjach przeznaczonych dla systemu Android 10, ustaw wartość flagi manifestu na true .
  • Korzystając z ograniczonych uprawnień, instalator umieszcza na białej liście aplikacje dozwolone do przechowywania w trybie innym niż piaskownica. Aplikacje, które nie znajdują się na białej liście, są umieszczane w piaskownicy.