ProtectHome mot et TOTP-frø: hvorfor VPN-påloggingen feiler

Autentiseringsappen viser en fersk sekssifret kode, VPN avviser den, og den samme koden verifiseres fint når du tester den fra din egen shell. Det gapet er hele historien. En PAM-modul som ikke kan åpne registreringshemmeligheten, returnerer en feil som ser identisk ut med en feil kode, og tjenestemiljøet som skjuler hjemmekataloger er en vanlig årsak. Før du lemper på noen tillatelse, må du avgjøre hvilken av tre situasjoner du er i.

Hvilken av tre feil er dette?

Den første er en hemmelighet modulen ikke kan lese i det hele tatt. Den andre er en hemmelighet den kan lese, men ikke oppdatere. Den tredje er en kode som virkelig er feil, vanligvis på grunn av klokkedrift eller en gjenbrukt verdi.

Skill dem ved å lese tjenesteloggen og systemets autentiseringslogg for ett mislykket forsøk, og bekreft deretter hvilken PAM-tjeneste innstikket laster og hvilken modullinje den tjenesten bruker. En generisk autentiseringsfeil skiller dem ikke, og en vellykket manuell test gjør det heller ikke, fordi skallet ditt ikke er tjenestens miljø.

Enhetens filsystemvisning er den vanlige skyldige når bare tjenesten feiler.

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

Alternativ A: flytt hemmeligheten ut av hjemmet

Når tjenesten skjuler /home og du heller vil beholde den beskyttelsen, lagre hemmeligheten et sted den kan se den. Modulen godtar en secret=-sti og en user=-konto som utfører filoperasjonene, noe som lar et sentralt lager betjene mange identiteter.

Dette er det ryddige alternativet, og det er det som trenger mest omhu, fordi et delt lager gjør én katalog til sikkerhetsgrensen for hver konto.

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

Sjekk tre ting før du stoler på det: kontoen finnes, modulens arbeidsprosess kan bytte til den, og filene eies av den med restriktive moduser. Ikke bruk ~ eller en sti med hjemvariabel sammen med user=, og ikke slå av modulens eierskapskontroller for å få en sti til å virke. Hold passordfasen og resten av stakken intakt.

Alternativ B: la filen ligge og åpne en sti

Hvis hemmeligheten må bli i brukerens hjemmekatalog, trenger enheten en visning som inkluderer den ene katalogen uten å eksponere alle hjemmekataloger på verten. Et drop-in kan legge til en smalt avgrenset bind-mount under et sandkasse-hjem.

Dette beholder eierskap per bruker som modell, på bekostning av en enhetsendring som må gjennomgås hver gang sandkassen endres.

To grenser er lette å overse. En skrivebeskyttet sti lagt til under en katalog sandkassen skjuler, eksponerer den ikke, fordi forelderen rett og slett ikke er der. Og mountet må være skrivbart hvis modulen må oppdatere tilstand, noe som bringer det neste alternativet i spill. Skriv drop-in som en separat fil i stedet for å redigere den pakkede enheten under /usr/lib, slik at en pakkeoppgradering ikke stille angrer det.

Alternativ C: behold sandkassen og fiks tilstandsskrivinger

Å lese hemmeligheten er bare halvparten av autentiseringen. Modulen kan skrive om informasjon om tidsforskyvning, gjenoppspillingsbeskyttelse eller en teller, og en fil som består lesekontrollen kan fortsatt feile på skrivingen.

Den feilen ser ut som en dårlig kode ved neste forsøk i stedet for ved dette, og derfor forveksles den med klokkedrift.

Gi den sin egen skrivbare katalog og pek hemmelighetens sti dit, i stedet for å gjøre hele hjemmekatalogen skrivbar. Bekreft katalogens eier, filsystemets ledige plass og om enheten begrenser skrivinger andre steder. Test deretter to påfølgende pålogginger, fordi den andre beviser skrivestien og den første bare lesingen.

Verifiser som tjenesten, ikke som deg selv

Hver kontroll som betyr noe, må kjøre inne i enhetens sandkasse med enhetens identitet.

En kommando som lykkes som root, forteller deg at filen finnes og ingenting annet. En pålogging gjennom den faktiske tjenesten forteller deg om modulen kan lese hemmeligheten, bruke den og skrive tilbake det den trenger.

Til slutt, hold kravet intakt. Å legge til et nullpassord-alternativ, godta skrivebeskyttede feil eller fjerne sandkassen ville alle få symptomet til å forsvinne ved å endre policyen. En bruker som må legge frem en kode, skal fortsatt avvises når hemmeligheten er utilgjengelig.