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

Halaman ini diterjemahkan oleh Cloud Translation API.

Konsep SELinux

Tinjau halaman ini untuk memahami konsep SELinux.

Kontrol akses wajib

Security Enhanced Linux (SELinux), adalah sistem kontrol akses wajib (MAC) untuk sistem operasi Linux. Sebagai sistem MAC, ini berbeda dari Linux sistem kontrol akses diskresi (DAC) yang sudah dikenal. Dalam sistem DAC, sebuah konsep kepemilikan, di mana pemilik sumber daya tertentu mengontrol akses izin akses yang terkait dengannya. Hal ini umumnya bersifat umum dan subjektif, terhadap eskalasi akses yang tidak diinginkan. Namun, sistem MAC berkonsultasi dengan otoritas untuk mengambil keputusan atas semua upaya akses.

SELinux telah diimplementasikan sebagai bagian dari Linux Security Module (LSM) , yang mengenali beragam objek kernel, dan tindakan sensitif yang ditampilkan. Pada titik di mana masing-masing tindakan ini akan fungsi hook LSM akan dipanggil untuk menentukan apakah tindakan harus diizinkan berdasarkan informasi untuknya yang disimpan dalam keamanan. SELinux menyediakan implementasi untuk {i>hook<i} ini dan untuk mengelola objek keamanan ini, yang digabungkan dengan kebijakannya sendiri, untuk menentukan keputusan akses.

Bersama dengan langkah keamanan Android lainnya, kontrol akses Android kebijakan ini sangat membatasi potensi kerusakan pada komputer yang disusupi dan menggunakan akun layanan. Menggunakan alat seperti akses wajib dan diskresi Android memberi Anda struktur untuk memastikan perangkat lunak Anda hanya berjalan seminimal mungkin tingkat hak istimewa yang tinggi. Hal ini mengurangi dampak serangan dan mengurangi kemungkinan proses yang salah yang menimpa atau bahkan mengirimkan data.

Di Android 4.3 dan yang lebih tinggi, SELinux menyediakan kontrol akses wajib (MAC) menaungi lingkungan kontrol akses diskresi (DAC) tradisional. Sebagai {i>instance<i}, perangkat lunak biasanya harus dijalankan sebagai akun pengguna {i>root<i} untuk menulis ke perangkat blok. Di lingkungan Linux berbasis DAC tradisional, jika pengguna {i>root<i} disusupi sehingga pengguna dapat menulis ke setiap perangkat blok mentah. Namun, SELinux dapat digunakan untuk memberi label perangkat ini sehingga proses menetapkan {i>root<i} hanya dapat menulis ke resource yang ditentukan dalam kebijakan terkait. Di sini proses tersebut tidak dapat menimpa data dan setelan sistem di luar perangkat blok mentah tertentu.

Lihat Kasus Penggunaan untuk mengetahui lebih banyak contoh ancaman dan cara mengatasinya dengan SELinux.

Tingkat penegakan kebijakan

SELinux dapat diimplementasikan dalam berbagai mode:

Permisif - Kebijakan keamanan SELinux tidak diterapkan, hanya dicatat ke dalam log.
Menegakkan - Kebijakan keamanan diterapkan dan dicatat dalam log. Gagal muncul sebagai error EPERM.

Pilihan ini bersifat biner dan menentukan apakah kebijakan Anda yang mengambil tindakan atau hanya memungkinkan Anda mengumpulkan potensi kegagalan. Permisif sangat berguna selama terlepas dari implementasi layanan.

Jenis, atribut, dan aturan

Android mengandalkan komponen Type Enforcement (TE) dari SELinux untuk lebih lanjut. Ini berarti bahwa semua objek (seperti, file, proses, atau soket) memiliki type yang terkait dengannya. Misalnya, secara {i>default<i}, sebuah aplikasi akan memiliki jenis untrusted_app. Untuk suatu proses, jenisnya juga yang dikenal sebagai domain. Hal ini dimungkinkan untuk menganotasi sebuah jenis dengan satu atau banyak atribut. Atribut berguna untuk merujuk ke beberapa jenis secara bersamaan.

Objek dipetakan ke class (misalnya, file, direktori, tautan simbolis, soket) dan berbagai jenis akses untuk setiap class diwakili oleh izin. Misalnya, izin open ada untuk class tersebut file. Sementara jenis dan atribut diperbarui secara teratur sebagai bagian dari kebijakan Android SELinux, izin dan kelas ditentukan secara statis jarang diperbarui sebagai bagian dari rilis Linux baru.

Aturan kebijakan berbentuk: allow source target:class permissions; dalam hal ini:

Sumber - Jenis (atau atribut) subjek aturan. Siapa yang meminta akses?
Target - Jenis (atau atribut) objek. Akses diminta ke mana?
Class - Jenis objek (misalnya file, socket) yang diakses.
Izin - Operasi (atau serangkaian operasi) (misalnya baca, tulis) yang dilakukan.

Contoh aturan adalah:

allow untrusted_app app_data_file:file { read write };

Hal ini menunjukkan bahwa aplikasi diizinkan untuk membaca dan menulis file yang diberi label app_data_file. Ada jenis lain untuk aplikasi. Sebagai , isolated_app digunakan untuk layanan aplikasi dengan isolatedProcess=true dalam manifesnya. Alih-alih mengulangi aturan untuk kedua jenis tersebut, Android menggunakan atribut bernama appdomain untuk semua jenis yang mencakup aplikasi:

# Associate the attribute appdomain with the type untrusted_app.
typeattribute untrusted_app, appdomain;

# Associate the attribute appdomain with the type isolated_app.
typeattribute isolated_app, appdomain;

allow appdomain app_data_file:file { read write };

Ketika aturan ditulis yang menentukan nama atribut, nama itu akan secara otomatis diperluas ke daftar domain atau jenis yang terkait dengan . Beberapa atribut penting adalah:

domain - atribut yang terkait dengan semua jenis proses,
file_type - atribut yang dikaitkan dengan semua jenis file.

Makro

Khususnya untuk akses file, ada banyak jenis izin akses pertimbangkan. Misalnya, izin read tidak cukup untuk membuka atau panggil stat di dalamnya. Untuk menyederhanakan definisi aturan, Android menyediakan kumpulan makro untuk menangani kasus yang paling umum. Misalnya, untuk untuk menyertakan izin yang tidak ada seperti open, aturan di atas dapat ditulis ulang sebagai:

allow appdomain app_data_file:file rw_file_perms;

Lihat global_macros dan te_macros untuk melihat lebih banyak contoh tentang makro yang berguna. Makro harus digunakan jika memungkinkan untuk membantu mengurangi kemungkinan kegagalan akibat penolakan pada izin akses.

Setelah ditentukan, jenis perlu dikaitkan dengan file atau proses yang diwakilinya. Lihat Mengimplementasikan SELinux untuk detail lebih lanjut tentang bagaimana asosiasi ini dilakukan. Untuk informasi selengkapnya tentang aturan, lihat Notebook SELinux.

Konteks dan Kategori Keamanan

Saat melakukan debug pada kebijakan SELinux atau memberi label file (melalui file_contexts atau saat menghubungi ls -Z), Anda mungkin datang di seluruh konteks keamanan (juga dikenal sebagai label). Sebagai contoh: u:r:untrusted_app:s0:c15,c256,c513,c768. Konteks keamanan memiliki format: user:role:type:sensitivity[:categories]. Anda biasanya dapat mengabaikan Kolom user, role, dan sensitivity dari konteks (lihat Kekhususan). type dijelaskan di bagian sebelumnya. categories adalah bagian dari kebijakan Multi-Level Security (MLS) di SELinux. Sejak Android S, kategori digunakan untuk:

Isolasi data aplikasi dari akses aplikasi lain,
Pisahkan data aplikasi dari satu pengguna fisik ke pengguna fisik lainnya.

Kekhususan

Android tidak menggunakan semua fitur yang disediakan oleh SELinux. Saat membaca dokumentasi eksternal, ingatlah hal-hal berikut:

Sebagian besar kebijakan dalam AOSP ditentukan menggunakan Bahasa Kebijakan Kernel. Ada beberapa pengecualian terkait penggunaan Common Intermediate Language (CIL).
Pengguna SELinux tidak digunakan. Satu-satunya yang ditentukan pengguna adalah u Jika perlu, pengguna fisik akan diwakili menggunakan kolom kategori dalam konteks keamanan.
roles SELinux dan Role-Based Access Control (RBAC) tidak digunakan. Dua peran default telah ditetapkan dan digunakan: r untuk subjek dan object_r untuk objek.
Sensitivitas SELinux tidak digunakan. Sensitivitas s0 default selalu ditetapkan.
Boolean SELinux tidak digunakan. Setelah kebijakan dibuat untuk perangkat, kebijakan tidak bergantung pada status perangkat. Hal ini menyederhanakan audit dan {i>debugging<i} terhadap kebijakan.