Na die voorregverlaging: watter OpenVPN-lêers werk nog?
Beskrywings wat voor die verlaging oopgemaak is, bly werk; paaie wat later heropen word, nie. Bepaal watter van die drie looptydlêers jou opstelling moet heropen.
Lang opstyd bewys net dat die begin geslaag het met die voorregte wat die diens op daardie oomblik gehad het. Die mislukkings wat hier saak maak, kom later: nuwe kliënt verbind, herroepingslys word vervang, hulpprogram moet lêer skryf. Elkeen is nuwe oopmaak deur die onbevoorregte rekening, met eie toestemmingsvraag en eie foutboodskap. Drie besluite skei opstelling wat bly werk van een wat by die volgende gebeurtenis faal.
Skei wat vroeg gelaai is van wat later oopgemaak word
Beskrywing is handvatsel op oop lêerbeskrywing, en die toegangmodus is vasgestel toe daardie beskrywing geskep is. Om later die prosesgebruiker te verander, sluit nie die handvatsel nie; daarom werk sleutellêer wat as root gelees is, na die verlaging. Die modus verander ook nie: handvatsel wat vir lees oopgemaak is, word nie skryfbaar nie, en skryfbare handvatsel word nie herroep net omdat die rekening sy regte op die pad verloor het nie. Daardie twee feite verduidelik meeste van die verrassende gedrag in hierdie verslae.
Die ander helfte is geheue. Diens kan sertifikaat ontleed, die ontlede materiaal hou en die lêer sluit; wat in gebruik bly, is data, nie oop lêer nie. Voortgesette verkeer bewys dus nie dat beskrywing oop is nie, en ook nie dat die padnaam bereikbaar is nie. Dit bewys net dat die materiaal vir die huidige sessie vroeër verkry is.
Latere oopmaak is ander transaksie. Dit loop onder huidige geloofsbriewe, huidige sekuriteitskonteks en huidige monteringsbeeld, so pad wat by opstart leesbaar was, kan by die volgende verbinding geweier word. Rotasie voeg valstrik by: nuwe lêer oor dieselfde padnaam laat bestaande beskrywing aan die ou objek geheg, so herlaai kan suksesvol lyk terwyl die diens nog vorige inhoud gebruik. Vergelyk die inode wat die proses hou met dié op skyf voordat op rotasie vertrou word.
Noem die drie looptyd-leesaksies en wanneer elkeen gebeur
Drie hulpbronne word gewoonlik lank na inisialisering oopgemaak, en hulle faal op verskillende oomblikke. Kliëntspesifieke konfigurasielêer word gelees wanneer daardie kliënt verbind, so dit kan vir een gebruiker breek terwyl ander aanhou. Herroepingsdata word tydens portuier-verifikasie geraadpleeg en weer wanneer die lêer vervang word. Tydelike gids word net aangeraak wanneer script of plugin iets skryf.
Nie een van die drie hoort by die opstartpad nie; daarom kan bediener wat weke lank gesond was, by die volgende verbinding faal. Die kategorie noem ook die eienaar van die oplossing: eerste twee is leestoestemming op konfigurasie onder die diensrekening, en die derde is skryfbare plek met nou 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 beantwoord n smaller vraag as wat meeste mense aanneem. Dit hou die sleutellêer oop oor die gedokumenteerde SIGUSR1- en ping-restart-herstellings, en dit doen niks vir CCD-lêers, herroepingsdata, hulpprogramme of volledige prosesherstarting nie. Dié volg steeds eie oopmaakpaaie, onder watter rekening ook al op daardie oomblik loop.
Bevestig die rekening en die beeld wat dit werklik het
Vra die lopende diens watter rekening dit gebruik eerder as om die unit-lêer te vertrou, en vergelyk dan die antwoord met wat die unit stel. n Verskil is die eerste ding om op te los, want elke latere toestemmingskontrole loop as wie die proses werklik is. Stap dan die pad een komponent op slag; deurgang word op elke vlak beoordeel, so leesbare lêer in onleesbare gids bly onleesbaar. Die finale lêermodus is die laaste vraag, nie die eerste nie.
Naamruimtes en dienssandbokse voeg grense by wat eienaarskap en modusbis nie beskryf nie. Pad wat in jou shell sigbaar is, kan afwesig of leesalleen wees binne chroot, monteringsnaamruimte of unit wat tuisgidse wegsteek. Sekuriteitsmodules voeg nog laag by, so lêer wat leesbaar lyk, kan steeds geweier word wanneer dit oopgemaak word.
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/aliceSuksesvolle lees in die administrateur se shell toets nie daardie gekombineerde voorwaardes nie. Hardloop die kontrole as die diensrekening, met dieselfde naamruimte en sandbok, of aanvaar dat die resultaat jou shell beskryf eerder as die bediener. Die derde opdrag is die goedkoop weergawe van daardie toets: dit druk die modus van elke komponent en faal by die eerste een wat die diensrekening nie kan deurgang nie.
Gee die looptyd-skryf n gids van sy eie
Lees is net die helfte van die inventaris. n Hulpscript mag statuslêer moet skep, n plugin mag toestand langs sy konfigurasie moet skryf, en daardie skryfwerk word nie gedek deur die konfigurasieboom skryfbaar te maak nie. Gee die spesifieke gids die skryftoestemming wat sy funksie nodig het, met eienaar en modus wat jy kan verduidelik.
Hou die privaatsleutel se toestemmings apart van die beleidlêers. n Sleutel wat na herstelling weer gelees moet word, het n ander vereiste as n kliëntlêer wat by elke verbinding gelees word, en een toegeeflike modus oor albei gee meer toegang as wat die probleem vra. n Toegewyde diensrekening met nou eienaarskap is makliker om te oudit as n breë groep. Wanneer die sleutel herstellings moet oorleef, persist-key verwyder die herlees eerder as om die gids te verbreed.
Besluit op grond van die gebeurtenis wat jy kan reproduseer
n Lewende tonnel bewys een pad deur die kode. Die gebeurtenis wat die lêer nodig het, is die enigste toets wat die oopmaak dek wat jou aangaan, of dit nou n nuwe kliëntverbinding, n vervangingsherroepingslêer, n toegelate sagte herstelling of n beplande herstarting is. Kies die gebeurtenis, hardloop dit, en hou die eerste fout eerder as die laaste.
Vir n sagte herstelling wys een sein en die unit se log of die sleutel weer gelees is. Stuur die sein, lees dan die laaste reëls wat die unit geskryf het:
systemctl kill -s SIGUSR1 [email protected]
journalctl -u [email protected] -n 40 --no-pagerMoenie aflei dat n gekompromitteerde diens nie meer lêers kan wysig net omdat voorregte verlaag is nie. Wat dit nog kan doen, hang af van oorblywende geloofsbriewe, vermoëns, gidse wat dit kan skryf en enige skryfbare beskrywing wat dit nog hou. Voorregverlaging vernou gesag, en die inventaris van looptyd-oopmakings wys hoe ver. Skryf daardie grens langs die konfigurasie sodat die volgende persoon dit nie weer hoef te ontdek nie.