ProtectHome kontraŭ TOTP-semoj: kial la VPN-ensaluto malsukcesas

La aŭtentigilo montras freŝan sesciferan kodon, la VPN rifuzas ĝin, kaj la sama kodo kontroliĝas senprobleme kiam vi testas el via propra ŝelo. Tiu breĉo estas la tuta historio. PAM-modulo, kiu ne povas malfermi la registran sekreton, redonas malsukceson kiu aspektas idente al malĝusta kodo, kaj la serva medio, kiu kaŝas hejmajn dosierujojn, estas ofta kaŭzo. Antaŭ ol malstreĉi ajnan permeson, decidu en kiu el tri situacioj vi estas.

Kiu el tri malsukcesoj estas ĉi tio?

La unua estas sekreto, kiun la modulo tute ne povas legi. La dua estas sekreto, kiun ĝi povas legi sed ne ĝisdatigi. La tria estas kodo, kiu vere estas malĝusta, kutime pro horloĝa drivo aŭ reuzita valoro.

Apartigu ilin legante la servan protokolon kaj la sisteman aŭtentigan protokolon por unu malsukcesa provo, poste konfirmu kiun PAM-servon la kromaĵo ŝarĝas kaj kiun modulan linion tiu servo uzas. Ĝenerala mesaĝo pri aŭtentiga malsukceso ne distingas ilin, nek sukcesa permana testo, ĉar via ŝelo ne estas la medio de la servo.

La dosiersistema vido de la unuo estas la kutima kulpulo kiam nur la servo malsukcesas.

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

Opcio A: movu la sekreton ekster la hejmon

Kiam la servo kaŝas /home kaj vi preferas konservi tiun protekton, konservu la sekreton ie, kie ĝi povas vidi ĝin. La modulo akceptas vojon secret= kaj konton user= kiu faras la dosierajn operaciojn, kio permesas al centra konservejo servi multajn identecojn.

Ĉi tio estas la ordema opcio, kaj ĝi postulas la plej grandan zorgon, ĉar komuna konservejo igas unu dosierujon la sekureca limo por ĉiu konto.

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

Kontrolu tri aferojn antaŭ ol fidi ĝin: la konto ekzistas, la laborproceso de la modulo povas ŝanĝi al ĝi, kaj la dosieroj apartenas al ĝi kun limigaj modoj. Ne uzu ~ aŭ vojon kun hejma variablo kune kun user=, kaj ne malŝaltu la posedajn kontrolojn de la modulo por igi vojon funkcii. Konservu la pasvortan etapon kaj la reston de la stako sendifektaj.

Opcio B: lasu la dosieron kaj malfermu vojon

Se la sekreto devas resti en la hejma dosierujo de la uzanto, la unuo bezonas vidon kiu inkluzivas tiun unu dosierujon sen malkaŝi ĉiun hejman dosierujon sur la gastiganto. Drop-in povas aldoni mallarĝe limigitan bind-muntadon sub sandboxita hejmo.

Ĉi tio konservas posedon laŭ uzanto kiel modelon, je la kosto de unuŝanĝo kiu devas esti reviziita ĉiufoje kiam la sandboxo ŝanĝiĝas.

Du limoj facile mankas. Legnura vojo aldonita sub dosierujo kiun la sandboxo kaŝas ne malkaŝas ĝin, ĉar la patro simple ne estas tie. Kaj la muntado devas esti skribebla se la modulo devas ĝisdatigi staton, kio enkondukas la sekvan opcion. Skribu la drop-in kiel apartan dosieron anstataŭ redakti la pakaĵan union sub /usr/lib, por ke pakaĵa ĝisdatigo ne silente nuligu ĝin.

Opcio C: konservu la sandboxon kaj ripari statskribojn

Legi la sekreton estas nur duono de aŭtentigo. La modulo povas reskribi temposkan informaĵon, reprotektadon aŭ nombrilon, kaj dosiero kiu trapasas la legan kontrolon ankoraŭ povas malsukcesi ĉe skribo.

Tiu malsukceso aspektas kiel malbona kodo ĉe la sekva provo anstataŭ ĉe ĉi tiu, tial ĝi estas konfuzata kun horloĝa drivo.

Donu al ĝi propran skribeblan dosierujon kaj direktu la sekretan vojon tien, anstataŭ igi la tutan hejmon skribebla. Konfirmu la posedanton de la dosierujo, la liberan spacon de la dosiersistemo kaj ĉu la unuo limigas skribojn aliloke. Poste testu du sinsekvajn ensalutojn, ĉar la dua pruvas la skriban vojon kaj la unua nur la legadon.

Kontrolu kiel la servo, ne kiel vi mem

Ĉiu grava kontrolo devas ruliĝi ene de la sandboxo de la unuo kun la identeco de la unuo.

Komando kiu sukcesas kiel root diras al vi, ke la dosiero ekzistas, kaj nenion alian. Ensaluto tra la reala servo diras al vi, ĉu la modulo povas legi la sekreton, uzi ĝin kaj reskribi tion, kion ĝi bezonas.

Fine, konservu la postulon sendifekta. Aldoni nulpasvortan opcion, akcepti legnurajn malsukcesojn aŭ forigi la sandboxon ĉiuj malaperigus la simptomon ŝanĝante la politikon. Uzanto devigata prezenti kodon ankoraŭ devas esti rifuzata kiam la sekreto estas neatingebla.