ProtectHome berbanding benih TOTP: mengapa log masuk VPN gagal

Aplikasi pengesah memaparkan kod enam digit yang baharu, VPN menolaknya, dan kod yang sama disahkan dengan baik apabila anda mengujinya dari shell anda sendiri. Jurang itulah keseluruhan cerita. Modul PAM yang tidak dapat membuka rahsia pendaftaran mengembalikan kegagalan yang kelihatan sama seperti kod salah, dan persekitaran perkhidmatan yang menyembunyikan direktori rumah ialah punca biasa. Sebelum melonggarkan sebarang kebenaran, tentukan anda berada dalam yang mana satu daripada tiga situasi.

Kegagalan yang mana satu daripada tiga ini?

Yang pertama ialah rahsia yang modul tidak dapat baca sama sekali. Yang kedua ialah rahsia yang boleh dibacanya tetapi tidak boleh dikemas kini. Yang ketiga ialah kod yang benar-benar salah, biasanya kerana hanyutan jam atau nilai yang dimainkan semula.

Asingkan kedua-duanya dengan membaca jurnal perkhidmatan dan log pengesahan sistem untuk satu percubaan yang gagal, kemudian sahkan perkhidmatan PAM mana yang dimuatkan pemalam dan baris modul mana yang digunakan perkhidmatan itu. Mesej kegagalan pengesahan generik tidak membezakannya, dan ujian manual yang berjaya juga tidak, kerana shell anda bukan persekitaran perkhidmatan.

Paparan sistem fail unit ialah suspek biasa apabila hanya perkhidmatan yang gagal.

systemctl show -p ProtectHome -p ProtectSystem -p ReadWritePaths [email protected]
ls -l /var/lib/vpn-otp/*/.google_authenticator 2>/dev/null | head -n 20

Pilihan A: pindahkan rahsia keluar dari rumah

Apabila perkhidmatan menyembunyikan /home dan anda lebih suka mengekalkan perlindungan itu, simpan rahsia di tempat yang boleh dilihatnya. Modul menerima laluan secret= dan akaun user= yang menjalankan operasi fail, yang membolehkan stor pusat melayani banyak identiti.

Ini pilihan yang kemas, dan inilah yang paling memerlukan kehati-hatian, kerana stor kongsi menjadikan satu direktori sebagai sempadan keselamatan setiap akaun.

auth required pam_google_authenticator.so secret=/var/lib/vpn-otp/${USER}/.google_authenticator user=vpn-otp

Semak tiga perkara sebelum mempercayainya: akaun itu wujud, proses kerja modul boleh bertukar kepadanya, dan fail dimiliki olehnya dengan mod ketat. Jangan gunakan ~ atau laluan pemboleh ubah rumah bersama user=, dan jangan lumpuhkan semakan pemilikan modul untuk menjadikan laluan berfungsi. Kekalkan peringkat kata laluan dan seluruh tindanan tidak terganggu.

Pilihan B: biarkan fail dan buka laluan

Jika rahsia mesti kekal dalam direktori rumah pengguna, unit memerlukan paparan yang merangkumi satu direktori itu tanpa mendedahkan setiap rumah pada hos. Drop-in boleh menambah lekap ikat yang sempit di bawah rumah yang disandbox.

Ini mengekalkan pemilikan setiap pengguna sebagai model, dengan kos perubahan unit yang perlu disemak setiap kali sandbox berubah.

Dua had mudah terlepas pandang. Laluan baca sahaja yang ditambah di bawah direktori yang disembunyikan sandbox tidak mendedahkannya, kerana induknya memang tiada. Dan lekap mesti boleh ditulis jika modul perlu mengemas kini status, yang membawa pilihan seterusnya. Tulis drop-in sebagai fail berasingan dan bukan menyunting unit terpakej di bawah /usr/lib, supaya peningkatan pakej tidak membatalkannya secara senyap.

Pilihan C: kekalkan sandbox dan betulkan tulisan status

Membaca rahsia hanyalah separuh daripada pengesahan. Modul mungkin menulis semula maklumat sisihan masa, perlindungan main semula atau pembilang, dan fail yang lulus pemeriksaan baca masih boleh gagal semasa menulis.

Kegagalan itu kelihatan seperti kod buruk pada percubaan seterusnya dan bukan pada percubaan ini, sebab itu ia disalah anggap sebagai hanyutan jam.

Berikan direktori boleh tulis sendiri dan halakan laluan rahsia ke sana, bukan menjadikan seluruh rumah boleh ditulis. Sahkan pemilik direktori, ruang kosong sistem fail dan sama ada unit mengehadkan tulisan di tempat lain. Kemudian uji dua log masuk berturut-turut, kerana yang kedua membuktikan laluan tulis dan yang pertama hanya membuktikan baca.

Sahkan sebagai perkhidmatan, bukan sebagai diri sendiri

Setiap pemeriksaan yang penting mesti berjalan dalam sandbox unit dengan identiti unit.

Arahan yang berjaya sebagai root memberitahu anda bahawa fail itu wujud dan tiada lagi. Log masuk melalui perkhidmatan sebenar memberitahu anda sama ada modul boleh membaca rahsia, menggunakannya dan menulis semula apa yang diperlukannya.

Akhir sekali, kekalkan keperluan itu tanpa diubah. Menambah pilihan kata laluan nol, menerima kegagalan baca sahaja atau membuang sandbox semuanya akan menghilangkan gejala dengan mengubah dasar. Pengguna yang dikehendaki mengemukakan kod masih perlu ditolak apabila rahsia tidak dapat dicapai.