ProtectHome proti semenu TOTP: zakaj prijava v VPN ne uspe

Aplikacija za preverjanje prikaže novo šestmestno kodo, VPN jo zavrne, ista koda pa se brez težav preveri, ko jo preizkusite v svoji lupini. Ta razlika je cela zgodba. Modul PAM, ki ne more odpreti skrivnosti registracije, vrne napako, ki je videti enako kot napačna koda, okolje storitve, ki skriva domače mape, pa je pogost vzrok. Preden popustite katero koli dovoljenje, se odločite, v kateri od treh situacij ste.

Katera od treh napak je to?

Prva je skrivnost, ki je modul sploh ne more prebrati. Druga je skrivnost, ki jo lahko prebere, a je ne more posodobiti. Tretja je koda, ki je res napačna, običajno zaradi odstopanja ure ali znova uporabljene vrednosti.

Ločite jih tako, da preberete dnevnik storitve in sistemski dnevnik preverjanja za en neuspešen poskus, nato potrdite, katero storitev PAM nalaga vtičnik in katero vrstico modula uporablja ta storitev. Splošno sporočilo o neuspešnem preverjanju jih ne loči, prav tako ne uspešen ročni preizkus, ker vaša lupina ni okolje storitve.

Pogled enote na datotečni sistem je običajni krivec, ko odpove samo storitev.

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žnost A: premaknite skrivnost iz domače mape

Ko storitev skriva /home in želite to zaščito obdržati, shranite skrivnost tja, kjer jo lahko vidi. Modul sprejme pot secret= in račun user=, ki izvaja datotečne operacije, kar osrednji shrambi omogoča streženje številnih identitet.

To je urejena možnost in zahteva največ pozornosti, ker skupna shramba naredi eno mapo varnostno mejo vsakega računa.

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

Preden ji zaupate, preverite tri stvari: račun obstaja, delovni proces modula lahko preklopi nanj in datoteke so njegove z omejitvenimi načini. Ne uporabljajte ~ ali poti s spremenljivko doma skupaj z user= in ne onemogočite preverjanj lastništva modula, da bi pot delovala. Ohranite fazo gesla in preostanek sklada nedotaknjene.

Možnost B: pustite datoteko in odprite pot

Če mora skrivnost ostati v uporabnikovi domači mapi, enota potrebuje pogled, ki vključuje to eno mapo, ne da bi razkril vse domače mape na gostitelju. Drop-in lahko doda tesno omejeno vezno priklopitev pod peskovnikom zaščiteno domačo mapo.

To ohranja lastništvo na uporabnika kot model, za ceno spremembe enote, ki jo je treba pregledati ob vsaki spremembi peskovnika.

Dve meji zlahka spregledate. Pot samo za branje, dodana pod mapo, ki jo peskovnik skriva, je ne razkrije, ker nadrejene mape preprosto ni. In priklopitev mora biti zapisljiva, če mora modul posodobiti stanje, kar v igro vnese naslednjo možnost. Zapišite drop-in kot ločeno datoteko, namesto da urejate pakirano enoto pod /usr/lib, da je nadgradnja paketa ne razveljavi tiho.

Možnost C: ohranite peskovnik in popravite pisanje stanja

Branje skrivnosti je le polovica preverjanja. Modul lahko prepiše podatke o časovnem odmiku, zaščito pred ponovitvijo ali števec, in datoteka, ki prestane preverjanje branja, lahko še vedno ne uspe pri pisanju.

Ta napaka je videti kot slaba koda pri naslednjem poskusu in ne pri tem, zato jo zamenjujejo z odstopanjem ure.

Dajte mu lastno zapisljivo mapo in usmerite pot skrivnosti tja, namesto da bi naredili zapisljivo celotno domačo mapo. Potrdite lastnika mape, prosti prostor datotečnega sistema in ali enota omejuje pisanje drugje. Nato preizkusite dve zaporedni prijavi, ker druga dokazuje pot pisanja, prva pa le branje.

Preverjajte kot storitev, ne kot sebe

Vsako pomembno preverjanje mora teči znotraj peskovnika enote z identiteto enote.

Ukaz, ki uspe kot root, vam pove, da datoteka obstaja, in nič drugega. Prijava prek prave storitve vam pove, ali lahko modul prebere skrivnost, jo uporabi in zapiše nazaj, kar potrebuje.

Na koncu ohranite zahtevo nedotaknjeno. Dodajanje možnosti ničelnega gesla, sprejemanje napak samo za branje ali odstranitev peskovnika bi vse odpravilo simptom s spremembo politike. Uporabnik, ki mora predložiti kodo, mora biti še vedno zavrnjen, ko skrivnost ni dosegljiva.