Na het afstoten van rechten: welke OpenVPN-bestanden werken nog?
Descriptoren die voor de overgang zijn geopend, blijven werken; paden die later opnieuw worden geopend niet. Bepaal welk van de drie runtime-bestanden uw configuratie opnieuw moet openen.
Een lange uptime bewijst alleen dat de start is geslaagd met de rechten die de daemon op dat moment had. De storingen die hier tellen, komen later: een nieuwe client verbindt, een intrekkingslijst wordt vervangen, een hulpscript moet een bestand schrijven. Elk daarvan is een nieuwe opening door het account zonder rechten, met zijn eigen rechtenvraag en zijn eigen foutmelding. Drie beslissingen scheiden een configuratie die blijft werken van een die bij de volgende gebeurtenis faalt.
Scheid wat vroeg is geladen van wat later wordt geopend
Een descriptor is een handvat op een open bestandsbeschrijving, en de toegangsmodus is vastgelegd toen die beschrijving werd gemaakt. Het later wisselen van procesgebruiker sluit het handvat niet, daarom blijft een sleutelbestand dat als root is gelezen na de overgang werken. De modus verandert ook niet: een handvat dat voor lezen is geopend wordt niet schrijfbaar, en een schrijfbaar handvat wordt niet ingetrokken alleen omdat het account zijn rechten op het pad kwijt is. Deze twee feiten verklaren het grootste deel van het verrassende gedrag in deze rapporten.
De andere helft is geheugen. Een daemon kan een certificaat parsen, het geparste materiaal bewaren en het bestand sluiten; wat in gebruik blijft zijn gegevens, geen geopend bestand. Doorlopend verkeer bewijst dus niet dat een descriptor open is, en ook niet dat de padnaam bereikbaar is. Het bewijst alleen dat het materiaal voor de huidige sessie eerder is verkregen.
Een latere opening is een andere transactie. Die loopt onder de huidige inloggegevens, de huidige beveiligingscontext en de huidige koppelweergave, zodat een pad dat bij de start leesbaar was bij de volgende verbinding kan worden geweigerd. Rotatie voegt een val toe: een nieuw bestand over dezelfde padnaam schrijven laat een bestaande descriptor aan het oude object vastzitten, zodat een herlaadbeurt geslaagd kan lijken terwijl de daemon nog de vorige inhoud gebruikt. Vergelijk de inode die het proces vasthoudt met die op schijf voordat u een rotatie gelooft.
Benoem de drie runtime-lezingen en wanneer elk optreedt
Drie bronnen worden gewoonlijk ruim na de initialisatie geopend, en ze falen op verschillende momenten. Een cliëntspecifiek configuratiebestand wordt gelezen wanneer precies die client verbindt, dus het kan voor één gebruiker breken terwijl de rest doorgaat. Intrekkingsgegevens worden geraadpleegd tijdens peer-authenticatie en opnieuw wanneer het bestand wordt vervangen. Een tijdelijke map wordt alleen aangeraakt wanneer een script of plug-in iets schrijft.
Geen van de drie hoort bij het startpad, daarom kan een server die weken gezond was bij de volgende verbinding falen. De categorie benoemt ook de eigenaar van de oplossing: de eerste twee zijn leesrechten op de configuratie onder het daemonaccount, en de derde is een schrijfbare locatie met een smal doel.
| Path reopened later | What triggers the open | First sign when it fails |
|---|---|---|
| Client configuration file | A connection for that client identity | One client rejected while others connect |
| Revocation data | Peer authentication, including after replacement | Revoked and valid peers both refused |
| Script or plugin temporary directory | A helper needs to create a file | The helper exits with a path error |
persist-key beantwoordt een smallere vraag dan de meeste mensen aannemen. Het houdt het sleutelbestand open tijdens de gedocumenteerde SIGUSR1- en ping-restart-resets, en het doet niets voor CCD-bestanden, intrekkingsgegevens, hulpprogramma’s of een volledige herstart van het proces. Die volgen nog steeds hun eigen openingspaden, onder welk account er op dat moment ook draait.
Bevestig het account en de weergave die het werkelijk heeft
Vraag de draaiende daemon welk account hij gebruikt in plaats van de unit-file te vertrouwen, en vergelijk het antwoord daarna met wat de unit instelt. Een afwijking is het eerste dat moet worden opgelost, want elke latere rechtencontrole draait als degene die het proces werkelijk is. Loop daarna het pad component voor component door; doorgang wordt op elk niveau beoordeeld, dus een leesbaar bestand in een map waar je niet doorheen kunt blijft onleesbaar. De uiteindelijke bestandsmodus is de laatste vraag, niet de eerste.
Namespaces en service-sandboxes voegen grenzen toe die eigendom en modusbits niet beschrijven. Een pad dat in uw shell zichtbaar is, kan ontbreken of alleen-lezen zijn binnen een chroot, een koppelnamespace of een unit die thuismappen verbergt. Beveiligingsmodules voegen nog een laag toe, zodat een bestand dat leesbaar lijkt bij het openen toch kan worden geweigerd.
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/aliceEen geslaagde lezing in de shell van de beheerder test geen van die gecombineerde voorwaarden. Voer de controle uit als het daemonaccount, met dezelfde namespace en sandbox, of accepteer dat het resultaat uw shell beschrijft en niet de server. De derde opdracht is de goedkope versie van die test: hij drukt de modus van elke component af en faalt op de eerste die het daemonaccount niet kan doorkruisen.
Geef het runtime-schrijven een eigen map
Lezen is maar de helft van de inventaris. Een hulpscript moet misschien een statusbestand aanmaken, een plug-in moet misschien toestand naast zijn configuratie schrijven, en die schrijfacties worden niet gedekt door de configuratieboom schrijfbaar te maken. Geef de specifieke map de schrijfpermissie die zijn functie nodig heeft, met een eigenaar en een modus die u kunt uitleggen. Geef de voorkeur aan alleen-lezen toegang voor alles wat alleen wordt gelezen.
Houd de rechten van de persoonlijke sleutel gescheiden van de beleidsbestanden. Een sleutel die na een reset opnieuw moet worden gelezen heeft een andere eis dan een cliëntbestand dat bij elke verbinding wordt gelezen, en één soepele modus voor beide geeft meer toegang dan het probleem vraagt. Een toegewijd daemonaccount met smal eigendom is gemakkelijker te auditen dan een brede groep. Wanneer de sleutel resets moet overleven, persist-key verwijdert het de herlezing in plaats van de map te verbreden.
Beslis op basis van de gebeurtenis die u kunt reproduceren
Een levende tunnel bewijst één pad door de code. De gebeurtenis die het bestand nodig heeft, is de enige test die de opening dekt die u belangrijk vindt, of dat nu een nieuwe clientverbinding is, een vervangen intrekkingsbestand, een toegestane zachte reset of een geplande herstart. Kies de gebeurtenis, voer die uit en houd de eerste fout vast in plaats van de laatste.
Bij een zachte reset tonen één signaal en het log van de unit of de sleutel opnieuw is gelezen. Stuur het signaal en lees daarna de laatste regels die de unit schreef:
systemctl kill -s SIGUSR1 [email protected]
journalctl -u [email protected] -n 40 --no-pagerConcludeer niet dat een gecompromitteerde daemon geen bestanden meer kan wijzigen alleen omdat de rechten zijn verlaagd. Wat hij nog kan, hangt af van de resterende inloggegevens, zijn mogelijkheden, de mappen waarin hij kan schrijven en elke schrijfbare descriptor die hij nog vasthoudt. Rechtensvermindering vernauwt de bevoegdheid, en de inventaris van runtime-openingen laat zien hoeveel. Schrijf die grens naast de configuratie zodat de volgende persoon hem niet opnieuw hoeft te ontdekken.