ProtectHome versus semínko TOTP: proč přihlášení k VPN selhává
Správný kód nepomůže modulu PAM, který nemůže otevřít semínko. Vyberte mezi drop-in a zapisovatelnou cestou stavu, potom zkontrolujte jednotku.
Autentizátor zobrazí nový šestimístný kód, VPN ho odmítne a stejný kód se bez problémů ověří, když ho otestujete ve vlastním shellu. Tento rozdíl je celý příběh. Modul PAM, který nemůže otevřít tajemství registrace, vrací selhání, jež vypadá stejně jako špatný kód, a prostředí služby, které skrývá domovské adresáře, je častým důvodem. Než uvolníte jakékoli oprávnění, rozhodněte, ve které ze tří situací jste.
Které ze tří selhání to je?
První je tajemství, které modul vůbec nemůže přečíst. Druhé je tajemství, které přečíst může, ale nedokáže aktualizovat. Třetí je kód, který je opravdu špatný, obvykle kvůli posunu hodin nebo znovu použité hodnotě.
Oddělte je čtením deníku služby a systémového autentizačního logu pro jeden neúspěšný pokus, potom ověřte, kterou službu PAM zásuvný modul načítá a který řádek modulu tato služba používá. Obecná zpráva o selhání autentizace je nerozliší, stejně jako úspěšný ruční test, protože váš shell není prostředím služby.
Pohled jednotky na souborový systém je obvyklý viník, když selhává jen 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 20Možnost A: přesuňte tajemství z domovského adresáře
Když služba skrývá /home a vy chcete tuto ochranu zachovat, uložte tajemství tam, kde ho vidí. Modul přijímá cestu secret= a účet user=, který provádí souborové operace, což centrálnímu úložišti umožňuje obsluhovat mnoho identit.
Toto je úhledná možnost a vyžaduje nejvíce péče, protože sdílené úložiště činí z jednoho adresáře bezpečnostní hranici pro každý účet.
auth required pam_google_authenticator.so secret=/var/lib/vpn-otp/${USER}/.google_authenticator user=vpn-otpNež mu začnete věřit, zkontrolujte tři věci: účet existuje, pracovní proces modulu na něj může přejít a soubory jsou jeho s omezujícími režimy. Nepoužívejte ~ ani cestu s domovskou proměnnou spolu s user= a nevypínejte kontroly vlastnictví modulu, abyste cestu zprovoznili. Zachovejte fázi hesla a zbytek zásobníku nedotčené.
Možnost B: ponechte soubor a otevřete cestu
Pokud musí tajemství zůstat v domovském adresáři uživatele, jednotka potřebuje pohled, který zahrnuje tento jediný adresář, aniž by odhalil všechny domovské adresáře na hostiteli. Drop-in může přidat úzce omezené připojení pod izolovaným domovským adresářem.
Tím zůstává vlastnictví po uživatelích modelem, za cenu změny jednotky, kterou je třeba revidovat při každé změně sandboxu.
Dvě hranice lze snadno přehlédnout. Cesta pouze pro čtení přidaná pod adresář, který sandbox skrývá, ho neodhalí, protože rodič prostě není. A připojení musí být zapisovatelné, pokud modul musí aktualizovat stav, což přináší další možnost. Napište drop-in jako samostatný soubor, místo abyste upravovali zabalenou jednotku pod /usr/lib, aby ji aktualizace balíčku tiše nevrátila zpět.
Možnost C: ponechte sandbox a opravte zápisy stavu
Čtení tajemství je jen polovina autentizace. Modul může přepisovat informace o časovém posunu, ochranu proti opakování nebo čítač, a soubor, který projde kontrolou čtení, může stále selhat při zápisu.
Toto selhání vypadá jako špatný kód při dalším pokusu, nikoli při tomto, proto se zaměňuje s posunem hodin.
Dejte mu vlastní zapisovatelný adresář a namiřte tam cestu k tajemství, místo abyste zpřístupnili zápis do celého domovského adresáře. Ověřte vlastníka adresáře, volné místo v souborovém systému a zda jednotka omezuje zápisy jinde. Potom otestujte dvě po sobě jdoucí přihlášení, protože druhé dokazuje cestu zápisu a první jen čtení.
Ověřujte jako služba, ne jako vy
Každá důležitá kontrola musí běžet uvnitř sandboxu jednotky s identitou jednotky.
Příkaz, který uspěje jako root, vám řekne, že soubor existuje, a nic víc. Přihlášení skutečnou službou vám řekne, zda modul umí tajemství přečíst, použít a zapsat zpět, co potřebuje.
Nakonec zachovejte požadavek nedotčený. Přidání možnosti prázdného hesla, přijetí selhání pouze pro čtení nebo odstranění sandboxu by všechny odstranily příznak změnou politiky. Uživatel, který musí předložit kód, má být odmítnut i tehdy, když je tajemství nedostupné.