ProtectHome verzus semienko TOTP: prečo prihlásenie do VPN zlyháva

Autentifikátor zobrazí nový šesťciferný kód, VPN ho odmietne a ten istý kód sa bez problémov overí, keď ho otestujete vo vlastnom shelli. Tento rozdiel je celý príbeh. Modul PAM, ktorý nedokáže otvoriť registračné tajomstvo, vráti zlyhanie, ktoré vyzerá rovnako ako nesprávny kód, a prostredie služby, ktoré skrýva domovské adresáre, je častou príčinou. Skôr než uvoľníte akékoľvek oprávnenie, rozhodnite, v ktorej z troch situácií ste.

Ktoré z troch zlyhaní to je?

Prvé je tajomstvo, ktoré modul vôbec nedokáže prečítať. Druhé je tajomstvo, ktoré prečítať dokáže, ale nedokáže aktualizovať. Tretie je kód, ktorý je naozaj nesprávny, zvyčajne pre posun hodín alebo znova použitú hodnotu.

Oddeľte ich čítaním denníka služby a systémového autentifikačného logu pre jeden neúspešný pokus, potom overte, ktorú službu PAM načítava doplnok a ktorý riadok modulu táto služba používa. Všeobecná správa o zlyhaní autentifikácie ich nerozlišuje, ani úspešný manuálny test, pretože váš shell nie je prostredím služby.

Pohľad jednotky na súborový systém je obvyklý vinník, keď zlyháva iba služba.

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

Možnosť A: presuňte tajomstvo z domovského adresára

Keď služba skrýva /home a vy chcete túto ochranu zachovať, uložte tajomstvo tam, kde ho vidí. Modul prijíma cestu secret= a účet user=, ktorý vykonáva súborové operácie, čo centrálnemu úložisku umožňuje obsluhovať mnoho identít.

Toto je úhľadná možnosť a vyžaduje najviac starostlivosti, pretože zdieľané úložisko robí z jedného adresára bezpečnostnú hranicu každého účtu.

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

Skôr než mu budete dôverovať, skontrolujte tri veci: účet existuje, pracovný proces modulu naň dokáže prepnúť a súbory sú jeho s obmedzujúcimi režimami. Nepoužívajte ~ ani cestu s domovskou premennou spolu s user= a nevypínajte kontroly vlastníctva modulu, aby cesta fungovala. Zachovajte fázu hesla a zvyšok zásobníka nedotknuté.

Možnosť B: ponechajte súbor a otvorte cestu

Ak tajomstvo musí zostať v domovskom adresári používateľa, jednotka potrebuje pohľad, ktorý zahŕňa ten jeden adresár bez odhalenia všetkých domovských adresárov na hostiteľovi. Drop-in môže pridať úzko obmedzené bind pripojenie pod izolovaným domovským adresárom.

Tým zostáva vlastníctvo podľa používateľa modelom, za cenu zmeny jednotky, ktorú treba preskúmať pri každej zmene sandboxu.

Dve hranice sa dajú ľahko prehliadnuť. Cesta iba na čítanie pridaná pod adresár, ktorý sandbox skrýva, ho neodhalí, pretože rodič jednoducho nie je. A pripojenie musí byť zapisovateľné, ak modul musí aktualizovať stav, čo prináša nasledujúcu možnosť. Napíšte drop-in ako samostatný súbor namiesto úpravy zabalenej jednotky pod /usr/lib, aby ju aktualizácia balíka potichu nevrátila späť.

Možnosť C: ponechajte sandbox a opravte zápisy stavu

Čítanie tajomstva je len polovica autentifikácie. Modul môže prepisovať informácie o časovom posune, ochranu proti opakovaniu alebo počítadlo, a súbor, ktorý prejde kontrolou čítania, môže stále zlyhať pri zápise.

Toto zlyhanie vyzerá ako zlý kód pri ďalšom pokuse a nie pri tomto, preto sa zamieňa s posunom hodín.

Dajte mu vlastný zapisovateľný adresár a nasmerujte tam cestu tajomstva, namiesto toho, aby ste urobili zapisovateľný celý domovský adresár. Overte vlastníka adresára, voľné miesto v súborovom systéme a či jednotka obmedzuje zápisy inde. Potom otestujte dve po sebe idúce prihlásenia, pretože druhé dokazuje cestu zápisu a prvé iba čítanie.

Overujte ako služba, nie ako vy sami

Každá dôležitá kontrola musí bežať vo vnútri sandboxu jednotky s identitou jednotky.

Príkaz, ktorý uspeje ako root, vám povie, že súbor existuje, a nič viac. Prihlásenie cez skutočnú službu vám povie, či modul dokáže tajomstvo prečítať, použiť a zapísať späť to, čo potrebuje.

Nakoniec zachovajte požiadavku nedotknutú. Pridanie možnosti nulového hesla, prijatie zlyhaní iba pri čítaní alebo odstránenie sandboxu by všetky odstránili príznak zmenou politiky. Používateľ, ktorý musí predložiť kód, má byť aj naďalej odmietnutý, keď je tajomstvo nedostupné.