Autentikasi PAM berfungsi secara manual tetapi gagal sebagai layanan OpenVPN

Autentikasi melalui PAM dapat berhasil saat Anda menjalankan klien secara manual dan gagal dengan AUTH_FAILED begitu systemd memulai profil yang sama. Kata sandi tidak berubah di antara kedua jalannya itu; yang berubah adalah kumpulan batasan di sekitar proses yang mengajukan pertanyaan kepada PAM. PAM menjawab melalui helper yang kemampuannya mengubah kredensialnya sendiri justru itulah yang dihapus oleh unit yang dikeraskan. Temukan helper itu dan batas yang dibutuhkannya sebelum menyentuh daftar kapabilitas.

unix_chkpwd adalah biner yang menjawab pertanyaan PAM

Dengan autentikasi kata sandi lokal, pam_unix jarang membaca file hash itu sendiri. Ia menjalankan unix_chkpwd, yang dipasang distribusi sebagai setuid root atau setgid shadow agar satu kata sandi dapat diperiksa atas nama proses yang tidak ada urusannya membaca /etc/shadow. Hapus kemampuan memperoleh identitas itu dan helper tidak dapat menyelesaikan pemeriksaan, sehingga modul mengembalikan kegagalan autentikasi biasa.

Kegagalan itu lalu tampak seperti masalah kredensial di setiap log yang dapat dilihat klien. Itulah jebakannya: klien melaporkan apa yang dikatakan PAM kepadanya, dan PAM hanya melaporkan bahwa tumpukan mengatakan tidak. Menjalankan helper secara manual sebagai root juga tidak membuktikan apa pun, karena itu melatih jalur hak istimewa yang tidak pernah dipakai layanan. Baca unit yang benar-benar dimuat systemd, lalu baca log sistem untuk percobaan yang dilakukannya. Kedua pandangan itu memisahkan masalah sandbox dari masalah kata sandi salah.

Baca unit sebelum membaca log kata sandi

Unit yang dipaketkan dapat membawa drop-in yang tidak Anda tulis, dan konfigurasi efektif adalah hasil gabungannya. Cetak unit sebagaimana systemd melihatnya, bersama pengaturan sandbox yang menentukan apakah helper dapat menaikkan dirinya. Inspeksi hanya-baca cukup pada tahap ini.

systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p CapabilityBoundingSet -p AmbientCapabilities -p NoNewPrivileges
journalctl -u [email protected] -b

Perintah pertama menunjukkan dari mana unit dan drop-in-nya berasal, yang penting karena penimpaan yang ditambahkan berbulan-bulan lalu hidup lebih lama daripada ingatan mengapa ia ada. Yang kedua mencetak nilai sandbox yang menjadi dasar dua bagian berikutnya.

Bandingkan apa yang Anda lihat dengan host yang berfungsi dari distribusi dan versi yang sama. Perbedaan pada User, CapabilityBoundingSet, atau NoNewPrivileges adalah petunjuk konkret; perbedaan pada komentar prosa bukan. Catat nilainya sebelum mengubah apa pun, karena perbandingan nanti dengan target yang bergerak tidak membuktikan apa pun. Jika layanan berjalan sebagai akun tanpa hak istimewa dengan himpunan bounding kosong, helper hampir tidak punya apa pun untuk dikerjakan.

Transformasi kredensial, akses file, dan kebijakan adalah tiga batas

Mulailah dari apa yang terjadi selama exec. Biner setuid atau file yang membawa kapabilitas file memicu transformasi kredensial, sehingga identitas yang dihasilkan bukan kelanjutan dari pemanggil. Himpunan bounding membatasi apa yang boleh diperoleh file semacam itu, dan NoNewPrivileges memblokir perolehan setuid, setgid, dan kapabilitas file secara total. Salah satu dari ketiganya dapat menghentikan helper sementara setiap fungsi layanan lain tetap utuh.

Selanjutnya, pisahkan pintasan diskresioner yang luas dari akses baca yang sempit. CAP_DAC_OVERRIDE melewati pemeriksaan diskresioner hampir di mana-mana, sedangkan CAP_DAC_READ_SEARCH mencakup pembacaan dan penelusuran direktori dengan kekuatan tambahannya sendiri. Keduanya alat berbeda dengan radius dampak berbeda, dan tidak satu pun merupakan ejaan dari biarkan PAM membaca file shadow.

Terakhir, tanyakan apakah kebijakan wajib mengizinkan tindakan itu sama sekali. Kapabilitas Linux tidak mengesampingkan SELinux, dan memilikinya tidak membuktikan apa pun tentang aturan type enforcement. Perlakukan penolakan akses file dan penolakan kapabilitas sebagai bukti berbeda, karena keduanya menyebut perbaikan berbeda dan sering kali pemilik berbeda. Baca setiap bidang catatan alih-alih satu kata denied. Biner mana yang melakukan tindakan, di domain mana ia berjalan, jenis target apa yang disentuhnya, kelas objek apa yang terlibat, dan izin apa yang ditolak kebijakan — masing-masing mempersempit jawaban dengan cara berbeda.

Tarik penolakan keluar dari log audit

Pada host yang menegakkan, jejak audit adalah satu-satunya tempat yang mencatat penolakan. Kueri kejadian terbaru dan bacalah terhadap stempel waktu login yang gagal, bukan terhadap waktu Anda mulai menyelidiki.

ausearch -m AVC,USER_AVC -ts recent

Hasil kosong bukan bukti tidak bersalah. Itu berarti audit tidak mengumpulkan, atau jendela Anda melewatkan percobaan itu, dan kedua kemungkinan harus disingkirkan sebelum Anda menyingkirkan kebijakan.

Panduan pemecahan masalah SELinux dari Red Hat menempatkan pemeriksaan label dan konfigurasi sebelum pembuatan aturan allow, yang juga urutan tepat untuk masalah ini. Biner helper berlabel salah dan celah kebijakan menghasilkan penolakan serupa tetapi memerlukan perbaikan berbeda. Membuat aturan allow untuk kesalahan pelabelan menyembunyikan cacat dan membiarkan pembaruan paket berikutnya memunculkannya lagi. Pastikan label pada helper yang terpasang sebelum menulis kebijakan apa pun.

Buktikan perubahan dengan satu login yang diterima dan satu yang ditolak

Ubah hanya batas yang Anda tunjukkan, lalu uji kedua hasilnya. Akun yang seharusnya terautentikasi harus berhasil, dan akun dengan kata sandi salah harus tetap gagal. Perubahan yang membuat setiap percobaan berhasil telah menghapus autentikasi, bukan memperbaikinya.

Lakukan percobaan koneksi sungguhan dan baca jurnal segera sesudahnya. Baris yang membuktikan perbaikan adalah entri pam_unix(openvpn:auth) untuk percobaan itu: seharusnya tertulis autentikasi berhasil, dan tidak ada catatan AVC yang membawa detik yang sama.

journalctl -u [email protected] -n 30 --no-pager
ss -tnp | grep openvpn

Tunnel yang berfungsi juga memerlukan penyambungan ulang, karena perubahan sandbox lebih sering memutus koneksi kedua daripada yang pertama. Periksa soket yang terbentuk setelah penyambungan ulang dan pastikan unit yang sama masih melayaninya.