Mengapa Memindahkan Sijil VPN Merosakkan Label SELinuxnya

Sijil boleh berada dalam direktori yang betul dengan mod yang boleh dibaca dan pemilikan root, dan perkhidmatan masih boleh melaporkan bahawa ia tidak dapat membuka fail itu. Pada sistem SELinux, gabungan itu menunjuk kepada satu mekanisme tertentu, bukan kepada kebenaran. Label bergerak bersama fail, kerana penamaan semula tidak mencipta objek baharu. Inode mengekalkan konteks keselamatan yang dimilikinya pada laluan lama, dan dasar untuk laluan baharu tidak pernah mendapat peluang menetapkan konteksnya sendiri.

Apa yang sebenarnya dilakukan penamaan semula kepada label

Fail membawa konteks SELinuxnya sebagai data atribut yang terlekat pada inode. Penamaan semula dalam satu sistem fail menukar entri direktori dan tiada yang lain, yang pantas dan atomik, dan itulah sebabnya konteks bertahan melalui pemindahan. Tiada dasar dirujuk, tiada nilai lalai digunakan, dan tiada amaran dicetak.

Menyalin berkelakuan berbeza. Salinan mencipta inode baharu dalam direktori destinasi, dan dasar menetapkan konteks daripada jenis direktori itu, jadi sijil yang disalin biasanya berakhir dengan label yang betul manakala yang dipindahkan kekal salah. Perbezaan tunggal itu menjelaskan sebahagian besar kekeliruan dalam kelas tiket ini.

Pemindahan antara sistem fail kembali kepada semantik salinan, jadi arahan yang sama boleh berkelakuan berbeza pada dua mesin bergantung pada sama ada /etc tinggal pada volumnya sendiri. Semak perkara itu sebelum membuat kesimpulan bahawa alat ini tidak boleh dipercayai. Satu pandangan pada jadual mount memberitahu anda jenis pemindahan yang anda lakukan.

Baca label semasa berbanding label yang dijangka

Tiga arahan baca sahaja menjawab soalan itu tanpa mengubah apa-apa. Yang pertama menunjukkan apa yang ada pada fail sekarang, yang kedua melaporkan apa yang dijangka oleh dasar untuk laluan tepat itu, dan yang ketiga menyenaraikan setiap fail di bawah direktori yang labelnya berbeza.

ls -lZ /etc/openvpn/client/office-ca.crt
matchpathcon /etc/openvpn/client/office-ca.crt
restorecon -Rn -v /etc/openvpn/client

Larian kering ialah yang boleh dipercayai, kerana ia menamakan setiap fail yang konteksnya menyimpang daripada dasar dan masih membiarkan sistem tidak disentuh. Jika sijil muncul dalam senarai itu, anda telah menemui percanggahan antara apa yang dimaksudkan oleh laluan dan apa yang didakwa oleh fail. Jika ia tidak muncul, label sudah menjadi apa yang dikehendaki oleh dasar dan masa anda milik tempat lain.

Kemudian kaitkan perbezaan itu dengan penolakan sebenar. Ketidakpadanan ialah bukti label yang salah, bukan bukti bahawa perkhidmatan gagal kerananya, dan pembetulan yang digunakan tanpa penolakan sepadan dalam log ialah tekaan dengan langkah tambahan.

Pulihkan pemetaan dan bukannya mencipta pengecualian

Untuk lokasi standard dasar sudah memetakan laluan itu, jadi restorecon menggunakannya dan kerja selesai. Kekalkan skop pada direktori yang anda baiki; memberi label semula seluruh sistem fail adalah perlahan, mengganggu, dan ia mengebumikan kesilapan asal di bawah perubahan yang sangat besar.

Untuk direktori tersuai urutannya penting, dan membalikkannya menghasilkan arahan yang melaporkan kejayaan tanpa mengubah apa-apa. Pemetaan tergolong dalam dasar, pelabelan semula tergolong di akhir, dan larian kering tergolong sebelum kedua-duanya. Melangkau bahagian terakhir itulah cara laluan yang tidak pernah salah tetap dilabel semula.

semanage fcontext -a -t openvpn_etc_t '/etc/openvpn/custom(/.*)?'
restorecon -Rv /etc/openvpn/custom

restorecon menggunakan pemetaan; ia tidak boleh mencipta satu. Jika tiada peraturan menerangkan laluan itu, tiada apa yang boleh dipulihkan, sebab itulah pemetaan berterusan mesti wujud sebelum pelabelan semula. Catat konfigurasi mana yang memiliki pemetaan itu, kerana jika tidak pemindahan kemudian, kemas kini pakej atau pelabelan semula mencipta semula kerosakan itu dan orang seterusnya bermula dari sifar.

Mengapa chcon bukan penyelesaiannya

chcon menulis konteks terus pada fail. Ia berkuat kuasa serta-merta dan ia ialah pilihan paling tidak tahan lama yang tersedia, kerana pelabelan semula sistem fail menggunakan semula dasar dan membuang perubahan manual tanpa bertanya. Fail kelihatan dibaiki dan pembaikan itu mempunyai tarikh luput yang tiada siapa tulis. Apa yang anda mahu sebaliknya ialah peraturan yang menerangkan laluan, supaya setiap fail yang tiba di situ secara automatik menerima rawatan yang sama.

Lebih teruk, ia mengajar pelajaran yang salah: pemetaan asas masih hilang, jadi kerosakan itu kembali berminggu-minggu kemudian tanpa pencetus jelas dan tanpa ingatan tentang jalan pintas itu. Gunakan chcon hanya sebagai eksperimen sementara untuk mengesahkan hipotesis, kemudian gantikannya dengan pemetaan yang bertahan pada pelabelan semula seterusnya, dan semak bahawa penggantian itu benar-benar berada di tempatnya.

Apabila label betul dan akses masih gagal

Mulakan dengan direktori induk. Kebenaran lintasan diperiksa pada setiap komponen laluan, jadi sijil yang dilabel dengan betul di dalam direktori yang tidak dapat dimasuki oleh perkhidmatan masih tidak boleh dibaca. SELinux dan kebenaran biasa kedua-duanya mesti membenarkan setiap langkah, dan membaiki yang satu tidak membaiki yang lain.

Kemudian semak identiti proses dan kotak pasir perkhidmatan itu sendiri. Unit dengan kotak pasir yang terhad boleh menolak akses kepada fail yang dasar akan benarkan dengan senang hati, dan daripada baris log kedua-dua punca kelihatan sama. Sahkan proses mana yang benar-benar bertanya, bukan yang anda andaikan bertanya.

Ingat bahawa peraturan dontaudit boleh menyekat mesej penolakan, jadi log audit kosong ialah bukti lemah dan bukan bukti. Jika dasar kelihatan betul dan akses masih gagal, siasat sebelum menghasilkan modul kebenaran yang luas, dan jangan lumpuhkan SELinux untuk membuat gejala itu hilang. Kedua-dua jalan pintas menghasilkan sistem yang kelihatan berfungsi dan pendirian keselamatan yang tiada siapa dapat menerangkan. Siasatan singkat lebih baik daripada kedua-duanya.