Apakah keupayaan Linux yang diperlukan oleh proses VPN anda?
Persediaan antara muka, laluan, akses peranti dan soket biasa ialah keistimewaan berasingan. Namakan operasi yang gagal sebelum memberikan CAP_NET_ADMIN.
Daemon VPN memerlukan operasi rangkaian istimewa walaupun aplikasi biasa membuka soket keluar tanpa sebarang keistimewaan. Di celah itulah kebanyakan kesilapan keupayaan bermula: seseorang melihat ralat kebenaran, memberikan seluruh set, dan perkhidmatan berfungsi atas sebab yang tiada siapa dapat jelaskan kemudian. Panduan di bawah bermula daripada operasi yang gagal, memetakannya kepada satu kuasa, dan kemudian menyemak konteks tempat proses itu benar-benar berjalan. Berjalan sebagai root tanpa had ialah jawapan yang sah untuk sesetengah penggunaan, tetapi ia sepatutnya menjadi keputusan dan bukan nilai lalai.
Mulakan daripada operasi yang gagal
Baca ralat itu sebelum membaca tutorial. «Operasi tidak dibenarkan» pada perubahan antara muka, penolakan membuka nod peranti dan kegagalan bind pada port rendah ialah tiga masalah berbeza dengan tiga kebenaran berbeza. Jika proses bermula dan hanya gagal pada perubahan laluan pertama, itu juga memberitahu bahawa penciptaan antara muka sudah berjaya, yang menyempitkan jawapan dengan banyak.
Hasilkan semula kegagalan dengan perkhidmatan dihentikan, kemudian mulakannya di latar hadapan di bawah pengguna yang sama jika pelaksanaan membenarkannya. Ralat yang anda lihat lebih baik daripada baris log yang perlu diteka, dan ia menjelaskan perbezaan antara masalah keupayaan dan penolakan SELinux atau AppArmor.
Petakan setiap operasi kepada satu kuasa
Jadual ini ialah peta permulaan, bukan pengganti dokumentasi pelaksanaan:
| Operation | Usual authority | Watch for |
|---|---|---|
| Create or configure tun/tap | CAP_NET_ADMIN in the relevant namespace | Creating the device and opening it are separate steps |
| Add routes, rules, firewall entries | CAP_NET_ADMIN | Same capability, different namespace than you think |
| Open /dev/net/tun | Device permissions, not a capability | Group membership or a udev rule may be enough |
| Raw sockets | CAP_NET_RAW | Needed by some user-space tunnel implementations |
| Bind a port below 1024 | CAP_NET_BIND_SERVICE | Irrelevant for most modern tunnel ports |
Dua baris dalam jadual itu ialah yang orang keliru. Membuka /dev/net/tun ialah persoalan kebenaran fail; meminta kernel mengkonfigurasi apa yang anda buka ialah persoalan keupayaan. Memberikan CAP_NET_ADMIN tidak membaiki nod peranti yang tidak dapat dibaca oleh pengguna perkhidmatan anda, dan membaiki nod itu tidak memberi anda kuasa laluan. Semak kedua-duanya sebelum anda menukar mana-mana satu.
WireGuard dalam kernel dan program terowong ruang pengguna juga tidak mempunyai keperluan yang sama. Laluan modul kernel mengkonfigurasi antara muka sedia ada melalui netlink, manakala pelaksanaan ruang pengguna mungkin juga memerlukan peranti dan, bagi sesetengah pengangkutan, soket mentah.
Baca konteksnya: perkhidmatan, kontena atau shell
Keupayaan dalam ruang nama rangkaian hos boleh memberi kesan jauh lebih besar daripada operasi yang sama di dalam tindanan yang sengaja diasingkan. Persekitaran masa jalan kontena biasanya bermula dengan set sempadan yang dikurangkan; menambah NET_ADMIN kepada kontena yang berkongsi rangkaian hos ialah kebenaran yang jauh lebih besar daripada menambahnya kepada kontena yang mempunyai ruang nama rangkaian sendiri dan tanpa lekap hos.
Untuk unit systemd, baca apa yang benar-benar digunakan dan bukan apa yang nampak dikatakan oleh fail unit: systemctl show -p CapabilityBoundingSet -p AmbientCapabilities melaporkan nilai berkesan, yang mungkin ditetapkan oleh drop-in yang anda terlupa. Minta nilai berkesan, jangan sekali-kali nilai yang dimaksudkan. Keupayaan ambient penting kerana perkhidmatan bukan root kehilangan keupayaan merentas exec tanpanya.
Gunakan persediaan pakej atau imej yang disokong sebagai garis dasar. Jangan tambah kebenaran soket mentah atau mod istimewa kerana tutorial lain menyenaraikannya untuk alat lain; alasan itu tidak memindahkan apa-apa dan merugikan anda pengasingan yang anda bayar. Jika ragu-ragu, jangan berikan apa-apa dan baca nota pelaksanaan untuk operasi tepat yang anda perlukan.
Perhatikan apa yang berlaku selepas keistimewaan menurun
Banyak daemon bermula dengan keistimewaan, mengkonfigurasi antara muka, kemudian turun kepada pengguna tanpa keistimewaan dan mengekalkan terowong. Dari titik itu proses tidak lagi boleh menambah laluan, menulis semula peraturan firewall atau membuka peranti istimewa baharu, yang tidak mengapa sehingga sambungan semula memerlukan tepat itu. Bacaan fail dan pelaksanaan cangkuk kemudiannya boleh gagal atas sebab yang sama.
Uji seluruh kitaran hayat dan bukan saat pertama: permulaan, pembaharuan atau sambungan semula, dan pembersihan semasa berhenti. Kejayaan pertama mencipta antara muka tidak membuktikan bahawa setiap operasi istimewa kemudiannya masih berfungsi, dan kegagalan biasanya muncul berjam-jam kemudian dalam pengeluaran.
Pelaksanaan yang mengekalkan terowong terbuka merentas pertukaran pengguna biasanya menggandingkannya dengan pilihan untuk mengekalkan terowong dan kunci. Di pihak systemd, soalan yang setara ialah sama ada set keupayaan unit itu bertahan melalui pertukaran pengguna yang anda konfigurasikan.
Catat pemberian kebenaran dan sebabnya
Tuliskan kebenaran yang tepat, operasi yang dibolehkannya dan ralat yang dibaikinya. Satu baris dalam nota penggunaan — «CAP_NET_ADMIN dalam ruang nama rangkaian unit, diperlukan untuk perubahan laluan selepas sambungan semula» — cukup untuk menghalang orang seterusnya daripada meluaskan kebenaran itu semula.
Kemudian baca semula set berkesan selepas setiap peningkatan. Vendor menambah ciri, imej menukar nilai lalai, dan keupayaan yang tidak perlu tahun lalu boleh menjadi penyokong tanpa sesiapa menyedarinya.