Menerapkan Keamanan

Tim Keamanan Android secara rutin menerima permintaan informasi tentang pencegahan potensi masalah keamanan pada perangkat Android. Kami juga sesekali memeriksa perangkat dan memberi tahu produsen perangkat serta mitra yang terkena dampak mengenai potensi masalah.

Halaman ini memberikan praktik terbaik keamanan berdasarkan pengalaman kami, memperluas dokumentasi Perancangan untuk Keamanan yang telah kami sediakan untuk pengembang dan mencakup detail unik untuk membangun atau menginstal perangkat lunak tingkat sistem pada perangkat.

Untuk memfasilitasi penerapan praktik terbaik ini, jika memungkinkan, Tim Keamanan Android menggabungkan pengujian ke dalam Android Compatibility Test Suite (CTS) dan Android Lint . Kami mendorong pelaksana perangkat untuk menyumbangkan pengujian yang dapat membantu pengguna Android lainnya (lihat pengujian terkait keamanan di root/cts/tests/tests/security/src/android/security/cts ).

Proses pengembangan

Gunakan praktik terbaik berikut dalam proses dan lingkungan pengembangan Anda.

Meninjau kode sumber

Tinjauan kode sumber dapat mendeteksi berbagai masalah keamanan, termasuk yang diidentifikasi dalam dokumen ini. Android sangat menganjurkan peninjauan kode sumber secara manual dan otomatis. Praktik terbaik:

• Jalankan Android Lint pada semua kode aplikasi menggunakan Android SDK dan perbaiki masalah yang teridentifikasi.
• Kode asli harus dianalisis menggunakan alat otomatis yang dapat mendeteksi masalah manajemen memori seperti buffer overflows dan kesalahan satu per satu.
• Sistem build Android memiliki dukungan untuk banyak pembersih LLVM, seperti AddressSanitizer dan UndefinisiBehaviorSanitizer yang dapat digunakan untuk tujuan ini.

Menggunakan pengujian otomatis

Pengujian otomatis dapat mendeteksi berbagai masalah keamanan, termasuk beberapa masalah yang dibahas di bawah. Praktik terbaik:

• CTS diperbarui secara berkala dengan tes keamanan; jalankan CTS versi terbaru untuk memverifikasi kompatibilitas.
• Jalankan CTS secara teratur selama proses pengembangan untuk mendeteksi masalah sejak dini dan mengurangi waktu perbaikan. Android menggunakan CTS sebagai bagian dari integrasi berkelanjutan dalam proses pembangunan otomatis kami, yang dibangun beberapa kali per hari.
• Produsen perangkat harus mengotomatiskan pengujian keamanan antarmuka, termasuk pengujian dengan format input yang salah (pengujian fuzz).

Menandatangani gambar sistem

Tanda tangan dari citra sistem sangat penting untuk menentukan integritas perangkat. Praktik terbaik:

• Perangkat tidak boleh ditandatangani dengan kunci yang diketahui publik.
• Kunci yang digunakan untuk menandatangani perangkat harus dikelola dengan cara yang konsisten dengan praktik standar industri untuk menangani kunci sensitif, termasuk modul keamanan perangkat keras (HSM) yang menyediakan akses terbatas dan dapat diaudit.

Menandatangani aplikasi (APK)

Tanda tangan aplikasi memainkan peran penting dalam keamanan perangkat dan digunakan untuk pemeriksaan izin serta pembaruan perangkat lunak. Saat memilih kunci yang akan digunakan untuk menandatangani aplikasi, penting untuk mempertimbangkan apakah aplikasi hanya akan tersedia di satu perangkat atau umum di beberapa perangkat. Praktik terbaik:

• Permohonan tidak boleh ditandatangani dengan kunci yang diketahui publik.
• Kunci yang digunakan untuk menandatangani aplikasi harus dikelola dengan cara yang konsisten dengan praktik standar industri untuk menangani kunci sensitif, termasuk HSM yang menyediakan akses terbatas dan dapat diaudit.
• Aplikasi tidak boleh ditandatangani dengan kunci platform.
• Aplikasi dengan nama paket yang sama tidak boleh ditandatangani dengan kunci yang berbeda. Hal ini sering terjadi saat membuat aplikasi untuk perangkat yang berbeda, terutama saat menggunakan kunci platform. Jika aplikasi tidak bergantung pada perangkat, gunakan kunci yang sama di seluruh perangkat. Jika aplikasi khusus untuk perangkat, buat nama paket unik per perangkat dan kunci.

Penerbitan aplikasi

Google Play memberi produsen perangkat kemampuan untuk memperbarui aplikasi tanpa melakukan pembaruan sistem secara menyeluruh. Hal ini dapat mempercepat respons terhadap masalah keamanan dan pengiriman fitur baru, serta memberikan cara untuk memastikan aplikasi Anda memiliki nama paket yang unik. Praktik terbaik:

• Unggah aplikasi Anda ke Google Play untuk mengizinkan pembaruan otomatis tanpa memerlukan pembaruan penuh melalui udara (OTA). Aplikasi yang diunggah namun tidak dipublikasikan tidak langsung dapat diunduh oleh pengguna namun aplikasi tetap terupdate. Pengguna yang sebelumnya telah menginstal aplikasi dapat menginstalnya kembali dan/atau menginstalnya di perangkat lain.
• Buat nama paket aplikasi yang jelas terkait dengan perusahaan Anda, misalnya dengan menggunakan merek dagang perusahaan.
• Aplikasi yang dipublikasikan oleh produsen perangkat harus diunggah di Google Play Store untuk menghindari peniruan nama paket oleh pengguna pihak ketiga. Jika produsen perangkat memasang aplikasi di perangkat tanpa memublikasikan aplikasi tersebut di Play Store, pengembang lain dapat mengunggah aplikasi yang sama, menggunakan nama paket yang sama, dan mengubah metadata untuk aplikasi tersebut. Saat aplikasi disajikan kepada pengguna, metadata yang tidak terkait ini dapat menimbulkan kebingungan.

Menanggapi insiden

Pihak eksternal harus dapat menghubungi produsen perangkat mengenai masalah keamanan spesifik perangkat. Kami menyarankan untuk membuat alamat email yang dapat diakses publik untuk mengelola insiden keamanan. Praktik terbaik:

• Buat security@perusahaan-anda.com atau alamat serupa dan publikasikan.
• Jika Anda mengetahui adanya masalah keamanan yang memengaruhi OS Android atau perangkat Android dari beberapa produsen perangkat, Anda harus menghubungi Tim Keamanan Android dengan mengajukan laporan bug Keamanan .

Implementasi produk

Gunakan praktik terbaik berikut saat menerapkan produk.

Mengisolasi proses root

Proses root adalah target paling sering dari serangan eskalasi hak istimewa, sehingga mengurangi jumlah proses root akan mengurangi risiko eskalasi hak istimewa. CTS menyertakan tes informasi yang mencantumkan proses root. Praktik terbaik:

• Perangkat harus menjalankan kode minimum yang diperlukan sebagai root. Jika memungkinkan, gunakan proses Android biasa daripada proses root. ICS Galaxy Nexus hanya memiliki enam proses root: vold, inetd, zygote, tf_daemon, ueventd, dan init. Jika suatu proses harus dijalankan sebagai root pada perangkat, dokumentasikan proses tersebut dalam permintaan fitur AOSP sehingga dapat ditinjau secara publik.
• Jika memungkinkan, kode root harus diisolasi dari data yang tidak tepercaya dan diakses melalui IPC. Misalnya, mengurangi fungsionalitas root menjadi Layanan kecil yang dapat diakses melalui Binder dan mengekspos Layanan dengan izin tanda tangan ke aplikasi dengan hak istimewa rendah atau tanpa hak untuk menangani lalu lintas jaringan.
• Proses root tidak boleh mendengarkan pada soket jaringan.
• Proses root tidak boleh menyediakan runtime tujuan umum untuk aplikasi (misalnya, Java VM).

Mengisolasi aplikasi sistem

Secara umum, aplikasi pra-instal tidak boleh berjalan dengan UID sistem bersama. Namun, jika aplikasi perlu menggunakan UID bersama sistem atau layanan istimewa lainnya, aplikasi tidak boleh mengekspor layanan, penerima siaran, atau penyedia konten apa pun yang dapat diakses oleh aplikasi pihak ketiga yang diinstal oleh pengguna. Praktik terbaik:

• Perangkat harus menjalankan kode minimum yang diperlukan sebagai sistem. Jika memungkinkan, gunakan proses Android dengan UID-nya sendiri daripada menggunakan kembali UID sistem.
• Jika memungkinkan, kode sistem harus diisolasi dari data yang tidak tepercaya dan hanya mengekspos IPC ke proses tepercaya lainnya.
• Proses sistem tidak boleh mendengarkan pada soket jaringan.

Mengisolasi proses

Android Application Sandbox menyediakan aplikasi dengan harapan isolasi dari proses lain pada sistem, termasuk proses root dan debugger. Kecuali jika proses debug diaktifkan secara khusus oleh aplikasi dan pengguna, tidak boleh ada aplikasi yang melanggar ekspektasi tersebut. Praktik terbaik:

• Proses root tidak boleh mengakses data dalam folder data aplikasi individual, kecuali menggunakan metode debugging Android yang terdokumentasi.
• Proses root tidak boleh mengakses memori aplikasi, kecuali menggunakan metode debugging Android yang terdokumentasi.
• Perangkat tidak boleh menyertakan aplikasi apa pun yang mengakses data atau memori aplikasi atau proses lain.

Mengamankan file SUID

Program setuid baru tidak boleh diakses oleh program yang tidak tepercaya. Program setuid sering kali menjadi lokasi kerentanan yang dapat digunakan untuk mendapatkan akses root, jadi usahakan untuk meminimalkan ketersediaan program setuid untuk aplikasi yang tidak tepercaya. Praktik terbaik:

• Proses SUID tidak boleh menyediakan shell atau pintu belakang yang dapat digunakan untuk menghindari model keamanan Android.
• Program SUID tidak boleh ditulis oleh pengguna mana pun.
• Program SUID tidak boleh dibaca atau dieksekusi oleh dunia. Buat grup, batasi akses ke biner SUID hanya untuk anggota grup tersebut, dan tempatkan aplikasi apa pun yang seharusnya dapat menjalankan program SUID ke dalam grup tersebut.
• Program SUID adalah sumber umum rooting perangkat oleh pengguna. Untuk mengurangi risiko ini, program SUID tidak boleh dijalankan oleh pengguna shell.

Pemverifikasi CTS mencakup tes informasi yang mencantumkan file SUID; beberapa file setuid tidak diizinkan per tes CTS.

Mengamankan soket pendengaran

Tes CTS gagal ketika perangkat mendengarkan pada port apa pun, pada antarmuka apa pun. Jika terjadi kegagalan, Android memverifikasi bahwa praktik terbaik berikut sedang digunakan:

• Seharusnya tidak ada port pendengaran pada perangkat.
• Port pendengaran harus dapat dinonaktifkan tanpa OTA. Ini bisa berupa perubahan konfigurasi server atau perangkat pengguna.
• Proses root tidak boleh mendengarkan pada port mana pun.
• Proses yang dimiliki oleh UID sistem tidak boleh mendengarkan pada port mana pun.
• Untuk IPC lokal yang menggunakan soket, aplikasi harus menggunakan Soket Domain UNIX dengan akses terbatas pada grup. Buat deskriptor file untuk IPC dan jadikan +RW untuk grup UNIX tertentu. Setiap aplikasi klien harus berada dalam grup UNIX tersebut.
• Beberapa perangkat dengan banyak prosesor (misalnya radio/modem yang terpisah dari prosesor aplikasi) menggunakan soket jaringan untuk berkomunikasi antar prosesor. Dalam kasus seperti itu, soket jaringan yang digunakan untuk komunikasi antar-prosesor harus menggunakan antarmuka jaringan yang terisolasi untuk mencegah akses oleh aplikasi yang tidak sah pada perangkat (yaitu, menggunakan iptables untuk mencegah akses oleh aplikasi lain pada perangkat).
• Daemon yang menangani port pendengaran harus kuat terhadap data yang salah format. Google dapat melakukan pengujian fuzz terhadap port menggunakan klien yang tidak sah, dan, jika memungkinkan, klien yang diberi wewenang. Setiap kerusakan akan dilaporkan sebagai bug dengan tingkat keparahan yang sesuai.

Pencatatan data

Pencatatan data meningkatkan risiko paparan data tersebut dan mengurangi kinerja sistem. Beberapa insiden keamanan publik telah terjadi akibat pencatatan data sensitif pengguna oleh aplikasi yang diinstal secara default pada perangkat Android. Praktik terbaik:

• Aplikasi atau layanan sistem tidak boleh mencatat data yang disediakan dari aplikasi pihak ketiga yang mungkin berisi informasi sensitif.
• Aplikasi tidak boleh mencatat Informasi Identifikasi Pribadi (PII) apa pun sebagai bagian dari operasi normal.

CTS mencakup pengujian yang memeriksa keberadaan informasi yang berpotensi sensitif dalam log sistem.

Membatasi akses direktori

Direktori yang dapat ditulis oleh dunia dapat menimbulkan kelemahan keamanan dan memungkinkan aplikasi mengganti nama file tepercaya, mengganti file, atau melakukan serangan berbasis symlink (penyerang dapat menggunakan symlink ke file untuk mengelabui program tepercaya agar melakukan tindakan yang tidak seharusnya). Direktori yang dapat ditulisi juga dapat mencegah penghapusan aplikasi dari membersihkan semua file yang terkait dengan aplikasi dengan benar.

Sebagai praktik terbaik, direktori yang dibuat oleh sistem atau pengguna root tidak boleh ditulis oleh dunia. Tes CTS membantu menerapkan praktik terbaik ini dengan menguji direktori yang dikenal.

Mengamankan file konfigurasi

Banyak driver dan layanan bergantung pada konfigurasi dan file data yang disimpan dalam direktori seperti /system/etc dan /data . Jika file-file ini diproses oleh proses yang memiliki hak istimewa dan dapat ditulis oleh dunia, ada kemungkinan bagi aplikasi untuk mengeksploitasi kerentanan dalam proses tersebut dengan membuat konten berbahaya dalam file yang dapat ditulis oleh dunia. Praktik terbaik:

• File konfigurasi yang digunakan oleh proses dengan hak istimewa tidak boleh dibaca oleh dunia.
• File konfigurasi yang digunakan oleh proses dengan hak istimewa tidak boleh dapat ditulis oleh dunia.

Menyimpan perpustakaan kode asli

Kode apa pun yang digunakan oleh proses produsen perangkat yang memiliki hak istimewa harus berada di /vendor atau /system ; sistem file ini dipasang hanya-baca saat boot. Sebagai praktik terbaik, pustaka yang digunakan oleh sistem atau aplikasi dengan hak istimewa tinggi lainnya yang diinstal pada perangkat juga harus ada dalam sistem file ini. Hal ini dapat mencegah kerentanan keamanan yang memungkinkan penyerang mengontrol kode yang dijalankan oleh proses istimewa.

Membatasi akses driver perangkat

Hanya kode tepercaya yang boleh memiliki akses langsung ke driver. Jika memungkinkan, arsitektur yang dipilih adalah menyediakan daemon dengan tujuan tunggal yang memproksi panggilan ke driver dan membatasi akses driver ke daemon tersebut. Sebagai praktik terbaik, node perangkat driver tidak boleh dibaca atau ditulis secara global. Tes CTS membantu menerapkan praktik terbaik ini dengan memeriksa contoh driver yang terekspos.

Menonaktifkan ADB

Android debug bridge (adb) adalah alat pengembangan dan debugging yang berharga, namun dirancang untuk digunakan dalam lingkungan yang terkendali dan aman dan tidak boleh diaktifkan untuk penggunaan umum. Praktik terbaik:

• ADB harus dinonaktifkan secara default.
• ADB harus meminta pengguna untuk mengaktifkannya sebelum menerima koneksi.

Membuka kunci bootloader

Banyak perangkat Android mendukung pembukaan kunci, memungkinkan pemilik perangkat untuk mengubah partisi sistem dan/atau menginstal sistem operasi khusus. Kasus penggunaan umum termasuk menginstal ROM pihak ketiga dan melakukan pengembangan tingkat sistem pada perangkat. Misalnya, pemilik perangkat Google Nexus dapat menjalankan fastboot oem unlock untuk memulai proses membuka kunci, yang menampilkan pesan berikut kepada pengguna:

Sebagai praktik terbaik, perangkat Android yang tidak dapat dibuka kuncinya harus menghapus semua data pengguna dengan aman sebelum dibuka kuncinya. Kegagalan menghapus semua data dengan benar saat membuka kunci dapat memungkinkan penyerang terdekat secara fisik mendapatkan akses tidak sah ke data rahasia pengguna Android. Untuk mencegah pengungkapan data pengguna, perangkat yang mendukung pembukaan kunci harus menerapkannya dengan benar (kita telah melihat banyak contoh di mana produsen perangkat menerapkan pembukaan kunci secara tidak benar). Proses membuka kunci yang diterapkan dengan benar memiliki properti berikut:

• Ketika perintah membuka kunci dikonfirmasi oleh pengguna, perangkat harus segera memulai penghapusan data. Bendera unlocked tidak boleh disetel sampai penghapusan aman selesai.
• Jika penghapusan aman tidak dapat diselesaikan, perangkat harus tetap dalam keadaan terkunci.
• Jika didukung oleh perangkat blok yang mendasarinya, ioctl(BLKSECDISCARD) atau yang setara harus digunakan. Untuk perangkat eMMC, ini berarti menggunakan perintah Secure Erase atau Secure Trim. Untuk eMMC 4.5 dan yang lebih baru, ini berarti menggunakan Erase atau Trim normal yang diikuti dengan operasi Sanitize.
• Jika BLKSECDISCARD tidak didukung oleh perangkat blok yang mendasarinya, ioctl(BLKDISCARD) harus digunakan. Pada perangkat eMMC, ini adalah operasi Trim normal.
• Jika BLKDISCARD tidak didukung, menimpa perangkat blok dengan semua angka nol dapat diterima.
• Pengguna akhir harus memiliki opsi untuk meminta data pengguna dihapus sebelum mem-flash partisi. Misalnya, pada perangkat Nexus, ini dilakukan melalui perintah fastboot oem lock .
• Perangkat dapat merekam, melalui efuse atau mekanisme serupa, apakah perangkat dibuka kuncinya dan/atau dikunci kembali.

Persyaratan ini memastikan bahwa semua data dimusnahkan setelah operasi pembukaan kunci selesai. Kegagalan dalam menerapkan perlindungan ini dianggap sebagai kerentanan keamanan tingkat sedang.

Perangkat yang tidak terkunci selanjutnya dapat dikunci kembali menggunakan perintah fastboot oem lock . Mengunci bootloader memberikan perlindungan yang sama terhadap data pengguna dengan OS kustom baru seperti yang tersedia pada OS pabrikan perangkat asli (misalnya, data pengguna akan dihapus jika perangkat dibuka kuncinya lagi).