Aplikasi Sandbox

Platform Android memanfaatkan perlindungan berbasis pengguna Linux untuk mengidentifikasi dan mengisolasi sumber daya aplikasi. Ini mengisolasi aplikasi satu sama lain dan melindungi aplikasi dan sistem dari aplikasi berbahaya. Untuk melakukan ini, Android memberikan ID pengguna (UID) unik untuk setiap aplikasi Android dan menjalankannya dalam prosesnya sendiri.

Android menggunakan UID untuk menyiapkan Application Sandbox tingkat kernel. Kernel memberlakukan keamanan antara aplikasi dan sistem pada 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 akses terbatas ke OS. Jika aplikasi A mencoba melakukan sesuatu yang berbahaya, seperti membaca data aplikasi B atau menghubungi telepon tanpa izin, itu akan dicegah karena tidak memiliki hak pengguna default yang sesuai. Kotak pasirnya sederhana, dapat diaudit, dan didasarkan pada pemisahan proses dan izin file gaya UNIX oleh pengguna yang berusia puluhan tahun.

Karena Application Sandbox ada di kernel, model keamanan ini meluas ke kode asli dan aplikasi OS. Semua perangkat lunak di atas kernel, seperti perpustakaan OS, kerangka kerja aplikasi, runtime aplikasi, dan semua aplikasi, berjalan di dalam Application Sandbox. Pada beberapa platform, pengembang dibatasi pada kerangka kerja pengembangan tertentu, serangkaian API, atau bahasa. Di Android, tidak ada batasan tentang bagaimana aplikasi dapat ditulis yang diperlukan untuk menegakkan keamanan; dalam hal ini, kode asli sama sandboxnya dengan kode yang ditafsirkan.

Perlindungan

Umumnya, untuk keluar dari Application Sandbox di perangkat yang dikonfigurasi dengan benar, seseorang harus mengkompromikan keamanan kernel Linux. Namun, mirip dengan fitur keamanan lainnya, perlindungan individu yang menerapkan sandbox aplikasi tidak kebal, jadi pertahanan yang mendalam penting untuk mencegah kerentanan tunggal yang mengarah pada kompromi OS atau aplikasi lain.

Android mengandalkan sejumlah perlindungan untuk menerapkan kotak pasir aplikasi. Penegakan ini telah diperkenalkan dari waktu ke waktu dan telah secara signifikan memperkuat kotak pasir kontrol akses diskresioner (DAC) berbasis UID yang asli. 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 ditegakkan oleh UID DAC.
  • Di Android 6.0, kotak pasir SELinux diperluas untuk mengisolasi aplikasi melintasi batas per pengguna fisik. Selain itu, Android juga menyetel default yang lebih aman untuk data aplikasi: Untuk aplikasi dengan targetSdkVersion >= 24 , izin DAC default pada direktori beranda aplikasi diubah dari 751 menjadi 700. Ini memberikan default yang lebih aman untuk data aplikasi pribadi (walaupun aplikasi dapat menimpa default ini) .
  • Di Android 8.0, semua aplikasi disetel untuk berjalan dengan filter seccomp-bpf yang membatasi syscalls yang diizinkan untuk digunakan oleh aplikasi, sehingga memperkuat batas aplikasi/kernel.
  • Di Android 9 semua aplikasi non-istimewa dengan targetSdkVersion >= 28 harus berjalan di kotak pasir SELinux individual, menyediakan MAC berdasarkan aplikasi. Perlindungan ini meningkatkan pemisahan aplikasi, mencegah mengesampingkan default yang aman, dan (paling signifikan) 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 paketnya, seperti yang dikembalikan oleh metode apa pun yang berlaku, seperti Context.getExternalFilesDir() .

Pedoman untuk berbagi file

Menyetel data aplikasi agar dapat diakses dunia adalah praktik keamanan yang buruk. Akses diberikan kepada semua orang dan tidak mungkin membatasi akses hanya kepada penerima yang dituju. Praktik ini telah menyebabkan kebocoran pengungkapan informasi dan kerentanan deputi yang membingungkan, dan merupakan target favorit untuk malware yang menargetkan aplikasi dengan data sensitif (seperti klien email). Di Android 9 dan yang lebih tinggi, berbagi file dengan cara ini secara eksplisit dilarang untuk aplikasi dengan targetSdkVersion>=28 .

Alih-alih membuat data aplikasi dapat diakses dunia, gunakan panduan berikut saat berbagi file:

  • Jika aplikasi Anda perlu berbagi file dengan aplikasi lain, gunakan penyedia konten . Penyedia konten berbagi data dengan perincian yang tepat dan tanpa banyak kelemahan dari izin UNIX yang dapat diakses dunia (untuk detailnya, lihat Dasar- dasar penyedia konten ).
  • Jika aplikasi Anda memiliki file yang benar-benar dapat diakses oleh dunia (seperti foto), file tersebut harus spesifik media (hanya file foto, video, dan audio) dan disimpan menggunakan kelas MediaStore . (Untuk 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 yang diketik dengan lemah seperti PDF dan kelas MediaStore.Downloads , aplikasi harus menggunakan maksud seperti maksud ACTION_OPEN_DOCUMENT .

Untuk mengaktifkan perilaku Android 10, gunakan atribut manifes requestLegacyExternalStorage , dan ikuti praktik terbaik Izin aplikasi .

  • Nilai default flag manifes adalah true untuk aplikasi yang menargetkan Android 9 (dan lebih rendah).
  • Nilai defaultnya adalah false untuk aplikasi yang menargetkan Android 10. Untuk sementara waktu menyisih dari tampilan penyimpanan yang difilter di aplikasi yang menargetkan Android 10, setel nilai tanda manifes ke true .
  • Menggunakan izin terbatas, penginstal memasukkan aplikasi yang diizinkan untuk penyimpanan non-kotak pasir. Aplikasi yang tidak masuk daftar putih dimasukkan ke dalam kotak pasir.