ProtectHome teenoor ’n TOTP-saad: waarom die VPN-aanmelding misluk

Die verifikasieprogram wys ’n nuwe sesyferkode, die VPN verwerp dit, en dieselfde kode verifieer foutloos wanneer jy dit uit jou eie skulp toets. Daardie gaping is die hele storie. ’n PAM-module wat nie die inskrywingsgeheim kan oopmaak nie, gee ’n fout wat identies lyk aan ’n verkeerde kode, en die diensomgewing wat tuisgidse wegsteek, is ’n algemene rede waarom dit nie kan nie. Voordat jy enige toestemming verslap, besluit in watter van drie situasies jy is.

Watter van drie mislukkings is dit?

Die eerste is ’n geheim wat die module glad nie kan lees nie. Die tweede is ’n geheim wat dit kan lees, maar nie kan bywerk nie. Die derde is ’n kode wat werklik verkeerd is, gewoonlik weens klokdrywing of ’n herspeelde waarde.

Skei hulle deur die diensjoernaal en die stelsel-verifikasielog vir een mislukte poging te lees, en bevestig dan watter PAM-diens die inprop laai en watter modulelyn daardie diens gebruik. ’n Algemene verifikasiefoutboodskap onderskei hulle nie, en ’n suksesvolle handmatige toets ook nie, want jou skulp is nie die diens se omgewing nie.

Die eenheid se lêerstelsel-aansig is die gewone skuldige wanneer net die diens misluk.

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

Opsie A: skuif die geheim uit die tuisgids

Wanneer die diens /home wegsteek en jy wil eerder daardie beskerming behou, stoor die geheim op ’n plek wat dit kan sien. Die module aanvaar ’n secret=-pad en ’n user=-rekening wat die lêerbewerkings uitvoer, wat ’n sentrale stoor baie identiteite laat bedien.

Dit is die netjiese opsie, en dit is die een wat die meeste sorg verg, want ’n gedeelde stoor maak ’n enkele gids die sekuriteitsgrens vir elke rekening.

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

Kontroleer drie dinge voordat jy dit vertrou: die rekening bestaan, die module se werkproses kan daarheen oorskakel, en die lêers word deur hom besit met beperkende lêermodusse. Moenie ~ of ’n tuisveranderlike-pad saam met user= gebruik nie, en moenie die module se eienaarskapkontroles deaktiveer om ’n pad te laat werk nie. Hou die wagwoordstadium en die res van die stapel ongeskonde.

Opsie B: laat die lêer staan en open ’n pad

As die geheim in die gebruiker se tuisgids moet bly, het die eenheid ’n aansig nodig wat daardie een gids insluit sonder om elke tuisgids op die gasheer bloot te lê. ’n Drop-in kan ’n noukeurig beperkte bind-monteer onder ’n gesandkaste tuisgids byvoeg.

Dit hou per-gebruiker eienaarskap as die model, ten koste van ’n eenheidswysiging wat hersien moet word wanneer die sandbox verander.

Twee grense word maklik gemis. ’n Lees-alleen-pad wat onder ’n gids gevoeg word wat die sandbox wegsteek, lê dit nie bloot nie, want die ouer is eenvoudig nie daar nie. En die montering moet skryfbaar wees as die module toestand moet bywerk, wat die volgende opsie in die spel bring. Skryf die drop-in as ’n aparte lêer eerder as om die verpakte eenheid onder /usr/lib te wysig, sodat ’n pakketopgradering dit nie stilweg ongedaan maak nie.

Opsie C: hou die sandbox en herstel toestandskrywes

Om die geheim te lees is net die helfte van verifikasie. Die module kan tydafwyking-inligting, herspelingsbeskerming of ’n teller herskryf, en ’n lêer wat die leestoets slaag, kan steeds die skryftoets faal.

Daardie mislukking lyk soos ’n slegte kode by die volgende poging eerder as by hierdie een, en daarom word dit met klokdrywing verwar.

Gee dit ’n eie skryfbare gids en wys die geheim se pad daarheen, eerder as om die hele tuisgids skryfbaar te maak. Bevestig die gids se eienaar, die lêerstelsel se vrye ruimte en of die eenheid elders skrywes beperk. Toets dan twee opeenvolgende aanmeldings, want die tweede een bewys die skryfpad en die eerste bewys net die lees.

Verifieer as die diens, nie as jyself nie

Elke kontrole wat saak maak, moet binne die eenheid se sandbox met die eenheid se identiteit loop.

’n Opdrag wat as root slaag, vertel jou dat die lêer bestaan en niks anders nie. ’n Aanmelding deur die werklike diens vertel jou of die module die geheim kan lees, gebruik en terugskryf wat dit nodig het.

Laastens, hou die vereiste ongeskonde. Om ’n nul-wagwoord-opsie by te voeg, lees-alleen-mislukkings te aanvaar of die sandbox te verwyder, sou almal die simptoom laat verdwyn deur die beleid te verander. ’n Gebruiker wat ’n kode moet voorlê, moet steeds verwerp word wanneer die geheim onbereikbaar is.