ProtectHome vastaan TOTP-siemen: miksi VPN-kirjautuminen epäonnistuu

Todennussovellus näyttää tuoreen kuusinumeroisen koodin, VPN hylkää sen, ja sama koodi vahvistuu moitteettomasti, kun testaat sitä omasta komentotulkistasi. Tämä ero on koko tarina. PAM-moduuli, joka ei voi avata rekisteröitymissalaisuutta, palauttaa virheen, joka näyttää täsmälleen samalta kuin väärä koodi, ja kotihakemistot piilottava palveluympäristö on yleinen syy siihen. Ennen kuin löysäät mitään käyttöoikeutta, päätä, missä kolmesta tilanteesta olet.

Mikä kolmesta epäonnistumisesta tämä on?

Ensimmäinen on salaisuus, jota moduuli ei voi lukea lainkaan. Toinen on salaisuus, jonka se voi lukea mutta jota se ei voi päivittää. Kolmas on koodi, joka on todella väärä, yleensä kellon ajautumisen tai uudelleen käytetyn arvon takia.

Erottele ne lukemalla palvelun loki ja järjestelmän todennusloki yhden epäonnistuneen yrityksen osalta ja vahvistamalla sitten, minkä PAM-palvelun liitännäinen lataa ja mitä moduuliriviä kyseinen palvelu käyttää. Yleinen todennusvirheilmoitus ei erottele niitä, eikä onnistunut manuaalinen testi, koska komentotulkkisi ei ole palvelun ympäristö.

Yksikön tiedostojärjestelmänäkymä on tavallinen syyllinen, kun vain palvelu epäonnistuu.

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

Vaihtoehto A: siirrä salaisuus pois kotoa

Kun palvelu piilottaa /home-hakemiston ja haluat mieluummin säilyttää tämän suojan, tallenna salaisuus jonnekin, missä se voi nähdä sen. Moduuli hyväksyy secret=-polun ja user=-tilin, joka tekee tiedostotoiminnot, mikä antaa keskitetyn säilön palvella monia identiteettejä.

Tämä on siisti vaihtoehto, ja se vaatii eniten huolellisuutta, koska jaettu säilö tekee yhdestä hakemistosta jokaisen tilin turvarajan.

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

Tarkista kolme asiaa ennen kuin luotat siihen: tili on olemassa, moduulin työprosessi voi vaihtaa siihen, ja tiedostot ovat sen omistuksessa rajoittavilla tiloilla. Älä käytä ~-merkkiä tai kotimuuttujapolkua yhdessä user=-asetuksen kanssa äläkä poista moduulin omistustarkistuksia saadaksesi polun toimimaan. Pidä salasanavaihe ja muun pinon osat ehjinä.

Vaihtoehto B: jätä tiedosto ja avaa polku

Jos salaisuuden on jäätävä käyttäjän kotihakemistoon, yksikkö tarvitsee näkymän, joka sisältää juuri tuon hakemiston paljastamatta isännän kaikkia kotihakemistoja. Drop-in voi lisätä kapeasti rajatun sidontaliitoksen hiekkalaatikkoon kuuluvan kodin alle.

Tämä pitää käyttäjäkohtaisen omistuksen mallina, mutta edellyttää yksikkömuutosta, joka on tarkistettava aina, kun hiekkalaatikko muuttuu.

Kaksi rajaa jää helposti huomaamatta. Vain luku -polku, joka lisätään hakemistoon, jonka hiekkalaatikko piilottaa, ei paljasta sitä, koska ylähakemisto yksinkertaisesti puuttuu. Ja liitoksen on oltava kirjoitettava, jos moduulin on päivitettävä tilaa, mikä tuo seuraavan vaihtoehdon esiin. Kirjoita drop-in erillisenä tiedostona sen sijaan, että muokkaisit /usr/lib-hakemiston alla olevaa pakattua yksikköä, jotta paketin päivitys ei kumoa sitä äänettömästi.

Vaihtoehto C: pidä hiekkalaatikko ja korjaa tilan kirjoitukset

Salaisuuden lukeminen on vain puolet todennuksesta. Moduuli voi kirjoittaa uudelleen aikaeron tiedot, toistonsuojauksen tai laskurin, ja lukutarkistuksen läpäisevä tiedosto voi silti epäonnistua kirjoituksessa.

Tuo epäonnistuminen näyttää huonolta koodilta seuraavalla yrityksellä, ei tällä, minkä vuoksi se sekoitetaan kellon ajautumiseen.

Anna sille oma kirjoitettava hakemisto ja osoita salaisuuden polku sinne sen sijaan, että tekisit koko kodista kirjoitettavan. Vahvista hakemiston omistaja, tiedostojärjestelmän vapaa tila ja se, rajoittaako yksikkö kirjoituksia muualla. Testaa sitten kaksi peräkkäistä kirjautumista, koska toinen todistaa kirjoituspolun ja ensimmäinen vain lukemisen.

Vahvista palveluna, älä itsenäsi

Jokaisen merkityksellisen tarkistuksen on ajettava yksikön hiekkalaatikon sisällä yksikön identiteetillä.

Komento, joka onnistuu rootina, kertoo, että tiedosto on olemassa, eikä mitään muuta. Kirjautuminen varsinaisen palvelun kautta kertoo, voiko moduuli lukea salaisuuden, käyttää sitä ja kirjoittaa takaisin tarvitsemansa.

Lopuksi pidä vaatimus ehjänä. Nollasalasanavaihtoehdon lisääminen, vain luku -virheiden hyväksyminen tai hiekkalaatikon poistaminen kaikki poistaisivat oireen muuttamalla käytäntöä. Käyttäjä, jonka on esitettävä koodi, on edelleen hylättävä, kun salaisuus ei ole saatavilla.