Hvor skal Linux gemme din VPN-adgangskode? Ikke i profilen
NetworkManagers hemmelighedsflag afgør, om profilen, en nøglering-agent eller ingen holder adgangskoden. Svaret afhænger af, hvornår forbindelsen starter.
VPN-adgangskoden skal bo et sted: i forbindelsesprofilen, i en nøglering som skrivebordet låser op, eller slet ingen steder. NetworkManager kalder det valg et hemmelighedsflag, og det er derfor en forbindelse virker efter login og fejler som tjeneste, når man vælger det forkerte. Flaget er én linje konfiguration, og det bestemmer, hvilket af de tre udfald du får.
Tre flag dækker næsten alle tilfælde, og beslutningen handler om, hvornår forbindelsen starter.
Tre hemmelighedsflag, tre adfærdsmønstre
Et flag på 0 betyder, at hemmeligheden gemmes sammen med forbindelsen, i hvilket lager der end holder profilen. Et flag på 1 gør den agent-ejet: hemmeligheden kommer fra en hemmelighedsagent som en skrivebordsnøglering, og NetworkManager spørger efter den ved aktivering. Et flag på 2 betyder ikke-gemt, så hemmeligheden skrives aldrig, og den skal leveres hver gang. Flag 4 markerer en hemmelighed som ikke påkrævet, for forbindelser der virkelig ikke har brug for nogen.
| Flag | Where it lives | Works unattended |
|---|---|---|
| 0 saved | Connection profile | Yes, if the store is readable |
| 1 agent-owned | Secret agent or keyring | Only if that agent is available |
| 2 not-saved | Nowhere | No |
Sæt flagene per hemmelighed i stedet for per forbindelse. Én forbindelse kan have en agent-ejet adgangskode og en gemt privatnøgle-adgangsfrase.
Beslut ud fra hvornår forbindelsen starter
Hvis en bruger, der er logget ind, starter forbindelsen, er agent-ejet det fornuftige standardvalg: nøgleringen låses op ved login, og hemmeligheden ligger aldrig i en fil. Hvis forbindelsen skal komme op, før nogen logger ind, er agent-ejet det forkerte valg, fordi der er ingen sessionsnøglering at låse op.
Det er hele beslutningen. Alt andet er en variant af den.
Til en tjeneste før login er et systemomfattende lager eller en beskyttet nøglefil det understøttede mønster, og filrettigheder bliver beskyttelsen. Løs ikke problemet ved at indsætte adgangskoden i et shell-script, der kører ved opstart.
Hvad nøgleringen giver, og hvad den ikke giver
En nøglering holder hemmeligheden ude af forbindelsesprofilen og binder den til en brugersession. Den gør ikke hemmeligheden tilgængelig for en tjeneste uden session, og den krypterer intet på forbindelsen. Det er adskilte egenskaber, som folk ofte blander sammen. Det, den faktisk køber, er en mindre skadesradius, når en profilfil lækker.
Den private nøgle, som profilen refererer til, har brug for sine egne rettigheder, uafhængigt af hvor adgangskoden bor.
Diagnosticering uden at dumpe hemmeligheder
Forbindelsesnavne, UUID'er og flag er som regel nok til at forklare en fejl. nmcli connection show lister profilen, og hemmelighedsflagene fortæller dig, hvor adgangskoden skulle komme fra.
Undgå --show-secrets i sager og chat. Når det først er indsat, er det en legitimation i en udskrift.
Lagring er ikke tilbagekaldelse
At fjerne en hemmelighed fra én nøglering gør ikke den legitimation ugyldig, som fjernoperatøren allerede har accepteret. Tilbagekaldelse af en konto er en handling på serversiden, og lokal lagring er en særskilt sag med en særskilt ejer.
Beslut begge dele før hændelsen, ikke under den. En interaktiv brugerforbindelse og en tjeneste før login har brug for forskellige svar, og et delt shell-script er ingen af delene. NetworkManagers dokumentation om hemmelighedsflag lister værdierne fuldt ud.