auth-nocache med en legitimasjonsfil: hjelper det eller skader det?

OpenVPN skriver ved oppstart ut en advarsel som foreslår auth-nocache, og det fristende svaret er å legge til valget og se linjen forsvinne. Det rådet forutsetter en interaktiv innlogging. Når brukernavn og passord først ligger i en fil, endres sammenligningen: valget slutter å beskytte den varige kopien, og på en klient som slipper privilegier kan det senere ødelegge den nye forhandlingen. To lagringsmodeller er verdt å holde fra hverandre før du redigerer en profil.

To måter å svare på legitimasjonsforespørselen

Den første modellen er et menneske som skriver legitimasjon i en terminal, eller et administrasjonsgrensesnitt som holder dem for økten. OpenVPN beholder den kopien slik at den kan svare på neste forhandling uten å spørre igjen, og det er nettopp det advarselen handler om. Ingenting på disken er involvert, så det eneste som må beskyttes er prosessen som holder verdien. Lukk klienten, og kopien er borte med den.

Den andre modellen er auth-user-pass som peker på en fil, der filen er lageret og klienten leser den når en verdi trengs. Eksponeringen som betyr noe her, er ikke prosessminnet, men rettighetene og eierskapet til den filen. Oppstartsadvarselen kommer fra direktivene i konfigurasjonen, ikke fra en undersøkelse av hvordan du leverer passordet, så den vises i begge modellene og peker på ingen av dem.

Resten av denne sammenligningen følger av den delingen: minnehåndtering for den ene modellen, filhåndtering og prosessidentitet for den andre.

Hva auth-nocache faktisk forkaster

Med en interaktiv innlogging --auth-nocache fjerner den lagrede kopien fra minnet etter at den er brukt. Prisen er en ny forespørsel ved hvert forhandlingsintervall, fordi neste runde ikke kan gjenbruke det som ble forkastet.

Med innlogging basert på fil kan klienten lese filen på nytt, så forkastingen er stort sett usynlig. Den blir synlig på det ene stedet folk ikke forventer det: etter at daemonen har sluppet privilegier, hvis legitimasjonsfilen ikke kan leses av kontoen den nå kjører som.

Legg til valget fordi du forstår den avveiningen, ikke fordi det dukket opp en advarsel. Et valg som legges til for å gjøre en logg stillere, er et valg hvis virkning ingen har målt.

Hvor den filbaserte veien knekker

En klient som starter som root for å åpne tunneleenheten og deretter bytter til user og group leser legitimasjonsfilen to ganger: én gang før byttet, én gang ved forhandlingen som følger. Hvis filen har modus 600 og eies av root, mislykkes den andre lesingen, og feilen viser seg en time senere som en autentiseringsfeil som ser ut som et serverproblem. Sjekk klientloggen rundt forhandlingsintervallet, og sjekk deretter kontoen og filen sammen.

stat -c '%a %U:%G' /etc/openvpn/client.creds
ps -o user:12,args -C openvpn | head

Begge linjene betyr noe. Den første forteller deg hvem som kan lese filen, den andre forteller deg hvem den kjørende daemonen faktisk er, og et avvik mellom dem forklarer en feil som ingen mengde ny skriving av passordet vil rette.

De praktiske rettelsene er lite glamorøse: flytt filen til en mappe og en eier som daemonens konto kan lese, eller behold den privilegerte lesingen og bekreft at klienten din bare leser én gang. Ikke løs det ved å gjøre filen lesbar for alle.

Tilfellet som faktisk vil ha valget

En innlogging med engangskode vil ha auth-nocache av en annen grunn. En engangskode brukes opp av den første autentiseringen, så en bufret kopi er ubrukelig ved neste forhandling, og en utdatert verdi kan til og med spilles av igjen.

Det er et spørsmål om typen legitimasjon, ikke om hvor den lagres. Et statisk passord i en beskyttet fil har den motsatte profilen: det må kunne leses ved hver forhandling, og beskyttelsen du trenger, ligger på filen.

Hold de to grunnene atskilt i profilkommentarene, ellers vil den neste administratoren anta at valget er der av den grunnen han selv ville ha valgt.

Sammenligningen i én beslutning

Velg den interaktive modellen når et menneske er til stede og ferskhet betyr noe, og godta den gjentatte forespørselen som prisen. Velg filmodellen når klienten kjører uten tilsyn, og bruk innsatsen på eierskap, modus og privilegieslipp i stedet.

Ingen av modellene gjør et lagret passord trygt i seg selv, og ingen av dem gjør oppstartsadvarselen meningsfull.

Hvis advarselen er den eneste grunnen til at du åpnet profilen, noter beslutningen i stedet for et uforklart valg: legitimasjon kommer fra en fil som daemonens konto kan lese, en forhandling er sett å lykkes, og avsnittet om forhandling i OpenVPN 2.6-håndboken ble lest før intervallet ble endret. Den noten overlever enhver enkelt flagg.