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 sistem kontrol akses diskresioner (DAC) Linux yang sudah dikenal. Dalam sistem DAC, ada konsep kepemilikan, di mana pemilik sumber daya tertentu mengontrol izin akses yang terkait dengannya. Ini umumnya berbutir kasar dan tunduk pada eskalasi hak istimewa yang tidak diinginkan. Sistem MAC, bagaimanapun, berkonsultasi dengan otoritas pusat untuk keputusan pada semua upaya akses.
SELinux telah diimplementasikan sebagai bagian dari kerangka Linux Security Module (LSM), yang mengenali berbagai objek kernel, dan tindakan sensitif yang dilakukan pada objek tersebut. Pada titik di mana setiap tindakan ini akan dilakukan, fungsi pengait LSM dipanggil untuk menentukan apakah tindakan tersebut harus diizinkan berdasarkan informasi yang disimpan dalam objek keamanan buram atau tidak. SELinux menyediakan implementasi untuk kait dan pengelolaan objek keamanan ini, yang digabungkan dengan kebijakannya sendiri, untuk menentukan keputusan akses.
Bersama dengan tindakan keamanan Android lainnya, kebijakan kontrol akses Android sangat membatasi potensi kerusakan mesin dan akun yang disusupi. Menggunakan alat seperti kontrol akses opsional dan wajib Android memberi Anda struktur untuk memastikan perangkat lunak Anda hanya berjalan pada tingkat hak istimewa minimum. Ini mengurangi efek serangan dan mengurangi kemungkinan proses yang salah menimpa atau bahkan mentransmisikan data.
Di Android 4.3 dan yang lebih tinggi, SELinux menyediakan payung kontrol akses wajib (MAC) di atas lingkungan kontrol akses diskresioner (DAC) tradisional. Misalnya, perangkat lunak biasanya harus dijalankan sebagai akun pengguna root untuk menulis ke perangkat blok mentah. Dalam lingkungan Linux berbasis DAC tradisional, jika pengguna root dikompromikan, pengguna dapat menulis ke setiap perangkat blok mentah. Namun, SELinux dapat digunakan untuk memberi label pada perangkat ini sehingga proses yang diberi hak akses root hanya dapat menulis ke perangkat yang ditentukan dalam kebijakan terkait. Dengan cara ini, proses tidak dapat menimpa data dan pengaturan sistem di luar perangkat blok mentah tertentu.
Lihat Kasus Penggunaan untuk lebih banyak contoh ancaman dan cara mengatasinya dengan SELinux.
Tingkat penegakan
SELinux dapat diimplementasikan dalam berbagai mode:
- Permisif - Kebijakan keamanan SELinux tidak diterapkan, hanya dicatat.
- Menegakkan - Kebijakan keamanan diberlakukan dan dicatat. Kegagalan muncul sebagai kesalahan EPERM.
Pilihan ini biner dan menentukan apakah kebijakan Anda mengambil tindakan atau hanya memungkinkan Anda untuk mengumpulkan potensi kegagalan. Permisif sangat berguna selama implementasi.
Jenis, atribut, dan aturan
Android mengandalkan komponen Type Enforcement (TE) dari SELinux untuk kebijakannya. Ini berarti bahwa semua objek (seperti, file, proses, atau soket) memiliki tipe yang terkait dengannya. Misalnya, secara default, aplikasi akan memiliki tipe untrusted_app
. Untuk suatu proses, tipenya juga dikenal sebagai domainnya . Hal ini dimungkinkan untuk membubuhi keterangan jenis dengan satu atau banyak atribut . Atribut berguna untuk merujuk ke beberapa tipe sekaligus.
Objek dipetakan ke kelas (misalnya, file, direktori, tautan simbolik, soket) dan berbagai jenis akses untuk setiap kelas diwakili oleh izin . Misalnya, izin open
ada untuk file
kelas . Meskipun tipe dan atribut diperbarui secara berkala sebagai bagian dari kebijakan Android SELinux, izin dan kelas ditentukan secara statis dan jarang diperbarui sebagai bagian dari rilis Linux baru.
Aturan kebijakan datang dalam bentuk: allow source target : class permissions ;
di mana:
- Sumber - Jenis (atau atribut) subjek aturan. Siapa yang meminta akses?
- Target - Jenis (atau atribut) objek. Untuk apa akses yang diminta?
- Kelas - Jenis objek (misalnya file, socket) yang sedang diakses.
- Izin - Operasi (atau serangkaian operasi) (misalnya membaca, menulis) sedang dilakukan.
Contoh aturannya adalah:
allow untrusted_app app_data_file:file { read write };
Ini mengatakan bahwa aplikasi diizinkan untuk membaca dan menulis file berlabel app_data_file
. Ada jenis lain untuk aplikasi. Misalnya, isolated_app
digunakan untuk layanan aplikasi dengan isolatedProcess=true
dalam manifesnya. Alih-alih mengulangi aturan untuk kedua jenis, 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 secara otomatis diperluas ke daftar domain atau jenis yang terkait dengan atribut. Beberapa atribut penting adalah:
-
domain
- atribut yang terkait dengan semua jenis proses, -
file_type
- atribut yang terkait dengan semua jenis file.
makro
Khusus untuk akses file, ada banyak jenis izin yang perlu dipertimbangkan. Misalnya, izin read
tidak cukup untuk membuka file atau memanggil stat
di atasnya. Untuk menyederhanakan definisi aturan, Android menyediakan satu set makro untuk menangani kasus yang paling umum. Misalnya, untuk menyertakan izin yang hilang seperti open
, aturan di atas dapat ditulis ulang sebagai:
allow appdomain app_data_file:file rw_file_perms;
Lihat file global_macros
dan te_macros
untuk contoh makro yang berguna lainnya. Makro harus digunakan bila memungkinkan untuk membantu mengurangi kemungkinan kegagalan karena penolakan izin terkait.
Setelah tipe didefinisikan, itu perlu dikaitkan dengan file atau proses yang diwakilinya. Lihat Menerapkan SELinux untuk detail lebih lanjut tentang bagaimana asosiasi ini dilakukan. Untuk informasi lebih lanjut tentang aturan, lihat Notebook SELinux .
Konteks dan Kategori Keamanan
Saat men-debug kebijakan SELinux atau melabeli file (melalui file_contexts
atau saat menjalankan ls -Z
), Anda mungkin menemukan konteks keamanan (juga dikenal sebagai label ). Misalnya: u:r:untrusted_app:s0:c15,c256,c513,c768
. Konteks keamanan memiliki format: user:role:type:sensitivity[:categories]
. Anda biasanya dapat mengabaikan bidang user
, role
dan sensitivity
dari suatu konteks (lihat Specificity ). Bidang type
dijelaskan di bagian sebelumnya. categories
adalah bagian dari dukungan Multi-Level Security (MLS) di SELinux. Sejak Android S, kategori digunakan untuk:
- Mengisolasi data aplikasi dari akses oleh aplikasi lain,
- Pisahkan data aplikasi dari satu pengguna fisik ke pengguna lainnya.
Kekhususan
Android tidak menggunakan semua fitur yang disediakan oleh SELinux. Saat membaca dokumentasi eksternal, ingatlah poin-poin ini:
- Sebagian besar kebijakan di AOSP didefinisikan menggunakan Bahasa Kebijakan Kernel. Ada beberapa pengecualian untuk menggunakan Common Intermediate Language (CIL).
- Pengguna SELinux tidak digunakan. Satu-satunya pengguna yang ditentukan adalah
u
. Bila perlu, pengguna fisik diwakili menggunakan bidang kategori dari konteks keamanan. - Peran SELinux dan Kontrol Akses Berbasis Peran (RBAC) tidak digunakan. Dua peran default didefinisikan dan digunakan:
r
untuk subjek danobject_r
untuk objek. - Sensitivitas SELinux tidak digunakan. Sensitivitas
s0
default selalu disetel. - Boolean SELinux tidak digunakan. Setelah kebijakan dibuat untuk perangkat, kebijakan tersebut tidak bergantung pada status perangkat. Ini menyederhanakan audit dan debugging kebijakan.