Google berkomitmen untuk mendorong terwujudnya keadilan ras bagi komunitas Kulit Hitam. Lihat caranya.

Halaman ini diterjemahkan oleh Cloud Translation API.

Menyesuaikan SELinux

Setelah Anda mengintegrasikan tingkat dasar fungsionalitas SELinux dan menganalisis hasilnya secara menyeluruh, Anda dapat menambahkan pengaturan kebijakan Anda sendiri untuk mencakup penyesuaian Anda ke sistem operasi Android. Kebijakan ini tetap harus memenuhi persyaratan program Kompatibilitas Android dan tidak boleh menghapus pengaturan SELinux default.

Produsen tidak boleh menghapus kebijakan SELinux yang ada. Jika tidak, mereka berisiko merusak implementasi Android SELinux dan aplikasi yang diaturnya. Ini termasuk aplikasi pihak ketiga yang mungkin perlu ditingkatkan agar sesuai dan operasional. Aplikasi tidak boleh memerlukan modifikasi untuk terus berfungsi pada perangkat yang mendukung SELinux.

Saat memulai penyesuaian SELinux, ingatlah untuk:

Tulis kebijakan SELinux untuk semua daemon baru
Gunakan domain yang telah ditentukan sebelumnya bila perlu
Tetapkan domain ke proses apa pun yang muncul sebagai layanan init
Kenali makro sebelum menulis kebijakan
Kirimkan perubahan pada kebijakan inti ke AOSP

Dan ingat untuk tidak:

Buat kebijakan yang tidak kompatibel
Izinkan penyesuaian kebijakan pengguna akhir
Izinkan penyesuaian kebijakan MDM
Menakut-nakuti pengguna dengan pelanggaran kebijakan
Tambahkan pintu belakang

Lihat bagian Fitur Keamanan Kernel dari dokumen Definisi Kompatibilitas Android untuk persyaratan tertentu.

SELinux menggunakan pendekatan daftar putih, artinya semua akses harus diizinkan secara eksplisit dalam kebijakan agar dapat diberikan. Karena kebijakan SELinux default Android sudah mendukung Android Open Source Project, Anda tidak perlu mengubah pengaturan SELinux dengan cara apa pun. Jika Anda menyesuaikan pengaturan SELinux, berhati-hatilah agar tidak merusak aplikasi yang ada. Untuk memulai:

Gunakan kernel Android terbaru .
Mengadopsi prinsip hak istimewa terkecil .
Alamat hanya tambahan Anda sendiri untuk Android. Kebijakan default bekerja dengan basis kode Proyek Sumber Terbuka Android secara otomatis.
Pisahkan komponen perangkat lunak ke dalam modul yang melakukan tugas tunggal.
Buat kebijakan SELinux yang mengisolasi tugas tersebut dari fungsi yang tidak terkait.
Letakkan kebijakan tersebut di file *.te (ekstensi untuk file sumber kebijakan SELinux) di dalam direktori /device/ manufacturer / device-name /sepolicy dan gunakan variabel BOARD_SEPOLICY untuk memasukkannya ke dalam build.
Buat domain baru permisif pada awalnya. Ini dilakukan dengan menggunakan deklarasi permisif di file .te domain.
Analisis hasil dan perbaiki definisi domain Anda.
Hapus deklarasi permisif saat tidak ada penolakan lebih lanjut yang muncul di build userdebug.

Setelah Anda mengintegrasikan perubahan kebijakan SELinux Anda, tambahkan satu langkah ke alur kerja pengembangan Anda untuk memastikan kompatibilitas SELinux ke depannya. Dalam proses pengembangan perangkat lunak yang ideal, kebijakan SELinux hanya berubah ketika model perangkat lunak berubah dan bukan implementasi yang sebenarnya.

Saat Anda mulai menyesuaikan SELinux, pertama-tama audit penambahan Anda ke Android. Jika Anda telah menambahkan komponen yang menjalankan fungsi baru, pastikan komponen tersebut memenuhi kebijakan keamanan Android, serta semua kebijakan terkait yang dibuat oleh OEM, sebelum mengaktifkan mode penerapan.

Untuk mencegah masalah yang tidak perlu, lebih baik menjadi terlalu luas dan terlalu kompatibel daripada terlalu membatasi dan tidak kompatibel, yang mengakibatkan fungsi perangkat rusak. Sebaliknya, jika perubahan Anda bermanfaat bagi orang lain, Anda harus mengirimkan modifikasi ke kebijakan SELinux default sebagai patch . Jika tambalan diterapkan ke kebijakan keamanan default, Anda tidak perlu melakukan perubahan ini dengan setiap rilis Android baru.

Contoh pernyataan kebijakan

SELinux didasarkan pada bahasa komputer M4 dan oleh karena itu mendukung berbagai makro untuk menghemat waktu.

Dalam contoh berikut, semua domain diberikan akses untuk membaca dari atau menulis ke /dev/null dan membaca dari /dev/zero .

# Allow read / write access to /dev/null
allow domain null_device:chr_file { getattr open read ioctl lock append write};

# Allow read-only access to /dev/zero
allow domain zero_device:chr_file { getattr open read ioctl lock };

Pernyataan yang sama ini dapat ditulis dengan makro SELinux *_file_perms (singkatan):

# Allow read / write access to /dev/null
allow domain null_device:chr_file rw_file_perms;

# Allow read-only access to /dev/zero
allow domain zero_device:chr_file r_file_perms;

Contoh kebijakan

Berikut adalah contoh kebijakan lengkap untuk DHCP, yang kami periksa di bawah ini:

type dhcp, domain;
permissive dhcp;
type dhcp_exec, exec_type, file_type;
type dhcp_data_file, file_type, data_file_type;

init_daemon_domain(dhcp)
net_domain(dhcp)

allow dhcp self:capability { setgid setuid net_admin net_raw net_bind_service
};
allow dhcp self:packet_socket create_socket_perms;
allow dhcp self:netlink_route_socket { create_socket_perms nlmsg_write };
allow dhcp shell_exec:file rx_file_perms;
allow dhcp system_file:file rx_file_perms;
# For /proc/sys/net/ipv4/conf/*/promote_secondaries
allow dhcp proc_net:file write;
allow dhcp system_prop:property_service set ;
unix_socket_connect(dhcp, property, init)

type_transition dhcp system_data_file:{ dir file } dhcp_data_file;
allow dhcp dhcp_data_file:dir create_dir_perms;
allow dhcp dhcp_data_file:file create_file_perms;

allow dhcp netd:fd use;
allow dhcp netd:fifo_file rw_file_perms;
allow dhcp netd:{ dgram_socket_class_set unix_stream_socket } { read write };
allow dhcp netd:{ netlink_kobject_uevent_socket netlink_route_socket
netlink_nflog_socket } { read write };

Mari kita membedah contohnya:

Pada baris pertama, deklarasi tipe, daemon DHCP mewarisi dari kebijakan keamanan dasar ( domain ). Dari contoh pernyataan sebelumnya, DHCP dapat membaca dan menulis ke /dev/null .

Di baris kedua, DHCP diidentifikasi sebagai domain permisif.

Di baris init_daemon_domain(dhcp) , kebijakan menyatakan DHCP muncul dari init dan diizinkan untuk berkomunikasi dengannya.

Di baris net_domain(dhcp) , kebijakan memungkinkan DHCP untuk menggunakan fungsionalitas jaringan umum dari domain net seperti membaca dan menulis paket TCP, berkomunikasi melalui soket, dan melakukan permintaan DNS.

Di baris allow dhcp proc_net:file write; , kebijakan menyatakan DHCP dapat menulis ke file tertentu di /proc . Baris ini menunjukkan pelabelan file berbutir halus SELinux. Ia menggunakan label proc_net untuk membatasi akses tulis hanya ke file di bawah /proc/sys/net .

Blok terakhir dari contoh yang dimulai dengan allow dhcp netd:fd use; menggambarkan bagaimana aplikasi dapat diizinkan untuk berinteraksi satu sama lain. Kebijakan mengatakan DHCP dan netd dapat berkomunikasi satu sama lain melalui deskriptor file, file FIFO, soket datagram, dan soket aliran UNIX. DHCP hanya dapat membaca dan menulis dari soket datagram dan soket aliran UNIX dan tidak membuat atau membukanya.

Kontrol yang tersedia

Kelas	Izin
mengajukan	ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename execute swapon quotaon mounton
direktori	add_name remove_name reparent search rmdir open audit_access execmod
stopkontak	ioctl read write create getattr setattr lock relabelfrom relabelto append bind connect listen accept getopt setopt shutdown recvfrom sendto recv_msg send_msg name_bind
berkas sistem	mount remount unmount getattr relabelfrom relabelto transition associate quotamod quotaget
proses	fork transition sigchld sigkill sigstop signull signal ptrace getsched setsched getsession getpgid setpgid getcap setcap share getattr setexec setfscreate noatsecure siginh setrlimit rlimitinh dyntransition setcurrent execmem execstack execheap setkeycreate setsockcreate
keamanan	compute_av compute_create compute_member check_context load_policy compute_relabel compute_user setenforce setbool setsecparam setcheckreqprot read_policy
kemampuan	chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write audit_control setfcap
LAGI	DAN LAINNYA

tidak pernah mengizinkan aturan

Aturan SELinux neverallow melarang perilaku yang seharusnya tidak pernah terjadi. Dengan pengujian kompatibilitas , aturan neverallow SELinux sekarang diterapkan di seluruh perangkat.

Panduan berikut dimaksudkan untuk membantu produsen menghindari kesalahan yang terkait dengan aturan neverallow selama penyesuaian. Nomor aturan yang digunakan di sini sesuai dengan Android 5.1 dan dapat berubah berdasarkan rilis.

Aturan 48: neverallow { domain -debuggerd -vold -dumpstate -system_server } self:capability sys_ptrace;
Lihat halaman manual untuk ptrace . Kemampuan sys_ptrace memberikan kemampuan untuk ptrace proses apa pun, yang memungkinkan banyak kendali atas proses lain dan seharusnya hanya dimiliki oleh komponen sistem yang ditentukan, yang diuraikan dalam aturan. Kebutuhan akan kemampuan ini sering kali menunjukkan adanya sesuatu yang tidak dimaksudkan untuk build yang menghadap pengguna atau fungsionalitas yang tidak diperlukan. Hapus komponen yang tidak perlu.

Aturan 76: neverallow { domain -appdomain -dumpstate -shell -system_server -zygote } { file_type -system_file -exec_type }:file execute;
Aturan ini dimaksudkan untuk mencegah eksekusi kode arbitrer pada sistem. Secara khusus, ini menegaskan bahwa hanya kode pada /system yang dieksekusi, yang memungkinkan jaminan keamanan berkat mekanisme seperti boot terverifikasi. Seringkali, solusi terbaik saat menghadapi masalah dengan aturan neverallow ini adalah dengan memindahkan kode yang melanggar ke partisi /system .

Menyesuaikan SEPolicy di Android 8.0+

Bagian ini memberikan panduan untuk kebijakan SELinux vendor di Android 8.0 dan yang lebih tinggi, termasuk detail tentang ekstensi SEPolicy dan SEPolicy Proyek Sumber Terbuka Android (AOSP). Untuk informasi selengkapnya tentang bagaimana kebijakan SELinux tetap kompatibel di seluruh partisi dan versi Android, lihat Kompatibilitas .

Penempatan kebijakan

Di Android 7.0 dan yang lebih lama, produsen perangkat dapat menambahkan kebijakan ke BOARD_SEPOLICY_DIRS , termasuk kebijakan yang dimaksudkan untuk menambah kebijakan AOSP di berbagai jenis perangkat. Di Android 8.0 dan lebih tinggi, menambahkan kebijakan ke BOARD_SEPOLICY_DIRS menempatkan kebijakan hanya di gambar vendor.

Di Android 8.0 dan yang lebih tinggi, kebijakan ada di lokasi berikut di AOSP:

sistem/kebijakan/publik . Termasuk kebijakan yang diekspor untuk digunakan dalam kebijakan khusus vendor. Semuanya masuk ke infrastruktur kompatibilitas Android 8.0. Kebijakan publik dimaksudkan untuk tetap ada di seluruh rilis sehingga Anda dapat menyertakan apa pun /public dalam kebijakan khusus Anda. Karena itu, jenis kebijakan yang dapat ditempatkan di /public lebih dibatasi. Pertimbangkan ini API kebijakan yang diekspor platform: Apa pun yang berhubungan dengan antarmuka antara /system dan /vendor termasuk di sini.
sistem/kebijakan/swasta . Mencakup kebijakan yang diperlukan untuk memfungsikan citra sistem, tetapi kebijakan citra vendor mana yang seharusnya tidak diketahui.
sistem/kebijakan/vendor . Mencakup kebijakan untuk komponen yang masuk /vendor tetapi ada di pohon platform inti (bukan direktori khusus perangkat). Ini adalah artefak perbedaan sistem build antara perangkat dan komponen global; secara konseptual ini adalah bagian dari kebijakan khusus perangkat yang dijelaskan di bawah ini.
device/ manufacturer / device-name /sepolicy . Mencakup kebijakan khusus perangkat. Juga mencakup penyesuaian perangkat terhadap kebijakan, yang di Android 8.0 dan yang lebih tinggi sesuai dengan kebijakan untuk komponen pada citra vendor.

Di Android 11 dan yang lebih tinggi, system_ext dan partisi produk juga dapat menyertakan kebijakan khusus partisi. system_ext dan kebijakan produk juga dibagi menjadi publik dan pribadi, dan vendor dapat menggunakan kebijakan publik system_ext dan produk, seperti kebijakan sistem.

SYSTEM_EXT_PUBLIC_SEPOLICY_DIRS . Termasuk kebijakan yang diekspor untuk digunakan dalam kebijakan khusus vendor. Diinstal ke partisi system_ext.
SYSTEM_EXT_PRIVATE_SEPOLICY_DIRS . Mencakup kebijakan yang diperlukan untuk memfungsikan citra system_ext, tetapi kebijakan citra vendor mana yang seharusnya tidak diketahui. Diinstal ke partisi system_ext.
PRODUCT_PUBLIC_SEPOLICY_DIRS . Termasuk kebijakan yang diekspor untuk digunakan dalam kebijakan khusus vendor. Diinstal ke partisi produk.
PRODUCT_PRIVATE_SEPOLICY_DIRS . Mencakup kebijakan yang diperlukan untuk memfungsikan citra produk, tetapi kebijakan citra vendor mana yang seharusnya tidak diketahui. Diinstal ke partisi produk.

Catatan: ketika GSI digunakan, partisi system_ext dan produk OEM tidak akan dipasang. Aturan dalam kebijakan vendor yang menggunakan system_ext OEM dan kebijakan publik produk menjadi NOP karena definisi tipe khusus OEM hilang.

Catatan: Berhati-hatilah saat menggunakan system_ext dan kebijakan publik produk. Kebijakan publik bertindak sebagai API yang diekspor antara system_ext/produk dan vendor. Mitra seharusnya mengelola sendiri masalah kompatibilitas.

Skenario kebijakan yang didukung

Pada perangkat yang diluncurkan dengan Android 8.0 dan lebih tinggi, citra vendor harus bekerja dengan citra sistem OEM dan citra sistem AOSP referensi yang disediakan oleh Google (dan meneruskan CTS pada citra referensi ini). Persyaratan ini memastikan pemisahan yang bersih antara kerangka kerja dan kode vendor. Perangkat tersebut mendukung skenario berikut.

ekstensi khusus gambar vendor

Contoh : Menambahkan layanan baru ke vndservicemanager dari citra vendor yang mendukung proses dari citra vendor.

Seperti perangkat yang diluncurkan dengan versi Android sebelumnya, tambahkan penyesuaian khusus perangkat di device/ manufacturer / device-name /sepolicy . Kebijakan baru yang mengatur bagaimana komponen vendor berinteraksi dengan (hanya) komponen vendor lain harus melibatkan jenis yang hanya ada di device/ manufacturer / device-name /sepolicy . Kebijakan yang ditulis di sini memungkinkan kode pada vendor berfungsi, tidak akan diperbarui sebagai bagian dari OTA kerangka saja, dan akan ada dalam kebijakan gabungan pada perangkat dengan gambar sistem referensi AOSP.

dukungan vendor-image untuk bekerja dengan AOSP

Contoh : Menambahkan proses baru (terdaftar dengan hwservicemanager dari gambar vendor) yang mengimplementasikan HAL yang ditentukan oleh AOSP.

Seperti perangkat yang diluncurkan dengan versi Android sebelumnya, lakukan penyesuaian khusus perangkat di device/ manufacturer / device-name /sepolicy . Kebijakan yang diekspor sebagai bagian dari system/sepolicy/public/ tersedia untuk digunakan, dan dikirimkan sebagai bagian dari kebijakan vendor. Jenis dan atribut dari kebijakan publik dapat digunakan dalam aturan baru yang mendikte interaksi dengan bit khusus vendor yang baru, tunduk pada batasan neverallow yang diberikan. Seperti kasus khusus vendor, kebijakan baru di sini tidak akan diperbarui sebagai bagian dari OTA kerangka saja dan akan hadir dalam kebijakan gabungan pada perangkat dengan citra sistem referensi AOSP.

ekstensi hanya gambar sistem

Contoh : Menambahkan layanan baru (terdaftar dengan servicemanager) yang hanya diakses oleh proses lain dari citra sistem.

Tambahkan kebijakan ini ke system/sepolicy/private . Anda dapat menambahkan proses atau objek tambahan untuk mengaktifkan fungsionalitas dalam citra sistem mitra, asalkan bit baru tersebut tidak perlu berinteraksi dengan komponen baru pada citra vendor (khususnya, proses atau objek tersebut harus berfungsi penuh tanpa kebijakan dari citra vendor) . Kebijakan yang diekspor oleh system/sepolicy/public tersedia di sini seperti halnya untuk ekstensi khusus gambar vendor. Kebijakan ini merupakan bagian dari citra sistem dan dapat diperbarui dalam OTA kerangka saja, tetapi tidak akan ada saat menggunakan citra sistem AOSP referensi.

ekstensi gambar vendor yang melayani komponen AOSP yang diperluas

Contoh: HAL non-AOSP baru untuk digunakan oleh klien yang diperluas yang juga ada dalam citra sistem AOSP (seperti server_sistem yang diperluas).

Kebijakan untuk interaksi antara sistem dan vendor harus disertakan dalam direktori device/ manufacturer / device-name /sepolicy yang dikirimkan pada partisi vendor. Ini mirip dengan skenario di atas untuk menambahkan dukungan vendor-image untuk bekerja dengan gambar AOSP referensi, kecuali komponen AOSP yang dimodifikasi mungkin juga memerlukan kebijakan tambahan untuk beroperasi dengan benar dengan sisa partisi sistem (yang baik-baik saja selama mereka masih memiliki label tipe AOSP publik).

Kebijakan interaksi komponen AOSP publik dengan ekstensi hanya gambar sistem harus dalam system/sepolicy/private .

ekstensi gambar sistem yang hanya mengakses antarmuka AOSP

Contoh: Proses sistem non-AOSP yang baru harus mengakses HAL yang menjadi sandaran AOSP.

Ini mirip dengan contoh ekstensi sistem-gambar-saja , kecuali komponen sistem baru dapat berinteraksi di seluruh antarmuka system/vendor . Kebijakan untuk komponen sistem baru harus masuk system/sepolicy/private , yang dapat diterima asalkan melalui antarmuka yang sudah dibuat oleh AOSP di system/sepolicy/public (yaitu jenis dan atribut yang diperlukan untuk fungsionalitas ada di sana). Meskipun kebijakan dapat disertakan dalam kebijakan khusus perangkat, kebijakan tersebut tidak dapat menggunakan jenis atau perubahan system/sepolicy/private lainnya (dengan cara apa pun yang memengaruhi kebijakan) sebagai akibat dari pembaruan khusus kerangka kerja. Kebijakan dapat diubah dalam OTA kerangka saja, tetapi tidak akan ada saat menggunakan citra sistem AOSP (yang juga tidak akan memiliki komponen sistem baru).

ekstensi vendor-image yang melayani komponen sistem baru

Contoh: Menambahkan HAL non-AOSP baru untuk digunakan oleh proses klien tanpa analog AOSP (dan karenanya memerlukan domainnya sendiri).

Mirip dengan contoh AOSP-extensions , kebijakan untuk interaksi antara sistem dan vendor harus masuk ke direktori device/ manufacturer / device-name /sepolicy yang dikirimkan pada partisi vendor (untuk memastikan kebijakan sistem tidak memiliki pengetahuan tentang detail spesifik vendor). Anda dapat menambahkan tipe publik baru yang memperluas kebijakan di system/sepolicy/public ; ini harus dilakukan hanya di samping kebijakan AOSP yang ada, yaitu tidak menghapus kebijakan publik AOSP. Tipe publik baru kemudian dapat digunakan untuk kebijakan di system/sepolicy/private dan di device/ manufacturer / device-name /sepolicy .

Ingatlah bahwa setiap penambahan pada system/sepolicy/public menambah kerumitan dengan memperlihatkan jaminan kompatibilitas baru yang harus dilacak dalam file pemetaan dan yang tunduk pada batasan lain. Hanya tipe baru dan aturan izinkan yang sesuai yang dapat ditambahkan di system/sepolicy/public ; atribut dan pernyataan kebijakan lainnya tidak didukung. Selain itu, tipe publik baru tidak dapat digunakan untuk langsung melabeli objek dalam kebijakan /vendor .

Skenario kebijakan yang tidak didukung

Perangkat yang diluncurkan dengan Android 8.0 dan lebih tinggi tidak mendukung skenario dan contoh kebijakan berikut.

Ekstensi tambahan untuk citra sistem yang memerlukan izin untuk komponen citra vendor baru setelah OTA kerangka saja

Contoh: Proses sistem non-AOSP baru, yang memerlukan domainnya sendiri, ditambahkan dalam rilis Android berikutnya dan memerlukan akses ke HAL non-AOSP baru.

Mirip dengan sistem baru (non-AOSP) dan interaksi komponen vendor , kecuali tipe sistem baru diperkenalkan dalam OTA kerangka saja. Meskipun tipe baru dapat ditambahkan ke kebijakan di system/sepolicy/public , kebijakan vendor yang ada tidak memiliki pengetahuan tentang tipe baru karena hanya melacak kebijakan publik sistem Android 8.0. AOSP menangani ini dengan mengekspos sumber daya yang disediakan vendor melalui atribut (misalnya atribut hal_foo ) tetapi karena ekstensi mitra atribut tidak didukung di system/sepolicy/public , metode ini tidak tersedia untuk kebijakan vendor. Akses harus disediakan oleh tipe publik yang sudah ada sebelumnya.

Contoh: Perubahan pada proses sistem (AOSP atau non-AOSP) harus mengubah cara interaksinya dengan komponen vendor non-AOSP yang baru.

Kebijakan pada citra sistem harus ditulis tanpa pengetahuan tentang kustomisasi vendor tertentu. Kebijakan mengenai antarmuka tertentu di AOSP dengan demikian diekspos melalui atribut di sistem/kebijakan/publik sehingga kebijakan vendor dapat memilih untuk kebijakan sistem masa depan yang menggunakan atribut ini. Namun, ekstensi atribut di system/sepolicy/public tidak didukung , jadi semua kebijakan yang mendikte bagaimana komponen sistem berinteraksi dengan komponen vendor baru (dan yang tidak ditangani oleh atribut yang sudah ada di AOSP system/sepolicy/public ) harus ada di device/ manufacturer / device-name /sepolicy . Ini berarti bahwa tipe sistem tidak dapat mengubah akses yang diizinkan ke tipe vendor sebagai bagian dari OTA kerangka saja.