Pas uljes së privilegjeve: cilat skedarë OpenVPN vazhdojnë të punojnë?

Një kohë e gjatë funksionimi provon vetëm se nisja dha sukses me privilegjet që daemoni kishte në atë moment. Dështimet që kanë rëndësi këtu vijnë më vonë: një klient i ri lidhet, një listë revokimi zëvendësohet, një skript ndihmës duhet të shkruajë një skedar. Secila prej tyre është një hapje e re e kryer nga llogaria pa privilegje, me pyetjen e vet të lejeve dhe mesazhin e vet të gabimit. Tre vendime ndajnë një konfigurim që vazhdon të punojë nga ai që dështon në ngjarjen e ardhshme.

Ndani atë që u ngarkua herët nga ajo që hapet më vonë

Një përshkrues është një dorezë mbi një përshkrim të hapur skedari, dhe mënyra e aksesit u fiksua kur u krijua ai përshkrim. Ndryshimi i përdoruesit të procesit më vonë nuk e mbyll dorezën, prandaj një skedar çelësi i lexuar si root vazhdon të punojë pas uljes. As mënyra nuk ndryshon: një dorezë e hapur për lexim nuk bëhet e shkrueshme, dhe një dorezë e shkrueshme nuk tërhiqet vetëm sepse llogaria humbi të drejtat mbi shtegun. Këto dy fakte shpjegojnë pjesën më të madhe të sjelljes befasuese në këto raporte.

Gjysma tjetër është memoria. Daemoni mund të analizojë një certifikatë, të mbajë materialin e analizuar dhe të mbyllë skedarin; në përdorim mbeten të dhëna, jo një skedar i hapur. Prandaj trafiku i vazhdueshëm nuk provon as që një përshkrues është i hapur, as që emri i shtegut është i arritshëm. Provon vetëm se materiali i nevojshëm për sesionin aktual u sigurua më herët.

Një hapje e mëvonshme është një transaksion tjetër. Ajo zhvillohet nën kredencialet aktuale, kontekstin aktual të sigurisë dhe pamjen aktuale të montimit, kështu që një shteg i lexueshëm në nisje mund të refuzohet në lidhjen e ardhshme. Rrotullimi shton një kurth: shkrimi i një skedari të re mbi të njëjtin emër shtegu lë një përshkrues ekzistues të lidhur me objektin e vjetër, prandaj një rimbushje mund të duket e suksesshme ndërsa daemoni përdor ende përmbajtjen e mëparshme. Krahasoni inode që mban procesi me atë në disk përpara se të besoni një rrotullim.

Emërtoni tre leximet e kohës së ekzekutimit dhe kur ndodh secili

Tre burime normalisht hapen shumë pas inicializimit, dhe ato dështojnë në momente të ndryshme. Skedari i konfigurimit i një klienti të caktuar lexohet kur ai klient lidhet, prandaj mund të prishet për një përdorues ndërsa të tjerët vazhdojnë. Të dhënat e revokimit konsultohen gjatë vërtetimit të partnerit dhe përsëri kur skedari zëvendësohet. Një direktori e përkohshme preket vetëm kur një skript ose shtojcë shkruan diçka.

Asnjëri prej tre nuk i përket shtegut të nisjes, prandaj një server i shëndetshëm për javë mund të dështojë në lidhjen e ardhshme. Kategoria emërton edhe pronarin e rregullimit: dy të parët janë leje leximi mbi konfigurimin nën llogarinë e daemonit, dhe i treti është një vend i shkrueshëm me qëllim të ngushtë.

persist-key i përgjigjet një pyetjeje më të ngushtë sesa mendojnë shumica. Ai e mban skedarin e çelësit të hapur gjatë rivendosjeve të dokumentuara SIGUSR1 dhe ping-restart, dhe nuk bën asgjë për skedarët CCD, të dhënat e revokimit, ekzekutuesit ndihmës ose një rinisje të plotë të procesit. Ata vazhdojnë të ndjekin shtigjet e tyre të hapjes, nën çdo llogari që punon në atë moment.

Konfirmoni llogarinë dhe pamjen që ka vërtet

Pyetni daemonin që punon cilën llogari përdor në vend që t’i besoni skedarit unit, pastaj krahasoni përgjigjen me atë që unit vendos. Mospërputhja është gjëja e parë për t’u zgjidhur, sepse çdo kontroll lejeje i mëvonshëm zhvillohet si ai që procesi është vërtet. Pastaj ecni shtegun komponent pas komponenti; kalimi vlerësohet në çdo nivel, kështu që një skedar i lexueshëm brenda një direktorie të pakalueshme mbetet i palexueshëm. Mënyra përfundimtare e skedarit është pyetja e fundit, jo e para.

Hapësirat e emrave dhe kutitë e rërës së shërbimit shtojnë kufij që pronësia dhe bitet e mënyrës nuk i përshkruajnë. Një shteg i dukshëm në shellin tuaj mund të mungojë ose të jetë vetëm për lexim brenda një chroot, një hapësire emrash montimi ose një uniti që fsheh direktori shtëpie. Modulet e sigurisë shtojnë një shtresë tjetër, prandaj një skedar që duket i lexueshëm mund të refuzohet kur hapet.

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

Një lexim i suksesshëm në shellin e administratorit nuk provon asnjë nga ato kushte të kombinuara. Ekzekutoni kontrollin si llogaria e daemonit, me të njëjtën hapësirë emrash dhe kutinë e rërës, ose pranoni që rezultati përshkruan shellin tuaj dhe jo serverin. Komanda e tretë është versioni i lirë i atij testi: printon mënyrën e secilit komponent dhe dështon në të parin që llogaria e daemonit nuk mund të kalojë.

Jepini shkrimit të kohës së ekzekutimit një direktori të vetën

Leximi është vetëm gjysma e inventarit. Një skript ndihmës mund të ketë nevojë të krijojë një skedar statusi, një shtojcë mund të ketë nevojë të shkruajë gjendje pranë konfigurimit të saj, dhe këto shkrime nuk mbulohen duke e bërë pemën e konfigurimit të shkrueshme. Jepini direktorisë konkrete lejen e shkrimit që kërkon funksioni i saj, me një pronar dhe një mënyrë që mund t’i shpjegoni. Preferoni aksesin vetëm për lexim për çdo gjë që vetëm lexohet.

Mbani lejet e çelësit privat të ndara nga skedarët e politikës. Një çelës që duhet rilexuar pas një rivendosjeje ka një kërkesë të ndryshme nga një skedar klienti që lexohet në çdo lidhje, dhe një mënyrë lejuese për të dyja jep më shumë akses sesa kërkon problemi. Një llogari daemoni e dedikuar me pronësi të ngushtë auditohet më lehtë sesa një grup i gjerë. Kur çelësi duhet t’i mbijetojë rivendosjeve, persist-key heq rileximin në vend që të zgjerojë direktorinë.

Vendosni nga ngjarja që mund të riprodhoni

Një tunel i gjallë provon një shteg të vetëm në kod. Ngjarja që ka nevojë për skedarin është testi i vetëm që mbulon hapjen që ju intereson, qoftë një lidhje e re klienti, një skedar revokimi i zëvendësuar, një rivendosje e butë e lejuar ose një rinisje e planifikuar. Zgjidhni ngjarjen, ekzekutoni atë dhe mbani gabimin e parë në vend të atij të fundit.

Për një rivendosje të butë, një sinjal dhe regjistri i unitit tregojnë nëse çelësi u rilexua. Dërgoni sinjalin, pastaj lexoni rreshtat e fundit që shkroi uniti:

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

Mos përfundoni se një daemon i kompromentuar nuk mund të modifikojë më skedarë vetëm sepse privilegjet u ulën. Çfarë mund të bëjë ende varet nga kredencialet e mbetura, aftësitë e tij, direktori ku mund të shkruajë dhe çdo përshkrues i shkrueshëm që mban ende. Ulja e privilegjeve ngushton autoritetin, dhe inventari i hapjeve të kohës së ekzekutimit tregon sa. Shkruani atë kufi pranë konfigurimit që personi tjetër të mos duhet ta rizbulojë.