ProtectHome tsjin in TOTP-sied: wêrom't de VPN-oanmelding mislearret

De autentikaasje-app lit in nije seis-siferkoade sjen, de VPN wiist dy ôf, en deselde kode ferifiearret sûnder probleem as jo him út jo eigen shell testen. Dat gat is it hiele ferhaal. In PAM-module dy't it ynskriuwingsgeheim net iepenje kin, jout in flater werom dy't der itselde útsjocht as in ferkearde kode, en de tsjinstomjouwing dy't thúsmapen ferberget is in faak foarkommende reden. Foardat jo hokker tastimming dan ek fersoepje, beslute yn hokker fan trije situaasjes jo binne.

Hokker fan trije mislearrings is dit?

De earste is in geheim dat de module hielendal net lêze kin. De twadde is in geheim dat er lêze kin mar net bywurkje. De tredde is in kode dy't echt ferkeard is, meast troch klokdrift of in werbrûkte wearde.

Skoattje se troch it tsjinstdeiboek en it systeem-autentikaasjeloch foar ien mislearre poging te lêzen, en befêstigje dan hokker PAM-tsjinst de plugin ladt en hokker module-rigel dy tsjinst brûkt. In algemien autentikaasjeflaterberjocht ûnderskiedt se net, en in suksesfolle hânmjittige test ek net, want jo shell is net de omjouwing fan 'e tsjinst.

De bestandssysteemwerjefte fan 'e ienheid is de gewoane skuldige as allinnich de tsjinst mislearret.

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

Opsje A: ferpleatse it geheim út 'e thúsmap

As de tsjinst /home ferberget en jo leaver dy beskerming hâlde, bewarje it geheim dan earne dêr't er it sjen kin. De module akseptearret in secret=-paad en in user=-account dy't de bestandsbewurkingen docht, wêrtroch't in sintraal opslachplak in protte identiteiten betsjinje kin.

Dit is de oarderlike opsje, en it is dejinge dy't it measte soarch freget, want in dield opslachplak makket fan ien map de feiligensgrins foar elk account.

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

Kontrolearje trije dingen foardat jo it fertrouwe: it account bestiet, it wurkproses fan 'e module kin dêrhinne oerskeakelje, en de bestannen binne fan him mei beheinende modi. Brûk gjin ~ of in thúsferoarigerpaad tegearre mei user=, en skeakelje de eigendomskontrôles fan 'e module net út om in paad wurkje te litten. Hâld de wachtwurdstap en de rest fan 'e stack yntakt.

Opsje B: lit it bestân stean en iepenje in paad

At it geheim yn 'e thúsmap fan 'e brûker bliuwe moat, hat de ienheid in werjefte nedich dy't dy iene map omfettet sûnder alle thúsmapen op 'e host bleat te lizzen. In drop-in kin in nau beheinde bind-mount ûnder in sandboxe thúsmap tafoegje.

Dit hâldt eigendom per brûker as model, tsjin de kosten fan in ienheidsferoaring dy't besjoen wurde moat wannear't de sandbox feroaret.

Twa grinzen wurde maklik mist. In lês-allinnich paad tafoege ûnder in map dy't de sandbox ferberget, leit dy net bleat, want de âlder is gewoanwei net dêr. En de mount moat skriuwber wêze as de module de steat bywurkje moat, wat de folgjende opsje yn it spul bringt. Skriuw de drop-in as in apart bestân ynstee fan de ferpakke ienheid ûnder /usr/lib te bewurkjen, sadat in pakketfernijing him net stil útskeakelje kin.

Opsje C: hâld de sandbox en reparearje steatsskriuwsels

It geheim lêze is mar de helte fan autentikaasje. De module kin tiidôfwikingynformaasje, werhellingsbeskerming of in teller oerskriuwe, en in bestân dat de lês-kontrôle trochstiet kin noch altyd op skriuwen mislearje.

Dy mislearring liket by de folgjende poging op in minne kode, net by dizze, en dêrom wurdt er mei klokdrift ferwiksele.

Jou it in eigen skriuwbere map en wiis it geheimpaad dêrhinne, ynstee fan 'e hiele thúsmap skriuwber te meitsjen. Befêstigje de eigner fan 'e map, de frije romte fan it bestandssysteem en oft de ienheid skriuwsels earne oars beheint. Testje dan twa opienfolgjende oanmeldingen, want de twadde bewissiget it skriuwpaad en de earste allinnich it lêzen.

Ferifiearje as de tsjinst, net as josels

Elke kontrôle dy't ta saak docht moat binnen de sandbox fan 'e ienheid mei de identiteit fan 'e ienheid rinne.

In kommando dat as root slagget fertelt jo dat it bestân bestiet en fierder neat. In oanmelding fia de echte tsjinst fertelt jo oft de module it geheim lêze, brûke en weromskriuwe kin wat er nedich hat.

Ta beslút, hâld de eask yntakt. In nul-wachtwurd-opsje tafoegje, lês-allinnich-flaters akseptearje of de sandbox fuorthelje soene allegear it symptoom ferdwine litte troch it belied te feroarjen. In brûker dy't in kode leverje moat, moat noch altyd wegere wurde as it geheim net berikber is.