Flatpak memungkinkan aplikasi desktop berjalan di sandbox yang terisolasi, yang secara signifikan meningkatkan keamanan karena mencegah aplikasi saling memengaruhi dan memengaruhi sistem host. Namun, dalam praktiknya, aplikasi tipikal masih perlu mengakses layanan dan data pengguna yang dibagikan di antara aplikasi lain dan host. Situasi ini telah diperbaiki dengan memperketat izin di sekitar mekanisme portal, meskipun ada masalah lama:Cara mengelola rahasia pengguna.
Pada artikel ini, kami menyajikan pendekatan kami untuk mengelola rahasia pengguna untuk aplikasi Flatpak. Sementara sebagian besar aplikasi secara transparan dapat memanfaatkan mekanisme yang diusulkan, beberapa aplikasi memerlukan modifikasi kode. Langkah-langkah migrasi juga disajikan.
Bagaimana rahasia dikelola di desktop Linux
Pada desktop Linux modern, sebagian besar rahasia—sandi, token, dan sebagainya, dengan atribut terkaitnya—dikelola secara terpusat oleh proses daemon gnome-keyring-daemon . Aplikasi mengakses daemon ini melalui Secret Service API, yang diekspos melalui D-Bus. Proses ini dilakukan di bawah tenda jika aplikasi menggunakan pustaka klien seperti libsecret .
Catatan: Untuk tujuan yang sama, ada perpustakaan bernama libgnome-keyring , yang sekarang sudah usang. Perhatikan bahwa, terlepas dari namanya, libgnome-keyring adalah proyek terpisah dari gnome-keyring , yang TIDAK usang dan masih mempertahankan peran sentral manajemen rahasia.
Di sisi daemon, rahasia disimpan di sistem file dan dienkripsi. Selain itu, daemon tidak lain adalah layanan penyimpanan normal, artinya aplikasi apa pun dapat menyimpan data pada "jalur" arbitrer yang juga dapat dilihat oleh aplikasi lain. Meskipun model ini cukup selama kami mempercayai semua aplikasi, model ini meniadakan salah satu tujuan keamanan Flatpak:Meningkatkan keamanan sistem desktop dengan mengisolasi aplikasi satu sama lain.
Oleh karena itu, ketika menginstal aplikasi Flatpak yang menggunakan API Layanan Rahasia, pengguna diminta untuk memberikan izin yang diperlukan untuk aplikasi tersebut. Pada contoh di bawah, Anda dapat melihat bahwa aplikasi memerlukan akses ke Secret Service API (org.freedesktop.secrets ). Jika pengguna tidak ingin mengizinkan aplikasi ini mengakses layanan, satu-satunya pilihan mereka adalah membatalkan instalasi:
$ flatpak install org.gnome.Epiphany
…
org.gnome.Epiphany permissions:
ipc network pulseaudio wayland
x11 dri file access [1] dbus access [2]
system dbus access [3]
[1] xdg-download, xdg-run/dconf, ~/.config/dconf:ro
[2] ca.desrt.dconf, org.freedesktop.Notifications, org.freedesktop.secrets
[3] org.freedesktop.GeoClue2
Proceed with these changes to the Default system installation? [Y/n]:
Ini jelas merupakan hasil yang tidak diinginkan.
Pendekatan penyimpanan lokal
Ide dasar untuk mengatasi masalah ini adalah menyimpan rahasia di sisi aplikasi, bukan di sisi host (gnome-keyring-daemon ). Praktik ini analog dengan pekerjaan baru-baru ini di GSettings, di mana aplikasi menyimpan data pengaturan dalam file lokal, bukan di dconf layanan berjalan di host.
Namun, ketika menyangkut rahasia, ada masalah bootstrap:Aplikasi harus mengenkripsi rahasia saat menyimpannya di file lokal, tetapi belum mengetahui kunci enkripsi. Untuk menyediakan aplikasi dengan kunci enkripsi, kami mengandalkan mekanisme portal Flatpak, yang berada di antara aplikasi dan host agar keduanya dapat berkomunikasi melalui antarmuka terbatas.
Kami juga menambahkan portal baru yang memungkinkan aplikasi mengambil kunci enkripsi. Pertama, aplikasi mengirimkan permintaan ke portal (permintaan berisi deskriptor file Unix tempat kunci enkripsi ditulis). Kemudian, portal mendelegasikan permintaan ke implementasi back-end di gnome-keyring-daemon , yang mengirimkan kunci enkripsi unik untuk aplikasi sandbox melalui deskriptor file.
Dengan kunci enkripsi yang diterima, aplikasi mengenkripsi rahasia dan menyimpannya di direktori data aplikasi (~/.var/app/$APPID/data/keyrings ), yaitu mengikat -dipasang dan dapat diakses dari host dan kotak pasir.
API libsecret
Rahasia lib project menyediakan dua set API yang berbeda. Salah satunya adalah API sederhana, dan yang lainnya adalah API lengkap. Yang pertama menyediakan operasi stateless yang lebih sederhana untuk mengambil dan menyimpan rahasia, sedangkan yang kedua menyediakan API berorientasi objek yang lebih lengkap yang memetakan antarmuka D-Bus ke C API.
Penyimpanan lokal hanya didukung di API sederhana. Jika aplikasi Anda sudah menggunakan API sederhana, maka mereka akan secara otomatis menggunakan penyimpanan lokal saat berjalan di bawah Flatpak. Jika tidak, untuk mengaktifkan penyimpanan lokal, aplikasi perlu di-porting ke API sederhana. Lihat patch migrasi di Epiphany sebagai contoh.
Memiliki perbedaan antara dua set API juga memungkinkan aplikasi untuk tidak menggunakan penyimpanan lokal. Misalnya, jika aplikasi Anda adalah pengelola kata sandi yang membutuhkan akses penuh ke keyrings pengguna, Anda dapat mengabaikan penyimpanan lokal dengan menggunakan API lengkap.
Format gantungan kunci
Meskipun idealnya, kita harus dapat menggunakan format keyring yang sama untuk penyimpanan lokal dan gnome-keyring-daemon , kami menyadari bahwa format gantungan kunci yang digunakan oleh gnome-keyring-daemon memiliki keterbatasan. Rahasia, termasuk atribut terkait, dienkripsi sebagai satu bongkahan, yang berarti bahwa mereka dapat menggunakan memori terkunci dalam jumlah yang tidak perlu. Selain itu, atribut di-hash tanpa kunci, artinya adalah mungkin untuk menebak rahasia mana yang disimpan dalam file.
Oleh karena itu, daripada menerapkan format ini di dua tempat, kami memutuskan untuk mendefinisikan versi baru dari format file keyring, dengan karakteristik berikut:Rahasia dienkripsi satu per satu dan hash atribut sekarang menjadi kode autentikasi pesan (MAC) di atas atribut.
Format baru ini didasarkan pada format serialisasi GVariant, kecuali untuk header, dan perubahan ini memungkinkan kita untuk menggunakan kembali sebagian besar kode untuk encoding, decoding, dan pencarian.
Apa selanjutnya untuk manajemen rahasia Flatpak
Patch yang diperlukan (saat ini) hanya tersedia di repositori Git dari komponen yang relevan (xdg-desktop-portal , gnome-keyring , dan rahasia ). Mereka akan disertakan dalam rilis berikutnya menjelang GNOME 3.36.
Jika Anda seorang pengembang, masih ada ruang untuk perbaikan di area ini. Di sinilah bantuan Anda akan sangat dihargai:
-
Kunci kunci sesi: Secret Service API mendukung keyring "sesi", yang hanya berlangsung selama sesi pengguna. Backend penyimpanan lokal belum mendukung fitur ini. Kode ini dapat diimplementasikan menggunakan keyring sesi di kernel Linux.
-
Aplikasi pengelolaan dan pencadangan: Rahasia aplikasi sekarang disimpan di beberapa lokasi, dan bukan hanya keyring host. Akan berguna jika ada alat untuk mengelola rahasia aplikasi dan membuat cadangan. Proses ini harus dimungkinkan dengan meningkatkan Seahorse GNOME untuk melihat rahasia aplikasi.
-
Portal akun online: Saat ini, sudah umum bagi aplikasi web untuk diintegrasikan dengan protokol pendelegasian akses berbasis web seperti OAuth 2.0. Protokol ini didukung oleh gnome-online-accounts , yang selanjutnya menggunakan gnome-keyring-daemon untuk menyimpan token. Antarmuka portal untuk akun online akan berguna untuk membatasi akses per aplikasi.
-
Adopsi yang lebih luas dari format keyring baru: Meskipun format baru memiliki beberapa keunggulan, saat ini hanya digunakan oleh libsecret di sisi aplikasi. Akan bermanfaat jika gnome-keyring-daemon di sisi host juga menggunakan format yang sama.
-
Mengeraskan proses penginstalan ulang: Secara default, file keyring aplikasi (~/.var/app/$APPID/data/keyrings ) tetap ada setelah pencopotan pemasangan, bersama dengan data lainnya. Persistensi ini rentan jika ID aplikasi digunakan kembali oleh penerbit yang tidak tepercaya. Saat ini, sebaiknya gunakan --delete-data opsi untuk memastikan bahwa data aplikasi tersebut dihapus. Prosedur ini dapat ditingkatkan jika ID penerbit dikaitkan dengan aplikasi.
Ringkasan
Artikel ini menyajikan mekanisme untuk menyediakan aplikasi Flatpak dengan rahasia pengguna. Mekanisme ini dirancang berdasarkan prinsip-prinsip berikut:
- Minimalkan antarmuka host.
- Biarkan aplikasi berinteraksi dengan host melalui portal Flatpak.
- Menyimpan data aplikasi dalam format data umum.
Meskipun mekanismenya transparan, selama Anda menggunakan libsecret , mekanisme ini hanya diaktifkan melalui libsecret API sederhana. Untuk transisi yang lebih mulus, sebaiknya migrasikan aplikasi ke API ini. Informasi lebih lanjut tentang latar belakang proyek dan alasan desain tersedia dalam presentasi GUADEC (slide, rekaman).