Layanan yang sedang digunakan oleh aplikasi perlu untuk dikontrol apakah pemanggil memiliki cukup hak istimewa (privilege) untuk memanggil masing-masing API. Dalam Tizen 2.2.x tingkat kontrol akses dilakukan dengan menggunakan kebijakan Smack yang sangat rinci dalam mekanisme IPC. Sejak Tizen 3.0 diperkenalkan kebijakan Smack 3-domain yang kompak, ada kebutuhan untuk mekanisme user-space yang melengkapi solusi. Ini adalah tempat untuk modul baru - Cynara.
Pada Tizen Developer Conference 2014 (TDCSF14) awal bulan ini di San Fransisco, Casey Schaufler dan Tomasz Świerczek memberikan presentasi tentang Cynara sebagai iterasi terbaru dari desain aplikasi keamanan untuk Tizen. Cynara adalah nama latin untuk tanaman Karczoch (Polandia).
Masalah mendasar yang menghinggapi Tizen dalam soal keamanan aplikasi adalah bahwa privilege telah ditentukan (dalam dokumen seperti W3C API yang didukung oleh Tizen untuk pengembangan aplikasi) sehubungan dengan layanan abstrak, seperti "telephony," daripada terhadap sistem komponen, seperti perangkat jaringan. Semua kebijakan keamanan berusaha untuk menjembatani kesenjangan ini dengan menulis seperangkat aturan dan pengecualian yang memetakan abstrak ke perangkat tertentu dan lokasi filesystem.
Dalam Tizen 2.2.x, sistem kebijakan keamanan (system security policy) ditulis sebagai seperangkat aturan Smack yang berusaha untuk mengisolasi aplikasi individual dari satu sama lain dengan membuat domain Smack terpisah untuk setiap aplikasi yang diinstal. Setiap paket aplikasi termasuk file manifest merinci file dan direktori yang diciptakannya, dan API privilege yang diminta. Pada waktu menginstal, system package manager akan membaca manifest, membuat domain untuk aplikasi baru, dan menetapkan label Smack untuk domain tersebut ke setiap file dan direktori yang diinstal. Hal ini juga akan menghitung aturan Smack baru yang sesuai dengan kombinasi aplikasi baru dari privilege dan domain Smack nya, dan menambahkan aturan-aturan untuk sistem kebijakan Smack.
Masalahnya adalah bahwa tingkat granularity mengakibatkan database policy (kebijakan) yang besar yang sulit untuk di-maintain. "Itu hampir sebesar policy SELinux," kata Schaufler. Tizen 3.0 mendatang akan mengubah semuanya secara dramatis, dimulai dengan hal yang sederhana: model kebijakan 3-domain yang menempatkan semua aplikasi yang diinstal pada satu tingkat privilege dasar, domain "User." Ini juga mendefinisikan domain "Floor" untuk sistem data statis yang tidak akan berubah dan domain "System" untuk layanan sistem dasar. Model ini mendefinisikan satu set aturan Smack yang sudah dikenal (seperti memungkinkan semua proses untuk mengakses /tmp dan /dev/null) yang tidak perlu ditambahkan ke setiap aplikasi yang diinstal.
Tim keamanan Tizen juga memutuskan untuk meninjau kembali bagaimana framework privilege dari aplikasi dilaksanakan, jadi mereka kemudian mengadakan pertemuan tatap muka di mana perwakilan dari Intel dan Samsung masing-masing menyajikan ide-ide mereka. Ketika dua perwakilan perusahaan ini pada dasarnya menyajikan desain yang sama, mereka memutuskan untuk bergerak maju dengan itu.
Inti dari rencana baru adalah kebijakan "service (layanan)" yang disebut Cynara. Setiap aplikasi yang diinstal masih harus memiliki label Smack yang unik sendiri (untuk melindungi file dan direktori pribadi), tapi bukan menciptakan satu set aturan Smack baru dan pengecualian untuk setiap privilege yang diminta aplikasi. Cynara menciptakan label dan privilege yang lebih pendek. Ini seperti pemetaan rumit antara set privilege yang tersedia dan resource sistem yang dibuat sebelumnya dan diimplementasikan dalam set aturan Smack, tetapi tidak tumbuh untuk setiap aplikasi baru.
Ketika aplikasi yang berjalan meminta akses ke komponen sistem (misalnya, membaca geolocation saat ini), komponen mengirimkan query cynara_check() ke Cynara, termasuk label Smack aplikasi, ID pengguna bahwa aplikasi berjalan sebagai, dan nama dari privilege yang diminta aplikasi. Layanan Cynara kembali baik untuk ALLOW (mengijinkan) atau DENY (menolak), berdasarkan apakah database kebijakan menunjukkan bahwa kombinasi dari label dan privilege Smack diperbolehkan. Kembali nilai-nilai lain juga didukung, seperti "Menanyakan kepada pengguna," tapi intinya adalah bahwa secara langsung pertanyaan ya-atau-tidak bisa segera dijawab.
Dengan demikian, Cynara API cukup sederhana, namun manfaatnya datang dengan me-maintain database sederhana dari privilege yang diperbolehkan. Dalam pengujian kinerja, waktu respon rata-rata berada di bawah 10ms, sebagai perbandingan lebih dari 30ms untuk beberapa solusi alternatif seperti PolKit. Dia juga mencatat bahwa kinerja PolKit buruk karena beberapa keputusan desain, seperti penggunaan dari D-Bus untuk komunikasi dan penggunaan dari JSON dan XML untuk menyimpan database policy. Format database itu berarti bahwa seluruh policy harus dibaca dan diuraikan untuk setiap panggilan; Cynara, sebaliknya, menyimpan database di SQLite.
Berdasarkan roadmap, peluncuran pertama Cynara kemungkinan akan tercapai pada akhir Juni, setelah adanta utilitas untuk memperbarui database policy. Tool-tool penting yang diperlukan untuk penyebaran akan bisa tercapai pada akhir Juli, setelah itu tim akan bekerja pada menambahkan asynchronous privilege-checking API dan mekanisme untuk menambahkan ekstensi untuk system security policy.
Comments
Post a Comment