Google berkomitmen untuk memajukan ekuitas ras untuk komunitas kulit hitam. Lihat bagaimana.
Halaman ini diterjemahkan oleh Cloud Translation API.
Switch to English

Menyesuaikan SELinux

Setelah Anda mengintegrasikan tingkat dasar fungsi SELinux dan menganalisis hasilnya secara menyeluruh, Anda dapat menambahkan pengaturan kebijakan Anda sendiri untuk mencakup penyesuaian Anda ke sistem operasi Android. Kebijakan ini masih 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 melanggar implementasi Android SELinux dan aplikasi yang diaturnya. Ini termasuk aplikasi pihak ketiga yang mungkin perlu ditingkatkan agar patuh dan operasional. Aplikasi harus tidak memerlukan modifikasi untuk terus berfungsi pada perangkat yang diaktifkan SELinux.

Saat memulai menyesuaikan SELinux, ingat untuk:

  • Tulis kebijakan SELinux untuk semua daemon baru
  • Gunakan domain yang telah ditentukan sebelumnya kapan saja sesuai
  • Tetapkan domain untuk setiap proses yang muncul sebagai layanan init
  • Biasakan diri dengan makro sebelum menulis kebijakan
  • Kirim perubahan pada kebijakan inti ke AOSP

Dan ingatlah untuk tidak:

  • Buat kebijakan yang tidak kompatibel
  • Izinkan kustomisasi kebijakan pengguna akhir
  • Izinkan kustomisasi kebijakan MDM
  • Menakut-nakuti pengguna dengan pelanggaran kebijakan
  • Tambahkan backdoors

Lihat bagian Fitur Keamanan Kernel pada dokumen Definisi Kompatibilitas Android untuk persyaratan spesifik.

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 diharuskan mengubah pengaturan SELinux dengan cara apa pun. Jika Anda menyesuaikan pengaturan SELinux, berhati-hatilah untuk tidak merusak aplikasi yang ada. Untuk memulai:

  1. Gunakan kernel Android terbaru .
  2. Adopsi prinsip hak istimewa yang paling rendah .
  3. Alamat hanya tambahan Anda sendiri untuk Android. Kebijakan default berfungsi dengan basis kode Proyek Open Source Android secara otomatis.
  4. Mengelompokkan komponen perangkat lunak ke dalam modul yang melakukan tugas tunggal.
  5. Buat kebijakan SELinux yang mengisolasi tugas-tugas itu dari fungsi yang tidak terkait.
  6. Masukkan kebijakan-kebijakan tersebut dalam file *.te (ekstensi untuk file sumber kebijakan SELinux) di dalam direktori /device/ manufacturer / device-name /sepolicy dan gunakan variabel BOARD_SEPOLICY untuk memasukkannya dalam build Anda.
  7. Buat domain baru permisif pada awalnya. Ini dilakukan dengan menggunakan deklarasi permisif dalam file .te domain.
  8. Analisis hasil dan saring definisi domain Anda.
  9. Hapus deklarasi permisif ketika tidak ada lagi penolakan yang muncul di build userdebug.

Setelah Anda mengintegrasikan perubahan kebijakan SELinux Anda, tambahkan langkah ke alur kerja pengembangan Anda untuk memastikan kompatibilitas SELinux ke depan. Dalam proses pengembangan perangkat lunak yang ideal, kebijakan SELinux berubah hanya 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 kebijakan terkait yang dibuat oleh OEM, sebelum mengaktifkan mode penegakan.

Untuk mencegah masalah yang tidak perlu, lebih baik overbroad dan over-compatible daripada terlalu membatasi dan tidak kompatibel, yang mengakibatkan fungsi perangkat rusak. Sebaliknya, jika perubahan Anda akan menguntungkan orang lain, Anda harus mengirimkan modifikasi ke kebijakan SELinux default sebagai tambalan . Jika tambalan diterapkan pada kebijakan keamanan default, Anda tidak perlu melakukan perubahan ini pada setiap rilis Android baru.

Contoh pernyataan kebijakan

SELinux didasarkan pada bahasa komputer M4 dan karenanya mendukung berbagai makro untuk menghemat waktu.

Pada contoh berikut, semua domain diberikan akses untuk membaca 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 SELinux *_file_perms macro (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:

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:

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

Di baris kedua, DHCP diidentifikasi sebagai domain permisif.

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

Pada 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.

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

Blok terakhir dari contoh dimulai dengan allow dhcp netd:fd use; menggambarkan bagaimana aplikasi dapat diizinkan untuk berinteraksi satu sama lain. Kebijakan tersebut mengatakan DHCP dan netd dapat berkomunikasi satu sama lain melalui deskriptor file, file FIFO, soket datagram, dan soket stream 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

LEBIH

DAN LEBIH BANYAK

tidak pernah mengizinkan aturan

SELinux neverallow rules melarang perilaku yang seharusnya tidak pernah terjadi. Dengan pengujian kompatibilitas , SELinux neverallow rules sekarang diberlakukan di seluruh perangkat.

Pedoman berikut dimaksudkan untuk membantu produsen menghindari kesalahan terkait dengan aturan tidak neverallow selama penyesuaian. Nomor aturan yang digunakan di sini sesuai dengan Android 5.1 dan dapat berubah sewaktu-waktu.

Aturan 48: neverallow { domain -debuggerd -vold -dumpstate -system_server } self:capability sys_ptrace;
Lihat halaman manual untuk ptrace . Kemampuan sys_ptrace memberikan kemampuan untuk melakukan ptrace proses apa pun, yang memungkinkan banyak kontrol atas proses lain dan seharusnya hanya dimiliki oleh komponen sistem yang ditunjuk, yang diuraikan dalam aturan. Kebutuhan akan kemampuan ini sering menunjukkan keberadaan sesuatu yang tidak dimaksudkan untuk bangunan yang dibangun 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 dieksekusi, yang memungkinkan jaminan keamanan berkat mekanisme seperti boot yang terverifikasi. Seringkali, solusi terbaik ketika menghadapi masalah dengan aturan neverallow ini adalah memindahkan kode yang menyinggung ke partisi /system .

Menyesuaikan SEPolicy di Android 8.0+

Bagian ini memberikan panduan untuk kebijakan vendor SELinux di Android 8.0 dan lebih tinggi, termasuk detail tentang Android Open Source Project (AOSP) ekstensi SEPolicy dan SEPolicy. Untuk informasi lebih lanjut tentang bagaimana kebijakan SELinux tetap kompatibel di seluruh partisi dan versi Android, lihat Kompatibilitas .

Penempatan kebijakan

Di Android 7.0 dan sebelumnya, 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 pada gambar vendor.

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

  • sistem / sepolicy / publik . Termasuk kebijakan yang diekspor untuk digunakan dalam kebijakan khusus vendor. Semuanya masuk ke infrastruktur kompatibilitas Android 8.0. Kebijakan publik dimaksudkan untuk bertahan di seluruh rilis sehingga Anda dapat memasukkan apa saja /public dalam kebijakan khusus Anda. Karena itu, jenis kebijakan yang dapat ditempatkan di /public lebih dibatasi. Pertimbangkan ini API kebijakan ekspor platform: Apa pun yang berkaitan dengan antarmuka antara /system dan /vendor berada di sini.
  • sistem / sepolicy / pribadi . Termasuk kebijakan yang diperlukan untuk berfungsinya citra sistem, tetapi kebijakan gambar vendor mana yang tidak memiliki pengetahuan.
  • sistem / sepolicy / vendor . Termasuk kebijakan untuk komponen yang masuk /vendor tetapi ada di pohon platform inti (bukan direktori khusus perangkat). Ini adalah artefak dari perbedaan sistem bangun antara perangkat dan komponen global; secara konsep ini adalah bagian dari kebijakan khusus perangkat yang dijelaskan di bawah ini.
  • perangkat / manufacturer / device-name / sepolicy . Termasuk kebijakan khusus perangkat. Juga termasuk penyesuaian perangkat dengan kebijakan, yang di Android 8.0 dan lebih tinggi sesuai dengan kebijakan untuk komponen pada gambar vendor.

Skenario kebijakan yang didukung

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

ekstensi hanya vendor-gambar

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

Seperti halnya perangkat yang diluncurkan dengan versi Android sebelumnya, tambahkan kustomisasi khusus device/ manufacturer / device-name /sepolicy 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 kerangka kerja OTA saja, dan akan hadir dalam kebijakan gabungan pada perangkat dengan gambar sistem AOSP referensi.

dukungan vendor-image untuk bekerja dengan AOSP

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

Seperti halnya perangkat yang diluncurkan dengan versi Android sebelumnya, lakukan kustomisasi khusus device/ manufacturer / device-name /sepolicy 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 baru, tunduk pada batasan neverallow disediakan. Seperti halnya kasus khusus vendor, kebijakan baru di sini tidak akan diperbarui sebagai bagian dari kerangka kerja OTA saja dan akan hadir dalam kebijakan gabungan pada perangkat dengan gambar sistem AOSP referensi.

ekstensi sistem-gambar-saja

Contoh : Menambahkan layanan baru (terdaftar dengan servicemanager) yang diakses hanya oleh proses lain dari gambar 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 itu tidak perlu berinteraksi dengan komponen baru pada gambar vendor (khususnya, proses atau objek tersebut harus berfungsi penuh tanpa kebijakan dari gambar vendor) . Kebijakan yang diekspor oleh system/sepolicy/public tersedia di sini seperti halnya untuk ekstensi hanya-gambar-vendor. Kebijakan ini merupakan bagian dari gambar sistem dan dapat diperbarui dalam kerangka kerja hanya OTA, tetapi tidak akan hadir ketika menggunakan gambar sistem AOSP referensi.

ekstensi vendor-image yang melayani komponen AOSP yang diperluas

Contoh: HAL baru, non-AOSP untuk digunakan oleh klien diperluas yang juga ada dalam gambar sistem AOSP (seperti perpanjangan system_server).

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

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

ekstensi sistem-gambar yang hanya mengakses antarmuka AOSP

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

Ini mirip dengan contoh ekstensi hanya gambar sistem , kecuali komponen sistem baru dapat berinteraksi di seluruh antarmuka system/vendor . Kebijakan untuk komponen sistem baru harus masuk dalam system/sepolicy/private , yang dapat diterima asalkan melalui antarmuka yang telah ditetapkan oleh AOSP dalam system/sepolicy/public (yaitu jenis dan atribut yang diperlukan untuk fungsi ada di sana). Sementara kebijakan dapat dimasukkan dalam kebijakan khusus perangkat, itu tidak akan dapat menggunakan system/sepolicy/private lain system/sepolicy/private jenis system/sepolicy/private atau perubahan (dengan cara apa pun yang mempengaruhi kebijakan) sebagai hasil dari pembaruan kerangka kerja saja. Kebijakan dapat diubah dalam kerangka kerja hanya OTA, tetapi tidak akan hadir ketika menggunakan gambar sistem AOSP (yang tidak akan memiliki komponen sistem baru juga).

ekstensi vendor-image yang melayani komponen sistem baru

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

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

Perlu diingat bahwa setiap penambahan ke system/sepolicy/public menambah kompleksitas dengan memaparkan jaminan kompatibilitas baru yang harus dilacak dalam file pemetaan dan yang tunduk pada batasan lainnya. Hanya tipe baru dan aturan system/sepolicy/public sesuai yang dapat ditambahkan dalam system/sepolicy/public ; atribut dan pernyataan kebijakan lainnya tidak didukung. Selain itu, tipe publik baru tidak dapat digunakan untuk secara langsung memberi label objek dalam kebijakan /vendor .

Skenario kebijakan yang tidak didukung

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

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

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

Mirip dengan sistem baru (non-AOSP) dan interaksi komponen vendor , kecuali tipe sistem baru diperkenalkan dalam kerangka kerja-saja OTA. Meskipun tipe baru dapat ditambahkan ke kebijakan dalam 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 (mis. Atribut hal_foo ) tetapi karena ekstensi mitra atribut tidak didukung dalam system/sepolicy/public , metode ini tidak tersedia untuk kebijakan vendor. Akses harus disediakan oleh jenis publik yang sudah ada sebelumnya.

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

Kebijakan pada gambar sistem harus ditulis tanpa sepengetahuan kustomisasi vendor tertentu. Kebijakan mengenai antarmuka spesifik dalam AOSP dengan demikian diekspos melalui atribut dalam sistem / sepolicy / publik sehingga kebijakan vendor dapat ikut serta dalam kebijakan sistem masa depan yang menggunakan atribut ini. Namun, ekstensi atribut dalam system/sepolicy/public tidak didukung , sehingga semua kebijakan menentukan bagaimana komponen sistem berinteraksi dengan komponen vendor baru (dan yang tidak ditangani oleh atribut yang sudah ada dalam system/sepolicy/public 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 kerangka kerja khusus-OTA.