Pengesahan PAM berfungsi secara manual tetapi gagal sebagai perkhidmatan OpenVPN

Pengesahan melalui PAM boleh berjaya apabila anda menjalankan klien secara manual dan gagal dengan AUTH_FAILED sebaik sahaja systemd memulakan profil yang sama. Kata laluan tidak berubah antara larian tersebut; yang berubah ialah set kekangan di sekeliling proses yang bertanya kepada PAM. PAM menjawab melalui pembantu yang keupayaannya mengubah kelayakan sendiri itulah yang dibuang oleh unit yang dikeraskan. Cari pembantu itu dan sempadan yang diperlukannya sebelum menyentuh senarai kebolehan.

unix_chkpwd ialah binari yang menjawab soalan PAM

Dengan pengesahan kata laluan setempat, pam_unix jarang membaca fail hash itu sendiri. Ia melaksanakan unix_chkpwd, yang dipasang oleh pengedaran sebagai setuid root atau setgid shadow supaya satu kata laluan boleh disemak bagi pihak proses yang tiada urusan membaca /etc/shadow. Buang keupayaan memperoleh identiti itu dan pembantu tidak dapat melengkapkan semakan, jadi modul memulangkan kegagalan pengesahan biasa.

Kegagalan itu kemudian kelihatan seperti masalah kelayakan dalam setiap log yang boleh dilihat klien. Itulah perangkapnya: klien melaporkan apa yang PAM beritahu kepadanya, dan PAM hanya melaporkan bahawa tindanan berkata tidak. Menjalankan pembantu secara manual sebagai root juga tidak membuktikan apa-apa, kerana ia melatih laluan keistimewaan yang tidak pernah digunakan oleh perkhidmatan. Baca unit yang sebenarnya dimuatkan oleh systemd, kemudian baca log sistem untuk percubaan yang dibuatnya. Kedua-dua pandangan itu memisahkan masalah sandbox daripada masalah kata laluan salah.

Baca unit sebelum membaca log kata laluan

Unit yang dipakejkan boleh membawa drop-in yang anda tidak tulis, dan konfigurasi berkesan ialah hasil gabungan. Cetak unit seperti yang dilihat oleh systemd, bersama tetapan sandbox yang menentukan sama ada pembantu boleh menaikkan dirinya. Pemeriksaan baca-sahaja memadai pada peringkat 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 datang, yang penting kerana penggantian yang ditambah berbulan-bulan lalu hidup lebih lama daripada ingatan mengapa ia wujud. Yang kedua mencetak nilai sandbox yang bergantung kepadanya dua bahagian seterusnya.

Bandingkan apa yang anda lihat dengan hos berfungsi daripada pengedaran dan versi yang sama. Perbezaan dalam User, CapabilityBoundingSet atau NoNewPrivileges ialah petunjuk konkrit; perbezaan dalam komen prosa bukan. Catat nilai sebelum mengubah apa-apa, kerana perbandingan kemudian dengan sasaran bergerak tidak membuktikan apa-apa. Jika perkhidmatan berjalan sebagai akaun tanpa keistimewaan dengan set bounding kosong, pembantu hampir tiada apa-apa untuk digunakan.

Transformasi kelayakan, akses fail dan dasar ialah tiga sempadan

Mulakan dengan apa yang berlaku semasa exec. Binari setuid atau fail yang membawa keupayaan fail mencetuskan transformasi kelayakan, jadi identiti yang terhasil bukan kesinambungan pemanggil. Set bounding mengehadkan apa yang boleh diperoleh oleh fail sedemikian, dan NoNewPrivileges menyekat sepenuhnya perolehan setuid, setgid dan keupayaan fail. Mana-mana satu daripada ketiga-tiganya boleh menghentikan pembantu sementara setiap fungsi perkhidmatan lain kekal utuh.

Seterusnya, pisahkan pintasan budi bicara yang luas daripada akses baca yang sempit. CAP_DAC_OVERRIDE melangkau semakan budi bicara hampir di mana-mana, manakala CAP_DAC_READ_SEARCH meliputi bacaan dan traversal direktori dengan kuasa tambahannya sendiri. Kedua-duanya alat berbeza dengan jejari kesan berbeza, dan tiada satu pun merupakan ejaan bagi biarkan PAM membaca fail shadow.

Akhir sekali, tanya sama ada dasar mandatori membenarkan tindakan itu sama sekali. Keupayaan Linux tidak mengatasi SELinux, dan memilikinya tidak membuktikan apa-apa tentang peraturan type enforcement. Anggap penolakan akses fail dan penolakan keupayaan sebagai bukti berbeza, kerana keduanya menamakan pembaikan berbeza dan selalunya pemilik berbeza. Baca setiap medan rekod dan bukan hanya perkataan denied. Binari mana yang melakukan tindakan, dalam domain mana ia berjalan, jenis sasaran apa yang disentuhnya, kelas objek apa yang terlibat dan kebenaran apa yang ditolak oleh dasar — setiap satu menyempitkan jawapan dengan cara berbeza.

Tarik penolakan keluar daripada log audit

Pada hos yang menguatkuasakan, jejak audit ialah satu-satunya tempat yang merekodkan penolakan. Tanya peristiwa terkini dan bacanya terhadap cap masa log masuk yang gagal, bukan terhadap masa anda mula menyiasat.

ausearch -m AVC,USER_AVC -ts recent

Hasil kosong bukan bukti tidak bersalah. Ia bermaksud sama ada pengauditan tidak mengumpul, atau tetingkap anda terlepas percubaan itu, dan kedua-dua kemungkinan mesti dikecualikan sebelum anda mengecualikan dasar.

Panduan penyelesaian masalah SELinux Red Hat meletakkan semakan label dan konfigurasi sebelum penjanaan peraturan allow, yang juga merupakan urutan betul untuk masalah ini. Binari pembantu berlabel salah dan jurang dasar menghasilkan penolakan serupa tetapi memerlukan pembaikan berbeza. Menjana peraturan allow untuk kesilapan pelabelan menyembunyikan kecacatan dan membiarkan kemas kini pakej seterusnya memperkenalkannya semula. Sahkan label pada pembantu yang dipasang sebelum menulis sebarang dasar.

Buktikan perubahan dengan satu log masuk diterima dan satu ditolak

Ubah hanya sempadan yang anda tunjukkan, kemudian uji kedua-dua hasil. Akaun yang sepatutnya disahkan mesti berjaya, dan akaun dengan kata laluan salah mesti masih gagal. Perubahan yang membuat setiap percubaan berjaya telah membuang pengesahan dan bukan membaikinya.

Lakukan percubaan sambungan sebenar dan baca jurnal sejurus selepasnya. Baris yang membuktikan pembaikan ialah entri pam_unix(openvpn:auth) untuk percubaan itu: ia sepatutnya menyatakan pengesahan berjaya, dan tiada rekod AVC boleh membawa saat yang sama.

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

Terowong yang berfungsi juga memerlukan sambungan semula, kerana perubahan sandbox lebih kerap memutuskan sambungan kedua daripada yang pertama. Semak soket yang terbentuk selepas sambungan semula dan sahkan unit yang sama masih melayaninya.