Sandbox Aplikasi

Platform Android memanfaatkan perlindungan berbasis pengguna Linux untuk mengidentifikasi dan mengisolasi resource aplikasi. Hal ini mengisolasi aplikasi antara satu sama lain dan melindungi aplikasi dan sistem dari aplikasi berbahaya. Untuk melakukannya, Android menetapkan ID pengguna unik (UID) untuk setiap aplikasi Android dan menjalankannya sendiri {i>checkout<i}.

Android menggunakan UID untuk menyiapkan Sandbox Aplikasi tingkat kernel. Kernel menerapkan keamanan antara aplikasi dan sistem di tingkat proses melalui fasilitas Linux standar seperti ID pengguna dan grup yang ditetapkan ke aplikasi. Secara default, aplikasi tidak dapat berinteraksi satu sama lain dan memiliki batasan akses ke OS. Jika aplikasi A mencoba melakukan sesuatu yang berbahaya, seperti membaca data aplikasi B atau menelepon tanpa izin, aplikasi tersebut akan dicegah untuk melakukannya karena tidak memiliki hak istimewa pengguna default yang sesuai. Sandbox ini sederhana, dapat diaudit, dan didasarkan pada pemisahan proses dan izin file pengguna gaya UNIX yang sudah ada sejak puluhan tahun lalu.

Karena Application Sandbox ada dalam {i>kernel<i}, model keamanan ini meluas ke kode native dan aplikasi OS. Semua perangkat lunak di atas seperti library OS, framework aplikasi, runtime aplikasi, semua aplikasi, berjalan dalam Sandbox Aplikasi. Di beberapa platform, developer dibatasi pada framework pengembangan, kumpulan API, atau bahasa tertentu. Di Android, tidak ada batasan tentang bagaimana aplikasi dapat tertulis yang diwajibkan untuk menegakkan keamanan; Dalam hal ini, kode native dalam sandbox{i> <i}sebagai kode yang ditafsirkan.

Perlindungan

Umumnya, untuk keluar dari Sandbox Aplikasi di perangkat yang dikonfigurasi dengan benar, seseorang harus mengorbankan keamanan kernel Linux. Namun, mirip dengan fitur keamanan lainnya, perlindungan individual yang menerapkan sandbox aplikasi tidak kebal, sehingga pertahanan menyeluruh penting untuk mencegah satu kerentanan menyebabkan kompromi OS atau aplikasi lainnya.

Android mengandalkan sejumlah perlindungan untuk menerapkan aplikasi sandbox. Penegakan ini telah diperkenalkan seiring waktu dan telah secara signifikan memperkuat kontrol akses diskresi berbasis UID asli (DAC). Rilis Android sebelumnya menyertakan perlindungan berikut:

  • Di Android 5.0, SELinux menyediakan pemisahan kontrol akses wajib (MAC) antara sistem dan aplikasi. Namun, semua aplikasi pihak ketiga berjalan dalam konteks SELinux yang sama sehingga isolasi antar-aplikasi terutama diterapkan oleh DAC UID.
  • Di Android 6.0, sandbox SELinux diperluas untuk mengisolasi aplikasi di seluruh batas per pengguna fisik. Selain itu, Android juga menetapkan default yang lebih aman untuk data aplikasi: Untuk aplikasi dengan targetSdkVersion >= 24, default Izin DAC pada direktori beranda aplikasi diubah dari 751 menjadi 700. Hal ini memberikan setelan default yang lebih aman untuk data aplikasi pribadi (meskipun aplikasi dapat mengganti setelan default ini).
  • Di Android 8.0, semua aplikasi disetel untuk berjalan dengan seccomp-bpf filter yang membatasi {i>syscall<i} yang diizinkan untuk digunakan oleh aplikasi, sehingga memperkuat batas aplikasi/kernel.
  • Di Android 9, semua aplikasi yang tidak memiliki hak istimewa dengan targetSdkVersion >= 28 harus berjalan di sandbox SELinux individual, yang menyediakan MAC di per aplikasi layanan. Perlindungan ini meningkatkan pemisahan aplikasi, mencegah penggantian default yang aman, dan (yang paling penting) mencegah aplikasi membuat dunia datanya dapat diakses.
  • Di Android 10, aplikasi memiliki tampilan mentah sistem file yang terbatas, tanpa akses langsung ke jalur seperti /sdcard/DCIM. Namun, aplikasi mempertahankan akses mentah penuh ke jalur khusus paket mereka, seperti yang ditampilkan metode yang berlaku, seperti Context.getExternalFilesDir().

Panduan untuk berbagi file

Menyetel data aplikasi agar dapat diakses semua orang merupakan praktik keamanan yang buruk. Akses diberikan kepada semua orang dan tidak mungkin untuk membatasi akses hanya kepada penerima yang dimaksud. Praktik ini telah menyebabkan kebocoran informasi dan kebingungan kerentanan keamanan, dan merupakan target favorit {i>malware<i} yang menyasar aplikasi dengan data sensitif (seperti program email). Di Android 9 dan yang lebih tinggi, berbagi file dengan cara ini tidak diizinkan secara eksplisit untuk aplikasi dengan targetSdkVersion>=28.

Daripada membuat data aplikasi dapat diakses oleh semua orang, gunakan panduan berikut saat berbagi file:

  • Jika aplikasi Anda perlu berbagi file dengan aplikasi lain, gunakan penyedia konten. Penyedia konten membagikan data dengan perincian yang tepat dan tanpa banyak kelemahan dari izin akses UNIX yang dapat diakses di dunia (untuk detail, lihat Dasar-dasar penyedia konten).
  • Jika aplikasi Anda memiliki file yang benar-benar harus dapat diakses oleh semua orang (seperti foto), file tersebut harus khusus media (hanya file foto, video, dan audio) dan disimpan menggunakan class MediaStore. (Untuk mengetahui detail selengkapnya tentang cara menambahkan item media, lihat Mengakses file media dari penyimpanan bersama.)

Izin runtime Storage mengontrol akses ke koleksi yang diketik dengan kuat melalui MediaStore. Untuk mengakses file dengan jenis lemah seperti PDF dan class MediaStore.Downloads, aplikasi harus menggunakan seperti intent ACTION_OPEN_DOCUMENT.

Untuk mengaktifkan perilaku Android 10, gunakan Manifes requestLegacyExternalStorage dan ikuti Praktik terbaik izin aplikasi.

  • Nilai default flag manifes adalah true untuk aplikasi yang menargetkan Android 9 (dan yang lebih rendah).
  • Nilai defaultnya adalah false untuk aplikasi yang menargetkan Android 10. Untuk sementara waktu memilih tidak ikut tampilan penyimpanan di aplikasi yang menargetkan Android 10, tetapkan nilai tanda manifes ke true.
  • Dengan menggunakan izin terbatas, penginstal mengizinkan aplikasi yang diizinkan untuk penyimpanan tanpa sandbox. Aplikasi yang tidak diizinkan akan di-sandbox.