Efter privilegietabet: hvilke OpenVPN-filer virker stadig?

Lang oppetid beviser kun, at opstarten lykkedes med de privilegier, som daemonen havde i det øjeblik. De fejl, der betyder noget her, kommer senere: en ny klient forbinder, en tilbagekaldelsesliste erstattes, et hjælpescript skal skrive en fil. Hver af dem er en ny åbning udført af den uprivilegerede konto, med sit eget tilladelsesspørgsmål og sin egen fejlmeddelelse. Tre beslutninger adskiller en konfiguration, der fortsat virker, fra en der fejler ved den næste hændelse.

Adskil det, der blev indlæst tidligt, fra det, der åbnes senere

En deskriptor er et håndtag til en åben filbeskrivelse, og adgangstilstanden blev fastlagt, da beskrivelsen blev oprettet. At skifte procesbruger bagefter lukker ikke håndtaget, og derfor virker en nøglefil læst som root stadig efter tabet. Tilstanden ændres heller ikke: et håndtag åbnet til læsning bliver ikke skrivbart, og et skrivbart håndtag tilbagekaldes ikke, blot fordi kontoen har mistet sine rettigheder til stien. Disse to kendsgerninger forklarer det meste af den overraskende adfærd i disse rapporter.

Den anden halvdel er hukommelse. En daemon kan parse et certifikat, beholde det parsede materiale og lukke filen; det, der er i brug, er data, ikke en åben fil. Fortsat trafik beviser derfor hverken at en deskriptor er åben eller at stinavnet er tilgængeligt. Det beviser kun, at materialet til den aktuelle session blev skaffet tidligere.

En senere åbning er en anden transaktion. Den kører under de aktuelle legitimationsoplysninger, den aktuelle sikkerhedskontekst og den aktuelle monteringsvisning, så en sti, der var læsbar ved opstart, kan afvises ved den næste forbindelse. Rotation tilføjer en fælde: at skrive en ny fil over samme stinavn lader en eksisterende deskriptor hænge ved det gamle objekt, så en genindlæsning kan se ud til at lykkes, mens daemonen stadig bruger det forrige indhold. Sammenlign den inode, processen holder, med den på disken, før du tror på en rotation.

Navngiv de tre runtime-læsninger og hvornår hver udløses

Tre ressourcer åbnes normalt længe efter initialiseringen, og de fejler på forskellige tidspunkter. En klientspecifik konfigurationsfil læses, når netop den klient forbinder, så den kan brække for én bruger, mens alle andre fortsætter. Tilbagekaldelsesdata konsulteres under peer-godkendelse og igen, når filen erstattes. En midlertidig mappe berøres kun, når et script eller plugin skriver noget.

Ingen af de tre hører til opstartsstien, og derfor kan en server, der har været sund i uger, fejle ved den næste forbindelse. Kategorien navngiver også ejeren af rettelsen: de to første er læserettigheder på konfiguration under daemon-kontoen, og den tredje er et skrivbart sted med et snævert formål.

persist-key besvarer et snævrere spørgsmål, end de fleste antager. Det holder nøglefilen åben gennem de dokumenterede SIGUSR1- og ping-restart-nulstillinger, og det gør intet for CCD-filer, tilbagekaldelsesdata, hjælpeprogrammer eller en fuld genstart af processen. De følger stadig deres egne åbningsstier, under den konto der kører på det tidspunkt.

Bekræft kontoen og den visning, den faktisk har

Spørg den kørende daemon, hvilken konto den bruger, i stedet for at stole på unit-filen, og sammenlign derefter svaret med det, uniten sætter. En uoverensstemmelse er det første, der skal løses, fordi hver senere tilladelseskontrol kører som den, processen virkelig er. Gå derefter stien igennem komponent for komponent; gennemløb vurderes på hvert niveau, så en læsbar fil i en mappe, der ikke kan gennemløbes, forbliver ulæselig. Den endelige filtilstand er det sidste spørgsmål, ikke det første.

Navnerum og tjeneste-sandkasser tilføjer grænser, som ejerskab og tilstandsbits ikke beskriver. En sti, der er synlig i din shell, kan mangle eller være skrivebeskyttet inde i en chroot, et monteringsnavnerum eller en unit, der skjuler hjemmemapper. Sikkerhedsmoduler tilføjer endnu et lag, så en fil, der ser læsbar ud, stadig kan afvises, når den åbnes.

ps -o user:12,pid,args -C openvpn
systemctl show -p User -p Group -p ProtectHome -p RootDirectory [email protected]
sudo -u openvpn namei -l /etc/openvpn/ccd/alice

En vellykket læsning i administrator-shellen tester ingen af disse kombinerede betingelser. Kør kontrollen som daemon-kontoen, med samme navnerum og sandkasse, eller accepter at resultatet beskriver din shell og ikke serveren. Den tredje kommando er den billige version af den test: den udskriver tilstanden for hver komponent og fejler på den første, som daemon-kontoen ikke kan gennemløbe.

Giv runtime-skrivningen sin egen mappe

Læsning er kun halvdelen af opgørelsen. Et hjælpescript skal måske oprette en statusfil, et plugin skal måske skrive tilstand ved siden af sin konfiguration, og de skrivninger dækkes ikke af at gøre konfigurationstræet skrivbart. Giv den konkrete mappe den skrivetilladelse, dens funktion kræver, med en ejer og en tilstand, du kan forklare. Foretræk skrivebeskyttet adgang til alt, der kun læses.

Hold den private nøgles tilladelser adskilt fra politikfilerne. En nøgle, der skal læses igen efter en nulstilling, har et andet krav end en klientfil, der læses ved hver forbindelse, og én eftergivende tilstand for begge giver mere adgang, end problemet kræver. En dedikeret daemon-konto med snævert ejerskab er lettere at revidere end en bred gruppe. Når nøglen skal overleve nulstillinger, persist-key fjerner den genlæsningen i stedet for at udvide mappen.

Beslut ud fra den hændelse, du kan reproducere

En levende tunnel beviser én vej gennem koden. Den hændelse, der har brug for filen, er den eneste test, der dækker den åbning, du bekymrer dig om, hvad enten det er en ny klientforbindelse, en erstattet tilbagekaldelsesfil, en tilladt blød nulstilling eller en planlagt genstart. Vælg hændelsen, kør den, og behold den første fejl i stedet for den sidste.

Ved en blød nulstilling viser ét signal og unitens log, om nøglen blev læst igen. Send signalet, og læs derefter de sidste linjer, uniten skrev:

systemctl kill -s SIGUSR1 [email protected]
journalctl -u [email protected] -n 40 --no-pager

Slut ikke, at en kompromitteret daemon ikke længere kan ændre filer, bare fordi privilegierne blev sænket. Hvad den stadig kan, afhænger af resterende legitimationsoplysninger, dens evner, de mapper den kan skrive i, og enhver skrivbar deskriptor, den stadig holder. Privilegiereduktion indsnævrer autoriteten, og opgørelsen af runtime-åbninger viser hvor langt. Skriv den grænse ved siden af konfigurationen, så den næste person ikke skal genopdage den.