Perintah VPN Anda berjalan tanpa hak istimewa; layanannya tidak

Perintah VPN berjalan sebagai pengguna Anda, tidak ada kata sandi yang muncul, dan terowongan terangkat. Urutan itu terasa seperti operasi tanpa hak istimewa, dan biasanya memang bukan. Layanan terpisah melakukan perubahan jaringan, dan pertanyaan menariknya adalah apa yang akan dilakukan layanan itu bagi pemanggil yang belum diverifikasinya. Menghitung permintaan kata sandi tidak memberi tahu Anda apa pun tentang batas itu.

Antarmuka, mekanisme, dan pemeriksaan

Antarmuka menerima permintaan: sambung, putuskan, pilih profil. Mekanisme memiliki operasi jaringan: membuat antarmuka, mengubah rute, menerapkan filter. Pemeriksaan otorisasi memutuskan apakah pemanggil ini boleh meminta tindakan ini. Ketiganya dapat tersebar di biner, pembantu, dan layanan sistem, dan pengguna hanya melihat yang pertama.

Peran dapat hidup dalam satu biner, dalam dua proses, atau dalam klien dan layanan sistem, dan perintah yang dilihat pengguna jarang mengungkapkan yang mana. Ikon baki dan daemon sistem dapat terlihat seperti satu aplikasi padahal berjalan dengan kewenangan yang sangat berbeda. Hak istimewa saat pemasangan dan hak istimewa saat permintaan juga dua hal berbeda. Pemasang yang berjalan sebagai root dapat meninggalkan layanan yang mendengarkan permintaan berikutnya, jauh setelah pengelola paket selesai. Layanan itulah yang memegang kewenangan, bukan perintah yang Anda ketik.

Delegasi adalah rancangan yang normal

Mendelegasikan pekerjaan jaringan berhak istimewa ke layanan adalah arsitektur yang wajar. Itu menjaga aplikasi biasa tanpa hak istimewa dan memusatkan operasi yang membutuhkan kehati-hatian. Rancangan itu hanya berbayar ketika layanan juga memeriksa siapa yang bertanya dan untuk apa. Tanpa pemeriksaan itu, itu hanya pintu yang lebih lebar.

NetworkManager adalah contoh konkret di Linux. Panduan konfigurasi-nya menjelaskan bagaimana PolicyKit mengotorisasi permintaan non-root dalam penyiapan bawaan. Itu menunjukkan otorisasi yang didelegasikan dalam produk nyata. Itu tidak membuktikan bahwa setiap klien komersial memakai NetworkManager, dan tidak menjelaskan jalur soket atau kebijakan vendor tertentu.

Polanya adalah delegasi dengan kebijakan di belakangnya. Contohnya adalah satu implementasi pola itu, bukan yang universal.

Baca batasnya, bukan permintaannya

Temukan layanannya, pemilik konfigurasinya, dan antarmuka lokal yang dipakai frontend. Lalu tanyakan pengguna mana yang boleh meminta operasi mana. Bisa menaikkan dan menurunkan satu profil tersimpan bukan izin yang sama dengan memuat konfigurasi yang tidak pernah ditinjau operator. Perbedaannya adalah seluruh pertanyaan keamanan.

Mulailah dari pengelola layanan dan dari pandangan klien itu sendiri atas izinnya. Perintah di bawah menunjukkan apakah daemon berjalan, apa yang boleh diminta pemanggil darinya, dan apa yang dibuka daemon di bawah direktori runtimnya.

systemctl status NetworkManager
nmcli general permissions
ls -l /run/NetworkManager

Tanyakan juga apa yang dipengaruhi operasi itu. Item menu yang tampak pribadi dapat mengubah rute dan DNS untuk seluruh mesin, yang berarti dapat mengganggu sesi pengguna lain. Radius dampaknya termasuk dalam tinjauan yang sama dengan izin, dan biasanya itulah yang menentukan apakah layanan perlu peran yang lebih sempit.

Perbaiki izin dengan cara yang didukung

Menjadikan soket kendali yang terlindungi dapat ditulis semua orang, atau menambahkan akun ke grup administratif yang luas, menghapus kesalahan izin dan menciptakan yang lebih besar. Kesalahan itu adalah satu-satunya yang memberi tahu Anda bahwa batas itu ada. Gunakan proses keanggotaan atau otorisasi yang terdokumentasi, termasuk penyegaran sesi yang dibutuhkannya. Keanggotaan grup sering hanya berlaku untuk sesi masuk baru, karena itulah perubahan bisa tampak tidak melakukan apa pun sampai masuk berikutnya.

Jika produk membuka peran yang lebih sempit untuk operasi itu, utamakan itu daripada pemberian menyeluruh. Tuliskan peran yang dipilih dan pemiliknya di samping nama layanan.

Seperti apa pemisahan yang baik

Aplikasi biasa tetap tanpa hak istimewa, layanan hanya melakukan penyiapan yang dirancang untuknya, dan setiap pemanggil diperiksa terhadap kebijakan yang dimiliki seseorang. Itu rancangan yang bisa dipertahankan. Itu juga dapat diaudit, karena kebijakan itu punya nama yang melekat. Apa pun yang lebih besar pantas mendapat pengecualian tertulis, bukan perubahan izin yang senyap.

Mode kegagalannya adalah layanan yang menjalankan permintaan apa pun dari pengguna lokal mana pun karena antarmukanya nyaman. Dari sisi pengguna tampak sama, dan itu membawa kewenangan yang jauh lebih besar. Uji satu permintaan yang ditolak, bukan hanya yang berhasil. Penolakan yang datang dari kebijakan adalah bukti bahwa kebijakan itu ada.