Mengapa Memindahkan Sertifikat VPN Merusak Label SELinux-nya

Sertifikat bisa berada di direktori yang benar dengan mode yang dapat dibaca dan kepemilikan root, dan layanan tetap dapat melaporkan bahwa ia tidak dapat membuka berkas itu. Pada sistem SELinux, kombinasi itu menunjuk pada satu mekanisme tertentu, bukan pada izin. Label ikut berpindah bersama berkas, karena penggantian nama tidak membuat objek baru. Inode mempertahankan konteks keamanan yang dimilikinya di jalur lama, dan kebijakan untuk jalur baru tidak pernah mendapat kesempatan menetapkan konteksnya sendiri.

Apa yang sebenarnya dilakukan penggantian nama terhadap label

Sebuah berkas membawa konteks SELinux-nya sebagai data atribut yang melekat pada inode. Penggantian nama di dalam satu sistem berkas mengubah entri direktori dan tidak yang lain, yang cepat dan atomik, dan itulah sebabnya konteks bertahan melewati pemindahan. Tidak ada kebijakan yang ditanyakan, tidak ada nilai bawaan yang diterapkan, dan tidak ada peringatan yang dicetak.

Penyalinan berperilaku berbeda. Salinan membuat inode baru di direktori tujuan, dan kebijakan menetapkan konteks dari tipe direktori itu, sehingga sertifikat yang disalin biasanya berakhir dengan label yang benar sementara yang dipindahkan tetap salah. Perbedaan tunggal itu menjelaskan sebagian besar kebingungan pada kelas tiket ini.

Pemindahan antar sistem berkas kembali ke semantik penyalinan, sehingga perintah yang sama dapat berperilaku berbeda pada dua mesin tergantung apakah /etc berada pada volume tersendiri. Periksa hal itu sebelum menyimpulkan bahwa alat ini tidak dapat diandalkan. Satu lihat pada tabel mount memberi tahu Anda jenis pemindahan yang Anda lakukan.

Baca label saat ini terhadap label yang diharapkan

Tiga perintah hanya-baca menjawab pertanyaan itu tanpa mengubah apa pun. Yang pertama menunjukkan apa yang dimiliki berkas sekarang, yang kedua melaporkan apa yang diharapkan kebijakan untuk jalur yang tepat itu, dan yang ketiga mendaftar setiap berkas di bawah direktori yang labelnya berbeda.

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

Uji kering adalah yang dapat dipercaya, karena ia menyebut setiap berkas yang konteksnya menyimpang dari kebijakan dan tetap membiarkan sistem tidak tersentuh. Jika sertifikat muncul dalam daftar itu, Anda telah menemukan ketidaksesuaian antara apa yang berarti jalur dan apa yang diklaim berkas. Jika tidak muncul, labelnya sudah seperti yang dikehendaki kebijakan dan waktu Anda milik tempat lain.

Lalu korelasikan perbedaan itu dengan penolakan yang sebenarnya. Ketidakcocokan adalah bukti label yang salah, bukan bukti bahwa layanan gagal karenanya, dan perbaikan yang diterapkan tanpa penolakan yang sesuai di log adalah dugaan dengan langkah tambahan.

Pulihkan pemetaan alih-alih menciptakan pengecualian

Untuk lokasi standar kebijakan sudah memetakan jalur itu, jadi restorecon menerapkannya dan pekerjaan selesai. Jaga cakupan pada direktori yang Anda perbaiki; memberi label ulang seluruh sistem berkas itu lambat, mengganggu, dan mengubur kesalahan awal di bawah perubahan yang sangat besar.

Untuk direktori khusus urutannya penting, dan membaliknya menghasilkan perintah yang melaporkan sukses sambil tidak mengubah apa pun. Pemetaan berada di kebijakan, pemberian label ulang berada di akhir, dan uji kering berada sebelum keduanya. Melewati bagian terakhir itulah cara jalur yang tidak pernah salah tetap diberi label ulang.

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

restorecon menerapkan pemetaan; ia tidak dapat menciptakan pemetaan. Jika tidak ada aturan yang menjelaskan jalur itu, tidak ada yang dapat dipulihkan, karena itulah pemetaan permanen harus ada sebelum pemberian label ulang. Catat konfigurasi mana yang memiliki pemetaan itu, karena jika tidak, pemindahan berikutnya, pembaruan paket, atau pemberian label ulang menciptakan kembali kesalahan itu dan orang berikutnya mulai dari nol.

Mengapa chcon bukan solusinya

chcon menulis konteks langsung ke berkas. Ia berlaku seketika dan merupakan opsi paling tidak tahan lama yang tersedia, karena pemberian label ulang pada sistem berkas menerapkan kembali kebijakan dan membuang perubahan manual tanpa bertanya. Berkas tampak diperbaiki dan perbaikan itu memiliki tanggal kedaluwarsa yang tidak ditulis siapa pun. Yang Anda inginkan sebagai gantinya adalah aturan yang menjelaskan jalur, sehingga setiap berkas yang tiba di sana otomatis mendapat perlakuan yang sama.

Lebih buruk lagi, ini mengajarkan pelajaran yang salah: pemetaan yang mendasarinya masih hilang, sehingga kegagalan itu kembali berminggu-minggu kemudian tanpa pemicu yang jelas dan tanpa ingatan akan jalan pintas itu. Gunakan chcon hanya sebagai eksperimen sementara untuk memastikan hipotesis, lalu ganti dengan pemetaan yang bertahan pada pemberian label ulang berikutnya, dan periksa bahwa penggantinya benar-benar terpasang.

Ketika label sudah benar dan akses tetap gagal

Mulailah dari direktori induk. Izin lintas diperiksa pada setiap komponen jalur, sehingga sertifikat yang berlabel benar di dalam direktori yang tidak dapat dimasuki layanan tetap tidak terbaca. SELinux dan izin biasa keduanya harus mengizinkan setiap langkah, dan memperbaiki yang satu tidak memperbaiki yang lain.

Lalu periksa identitas proses dan kotak pasir layanan itu sendiri. Unit dengan kotak pasir yang membatasi dapat menolak akses ke berkas yang akan dengan senang hati diizinkan kebijakan, dan dari baris log kedua penyebab tampak identik. Pastikan proses mana yang benar-benar meminta, bukan yang Anda anggap meminta.

Ingat bahwa aturan dontaudit dapat menekan pesan penolakan, sehingga log audit yang kosong adalah bukti lemah dan bukan bukti. Jika kebijakan tampak benar dan akses tetap gagal, selidiki sebelum menghasilkan modul izin yang luas, dan jangan menonaktifkan SELinux agar gejalanya hilang. Kedua jalan pintas menghasilkan sistem yang tampak berfungsi dan postur keamanan yang tidak dapat dijelaskan siapa pun. Penyelidikan singkat lebih baik daripada keduanya.