RAND_bytes dështoi në OpenVPN: gabim biblioteke ose nyjë që mungon

RAND_bytes() failed është një pohim për një primitivë lokale, jo për llogarinë, çelësin e bashkëndarë paraprakisht ose portin e largët. Dy dështime shumë të ndryshme prodhojnë të njëjtin rresht dhe lënë gjurmë të ndryshme. Njëri është një backend kriptografik që refuzon të lëshojë bajt; tjetri është një proces që nuk arrin burimin e entropisë për të cilin u ndërtua kodi i tij. Ndaria e tyre kërkon një lexim të radhës së gabimeve dhe një vështrim mbi pamjen e sistemit të skedarëve të procesit të burgosur, dhe ai kontroll përket përpara çdo gjëje që krijohet nën /dev.

Çfarë dallon vlera e kthimit

Kontrata e dokumentuar ndan tre rezultate, jo dy: 1 për sukses, -1 kur metoda e ngarkuar RAND nuk e mbështet kërkesën, dhe 0 për dështime të tjera, me shpjegimin e lënë në radhën e gabimeve. Referenca e RAND_bytes shton një pikë që është e lehtë të kalosh pa e vënë re: gjeneratori i parazgjedhur merr farë nga sistemi operativ në platformat e mbështetura, dhe kur ajo mbjellje dështon ai mbetet në një gjendje gabimi në vend që të kthejë bajt të parashikueshëm.

Vetëm njëri prej atyre numrave përshkruan mjedisin. -1 është çështje ndërtimi, ofruesi ose funksionaliteti, sepse kodi kërkoi diçka që implementimi aktiv nuk e ofron. 0 me një ankesë për mbjelljen është çështje mjedisi, sepse gjeneratori nuk arriti të marrë fare entropi. Numri vetëm nuk thotë kurrë se cili, dhe as emri i funksionit.

Kur një nyjë pajisjeje e fshehur është shkaku i vërtetë

Një shërbim i kufizuar sheh një pemë tjetër nga ajo e guaskës ku po shkruani. Burgjet chroot, imazhet e kontejnerëve dhe skedarët e njësisë të forcimit paraqesin zakonisht një /dev që mban më pak nyje sesa ai i hostit. Nëse implementimi që dështon hap /dev/urandom sipas shtegut, ai ndryshim mjafton për të prishur nisjen ndërsa hosti vetë duket plotësisht i shëndetshëm. Një pajisje që ekziston jashtë burgut nuk provon asgjë për atë që procesi i burgosur lejohet të hapë.

Jo çdo ndërfaqe e rastësishme ka nevojë për një shteg, megjithatë. Thirrja e sistemit getrandom e Linux nuk pranon as emër skedari as përshkrues skedari, dhe faqja e saj e manualit vëren se kjo veti është e dobishme pikërisht aty ku një chroot fsheh shtegjet e pajisjeve.

Pra shpjegimi i nyjës që mungon është një hipotezë për një degë të kodit, jo një rregull për numrat e rastësishëm në përgjithësi. Ai qëndron kur provat emërtojnë një shteg, dhe është hamendje kur provat emërtojnë diçka tjetër.

Lexo radhën e gabimeve, pastaj pamjen e procesit

Mënyra më e shpejtë për ta zgjidhur çështjen është të lexoni atë që biblioteka ka regjistruar tashmë, dhe pastaj të shikoni drejtpërdrejt pamjen brenda burgut. Filloni me ndërtimin e OpenSSL që shërbimi ngarkoi vërtet, sepse rafte ofruesish ndryshojnë midis versioneve kryesore dhe midis shpërndarjeve. Pyetni më pas systemd cili proces po ekzekutohet dhe cilat kufizime zbatohen për të. Vetëm pasi të dy faktet janë mbi tavolinë ia vlen të listohen nyjet që ai proces mund të shohë.

openssl version -a
systemctl show openvpn-server@lab -p MainPID -p PrivateDevices -p DevicePolicy
pid=$(systemctl show -p MainPID --value openvpn-server@lab)
sudo ls -l /proc/"$pid"/root/dev/urandom /proc/"$pid"/root/dev/random

Kryejini ato lexime kundër të njëjtit proces, jo kundër guaskës që ndodh të jetë e hapur. Krahasimi i /dev të hostit me pamjen e një procesi të palidhur është mënyra se si varësia e gabuar riparohet dy herë.

Shto varësinë vetëm pasi mund ta emërtosh

Kur provat vërtet emërtojnë një shteg, riparimi është i vogël: bëni të disponueshëm atë shteg të vetëm brenda burgut dhe lini çdo gjë tjetër të qetë. Një bind mount i nyjës së vetme zakonisht mjafton, dhe mknod me numrat standardë major dhe minor të nyjës jep të njëjtin rezultat në instalime ku montimi nuk është opsion. Zgjerimi i sandbox-it, dhënia e aksesit për çdo pajisje karakteri ose fikja e PrivateDevices ndërron një rregullim të synuar me një regresion të përhershëm sigurie.

Një demon entropie nuk është zëvendësim për atë riparim. Paketat si haveged ndryshojnë se si ushqyehet pishina e kernelit; ato nuk mund të krijojnë një shteg që një proces i burgosur lejohet ta hapë. Instalimi i njërit mund ta bëjë një grafik shëndeti të duket më mirë ndërsa thirrja e hapjes vazhdon të dështojë. Mbaji problemet të dyja të ndara, përndryshe dështimi tjetër do t'i atribuohet përsëri shtresës së gabuar.

Verifiko gjeneratorin dhe tunelin veçmas

Një rinisje është testi i vetëm që ripërdor të njëjtin konfigurim, të njëjtin skedar njësie dhe të njëjtin izolim që prodhoi dështimin. Ekzekutoje, pastaj lexo shënimet më të reja të revistës në vend të një kampioni nga një nisje e mëparshme.

sudo systemctl restart openvpn-server@lab
sudo journalctl -u openvpn-server@lab --since -5min --no-pager | grep -iE 'rand|entropy|Initialization Sequence'

Kërko dy gjëra të ndara në atë dalje: mesazhin për burimin e rastësishëm që zhduket, dhe tunelin që arrin pikën e tij të zakonshme të nisjes. Një gjenerator që punon përsëri heq një dështim lokal dhe nuk thotë asgjë për identitetin e serverit, kredencialet ose rrugëtimin. Testoje me të njëjtin konfigurim klienti që dështoi më parë, që rezultati të jetë i krahasueshëm dhe jo thjesht më i mirë.