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

Anda menjalankan skrip up sebagai root, ia selesai, dan skrip yang sama gagal apabila perkhidmatan memanggilnya. Tiada apa-apa pada kebenaran fail berubah, jadi langkah seterusnya yang wajar ialah melonggarkannya semula, yang tidak membaiki apa-apa. Pada hos SELinux faktor penentu selalunya bukan siapa proses itu, tetapi di domain mana ia berjalan, dan root di dalam domain terbatas kekal terbatas.

Perintah yang sama, dua domain keselamatan berbeza

Penguatkuasaan jenis menilai domain sumber, label sasaran dan operasi yang diminta secara serentak. Sesi terminal anda berjalan dalam domain tidak terbatas atau pentadbiran, dan daemon berjalan dalam domain yang diberikan kepada unitnya. Oleh itu perintah yang serupa menghasilkan keputusan berbeza, dan perbezaannya adalah disengajakan dan bukan pepijat dalam dasar.

Itulah sebabnya membandingkan kedua-dua larian hanya berguna jika anda membandingkan konteksnya. Jalankan perintah yang sama dari shell dan dari hook, dan versi shell membuktikan bahawa binari itu wujud dan hujahnya betul; ia tidak membuktikan apa-apa tentang sama ada perkhidmatan dibenarkan menjalankannya. Jalankan dengan kedua-dua cara dan bandingkan domain, bukan hanya kod keluar. Perbandingan itulah yang mengubah aduan kebenaran yang kabur menjadi soalan khusus tentang satu domain dan satu label.

Bentuk klasik kerosakan ini ialah pembantu yang memanggil alat luaran. Hook itu sendiri mungkin dibenarkan, manakala alat yang dipanggilnya membawa label yang tidak boleh dijalankan oleh domain perkhidmatan, atau menulis ke direktori yang labelnya melarangnya.

Baca rekod AVC di sebelah ralat hook

Penolakan AVC menamakan medan yang menentukan kes: konteks sumber proses, konteks sasaran objek, kelas objek dan kebenaran khusus yang ditolak. Baca keempat-empatnya sebelum membentuk teori, kerana penolakan pada eksekusi dan penolakan pada tulisan mempunyai pembaikan yang sama sekali berbeza.

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

Konteks sumber sepatutnya sepadan dengan domain tempat perkhidmatan benar-benar berjalan, dan konteks sasaran dengan label fail atau direktori yang disentuh oleh operasi itu. Jika salah satu daripadanya tidak sepadan dengan ralat yang anda kejar, anda sedang membaca peristiwa lain.

Catat versi dasar dan laluan tepat fail boleh laku di sebelah rekod. Nama domain yang muncul dalam dasar satu distribusi ialah bukti tentang pemasangan itu, bukan jaminan bahawa binaan lain menghantar peraturan yang sama. Konteks itulah yang membolehkan orang lain menghasilkan semula kesimpulan anda pada hos mereka sendiri. Tanpanya, rekod itu dibaca sebagai anekdot dan bukan bukti.

Label, konfigurasi atau dasar: tiga pembaikan

Pembaikan pertama ialah label yang tidak sepadan dengan lokasi pemasangan fail. Skrip yang disalin ke tempatnya dengan cp atau ditulis oleh penyunting mungkin membawa label lalai yang tidak boleh digunakan oleh domain perkhidmatan, dan memulihkan konteks yang dijangka membaikinya tanpa menyentuh dasar sama sekali.

Yang kedua ialah konfigurasi. Distribusi mungkin menyediakan cara yang disokong untuk menjalankan operasi itu, direktori berdokumen untuk pembantu, atau pakej dasar yang dikemas kini yang sudah membenarkannya. Menukar susun atur anda kepada yang disokong lebih murah daripada menulis dasar dan bertahan melalui kemas kini.

Yang ketiga ialah peraturan yang benar-benar tiada, dan ia sepatutnya menjadi jalan terakhir. Hasilkan calon dengan alat audit, baca apa yang sebenarnya dibenarkannya, sempitkannya kepada operasi dan domain yang anda perhatikan, dan minta orang lain menyemaknya sebelum ia menghampiri pengeluaran.

Mengapa modul allow lama bukan jawapannya

Hasil carian untuk kerosakan ini penuh dengan modul siap sedia, selalunya untuk alat yang tidak lagi dipanggil oleh hook. Memasang satu memberikan kebenaran yang mungkin tiada kaitan dengan penolakan anda, dan ia membiarkan ketidakpadanan sebenar di tempatnya sambil menambah lubang kekal.

Ia juga menyembunyikan kegagalan seterusnya. Modul yang membenarkan kelas operasi yang luas akan membuat ralat ini hilang dan mengubah yang seterusnya menjadi sesuatu yang jauh lebih sukar untuk diatribusikan. Menanggalkan modul itu kemudian juga perubahan yang tiada siapa mahu jadualkan, jadi jalan pintas cenderung menjadi kekal.

Perbandingan yang berdisiplin ialah antara penolakan yang boleh anda baca dan perubahan yang anda cadangkan. Panduan penyelesaian masalah SELinux daripada Red Hat meletakkan pemeriksaan pelabelan dan konfigurasi di hadapan dasar yang dijana semata-mata atas sebab ini. Jika tiada penolakan yang sepadan dalam rekod, SELinux mungkin bukan masalah anda, dan isu laluan, sandbox atau kebenaran masih terbuka.