ProtectHome versus o sămânță TOTP: de ce eșuează autentificarea VPN

Aplicația de autentificare afișează un cod nou din șase cifre, VPN-ul îl respinge, iar același cod se verifică perfect când îl testați din propriul shell. Această diferență este toată povestea. Un modul PAM care nu poate deschide secretul de înregistrare returnează o eroare care arată identic cu un cod greșit, iar mediul serviciului care ascunde directoarele home este o cauză obișnuită. Înainte de a relaxa orice permisiune, decideți în care dintre cele trei situații sunteți.

Care dintre cele trei eșecuri este acesta?

Primul este un secret pe care modulul nu îl poate citi deloc. Al doilea este un secret pe care îl poate citi, dar nu îl poate actualiza. Al treilea este un cod care este cu adevărat greșit, de obicei din cauza derivei ceasului sau a unei valori reutilizate.

Separați-le citind jurnalul serviciului și jurnalul de autentificare al sistemului pentru o singură încercare eșuată, apoi confirmați ce serviciu PAM încarcă pluginul și ce linie de modul folosește acel serviciu. Un mesaj generic de eșec al autentificării nu le distinge, nici un test manual reușit, deoarece shell-ul dumneavoastră nu este mediul serviciului.

Vederea sistemului de fișiere a unității este vinovatul obișnuit când doar serviciul eșuează.

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

Opțiunea A: mutați secretul din directorul home

Când serviciul ascunde /home și preferați să păstrați această protecție, stocați secretul unde îl poate vedea. Modulul acceptă o cale secret= și un cont user= care efectuează operațiile cu fișiere, ceea ce permite unui depozit central să deservească multe identități.

Aceasta este opțiunea ordonată și cea care necesită cea mai multă atenție, deoarece un depozit partajat face dintr-un singur director granița de securitate a fiecărui cont.

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

Verificați trei lucruri înainte de a avea încredere: contul există, procesul de lucru al modulului poate trece la el, iar fișierele îi aparțin cu moduri restrictive. Nu folosiți ~ sau o cale cu variabilă home împreună cu user= și nu dezactivați verificările de proprietate ale modulului pentru a face o cale să funcționeze. Păstrați etapa parolei și restul stivei intacte.

Opțiunea B: lăsați fișierul și deschideți o cale

Dacă secretul trebuie să rămână în directorul home al utilizatorului, unitatea are nevoie de o vedere care include acel singur director fără a expune toate directoarele home de pe gazdă. Un drop-in poate adăuga o montare de legătură strict delimitată sub un director home izolat.

Aceasta păstrează proprietatea pe utilizator ca model, cu prețul unei modificări a unității care trebuie revizuită ori de câte ori se schimbă sandbox-ul.

Două limite sunt ușor de ratat. O cale doar pentru citire adăugată sub un director pe care sandbox-ul îl ascunde nu îl expune, deoarece părintele pur și simplu nu este acolo. Iar montarea trebuie să fie scriabilă dacă modulul trebuie să actualizeze starea, ceea ce aduce în joc următoarea opțiune. Scrieți drop-in-ul ca fișier separat în loc să editați unitatea împachetată din /usr/lib, astfel încât o actualizare a pachetului să nu îl anuleze în tăcere.

Opțiunea C: păstrați sandbox-ul și reparați scrierile de stare

Citirea secretului este doar jumătate din autentificare. Modulul poate rescrie informații despre decalajul de timp, protecția împotriva reluării sau un contor, iar un fișier care trece verificarea de citire poate eșua totuși la scriere.

Acel eșec arată ca un cod prost la următoarea încercare și nu la aceasta, motiv pentru care este confundat cu deriva ceasului.

Dați-i un director scriabil propriu și îndreptați calea secretului acolo, în loc să faceți scriabil întregul director home. Confirmați proprietarul directorului, spațiul liber al sistemului de fișiere și dacă unitatea restricționează scrierile în altă parte. Apoi testați două autentificări consecutive, deoarece a doua dovedește calea de scriere și prima doar citirea.

Verificați ca serviciul, nu ca dumneavoastră

Fiecare verificare importantă trebuie să ruleze în sandbox-ul unității cu identitatea unității.

O comandă care reușește ca root vă spune că fișierul există și nimic altceva. O autentificare prin serviciul real vă spune dacă modulul poate citi secretul, îl poate folosi și poate scrie înapoi ce are nevoie.

În final, păstrați cerința intactă. Adăugarea unei opțiuni de parolă nulă, acceptarea eșecurilor doar la citire sau eliminarea sandbox-ului ar face simptomul să dispară schimbând politica. Un utilizator obligat să prezinte un cod trebuie respins în continuare când secretul este inaccesibil.