Root di terminal, ditolak di bawah SELinux: mengapa hook gagal

Anda menjalankan skrip up sebagai root, skrip itu selesai, dan skrip yang sama gagal ketika layanan memanggilnya. Tidak ada yang berubah pada izin berkas, jadi langkah berikutnya yang wajar adalah melonggarkannya lagi, yang tidak memperbaiki apa pun. Pada host SELinux faktor penentunya sering kali bukan siapa prosesnya, melainkan di domain mana proses itu berjalan, dan root di dalam domain terbatas tetap terbatas.

Perintah yang sama, dua domain keamanan berbeda

Penegakan tipe mengevaluasi domain sumber, label tujuan, dan operasi yang diminta secara bersamaan. Sesi terminal Anda berjalan di domain tak terbatas atau administratif, dan daemon berjalan di domain yang ditetapkan untuk unitnya. Karena itu perintah yang identik menghasilkan keputusan berbeda, dan perbedaannya disengaja, bukan bug dalam kebijakan.

Karena itulah membandingkan kedua eksekusi hanya berguna jika Anda membandingkan konteksnya. Jalankan perintah yang sama dari shell dan dari hook, dan versi shell membuktikan bahwa biner itu ada serta argumennya benar; versi itu tidak membuktikan apa pun tentang apakah layanan diizinkan menjalankannya. Jalankan dengan kedua cara dan bandingkan domainnya, bukan hanya kode keluarnya. Perbandingan itulah yang mengubah keluhan izin yang kabur menjadi pertanyaan spesifik tentang satu domain dan satu label.

Bentuk klasik dari gangguan ini adalah pembantu yang memanggil alat eksternal. Hook itu sendiri mungkin diizinkan, sementara alat yang dipanggilnya membawa label yang tidak boleh dijalankan oleh domain layanan, atau menulis ke direktori yang labelnya melarangnya.

Baca catatan AVC di sebelah kesalahan hook

Penolakan AVC menyebutkan bidang-bidang yang menentukan kasus: konteks sumber proses, konteks tujuan objek, kelas objek, dan izin spesifik yang ditolak. Baca keempatnya sebelum menyusun teori, karena penolakan pada eksekusi dan penolakan pada penulisan memiliki perbaikan yang sangat berbeda.

ausearch -m AVC,USER_AVC -ts recent
ls -Z /usr/local/sbin/vpn-up.sh
ps -eZ | grep openvpn

Konteks sumber seharusnya cocok dengan domain tempat layanan benar-benar berjalan, dan konteks tujuan dengan label berkas atau direktori yang disentuh operasi itu. Jika salah satunya tidak cocok dengan kesalahan yang Anda kejar, Anda sedang membaca peristiwa lain.

Catat versi kebijakan dan jalur persis berkas yang dapat dieksekusi di samping catatan. Nama domain yang muncul dalam kebijakan satu distribusi adalah bukti tentang pemasangan itu, bukan jaminan bahwa build lain mengirimkan aturan yang sama. Konteks itulah yang memungkinkan orang lain mereproduksi kesimpulan Anda di host mereka sendiri. Tanpanya, catatan itu terbaca sebagai anekdot, bukan bukti.

Label, konfigurasi, atau kebijakan: tiga perbaikan

Perbaikan pertama adalah label yang tidak cocok dengan lokasi pemasangan berkas. Skrip yang disalin ke tempatnya dengan cp atau ditulis oleh penyunting mungkin membawa label bawaan yang tidak dapat digunakan domain layanan, dan memulihkan konteks yang diharapkan memperbaikinya tanpa menyentuh kebijakan sama sekali.

Yang kedua adalah konfigurasi. Distribusi mungkin menyediakan cara yang didukung untuk menjalankan operasi, direktori terdokumentasi untuk pembantu, atau paket kebijakan yang diperbarui yang sudah mengizinkannya. Mengubah tata letak Anda ke yang didukung lebih murah daripada menulis kebijakan dan bertahan terhadap pembaruan.

Yang ketiga adalah aturan yang benar-benar tidak ada, dan itu harus menjadi upaya terakhir. Hasilkan kandidat dengan perkakas audit, baca apa yang sebenarnya diizinkannya, persempit ke operasi dan domain yang Anda amati, dan minta orang lain meninjaunya sebelum mendekati produksi.

Mengapa modul allow lama bukan jawabannya

Hasil pencarian untuk gangguan ini penuh dengan modul siap pakai, sering kali untuk alat yang tidak lagi dipanggil hook. Memasang satu memberikan izin yang mungkin tidak ada hubungannya dengan penolakan Anda, dan membiarkan ketidakcocokan sebenarnya tetap ada sambil menambahkan lubang permanen.

Ini juga menyembunyikan kegagalan berikutnya. Modul yang mengizinkan kelas operasi yang luas akan membuat kesalahan ini hilang dan mengubah kesalahan berikutnya menjadi sesuatu yang jauh lebih sulit dikaitkan. Melepas modul nanti juga perubahan yang tidak ingin dijadwalkan siapa pun, jadi jalan pintas cenderung menjadi permanen.

Perbandingan yang disiplin adalah antara penolakan yang dapat Anda baca dan perubahan yang Anda usulkan. Pedoman pemecahan masalah SELinux dari Red Hat menempatkan pemeriksaan pelabelan dan konfigurasi di depan kebijakan yang dihasilkan justru karena alasan ini. Jika tidak ada penolakan yang sesuai dalam catatan, SELinux kemungkinan bukan masalah Anda, dan persoalan jalur, sandbox, atau izin masih terbuka.