RAND_bytes ebaõnnestus OpenVPN-is: teegiviga või puuduv sõlm

RAND_bytes() failed on väide ühe kohaliku primitiivi kohta, mitte konto, eelnevalt jagatud võtme ega kaugporti kohta. Kaks väga erinevat riket tekitavad sama rea ja jätavad erinevad jäljed. Üks on krüptograafiline backend, mis keeldub baite väljastamast; teine on protsess, mis ei jõua entroopiaallikani, mille jaoks selle kood ehitati. Nende eristamiseks on vaja üht veajärjekorra lugemist ja üht pilku vangistatud protsessi failisüsteemi vaatele, ja see kontroll kuulub enne kõike, mis luuakse /dev all.

Mida tagastusväärtus eristab

Dokumenteeritud leping eristab kolme tulemust, mitte kahte: 1 edu korral, -1 kui laaditud RAND-meetod ei toeta päringut, ja 0 muude tõrgete korral, kusjuures selgitus jääb veajärjekorda. RAND_bytes viide lisab punkti, mida on lihtne tähelepanuta jätta: vaikegeneraator seemendab end toetatud platvormidel operatsioonisüsteemist, ja kui see seemendamine ebaõnnestub, jääb see veaseisundisse, selle asemel et ennustatavaid baite tagastada.

Ainult üks neist numbritest kirjeldab keskkonda. -1 on ehituse, teenusepakkuja või funktsiooni küsimus, sest kood küsis midagi, mida aktiivne teostus ei paku. 0 koos seemendamiskaebusega on keskkonnaküsimus, sest generaator ei suutnud entroopiat üldse hankida. Number iseenesest ei ütle kunagi, kumb neist, ja funktsiooni nimi samuti mitte.

Millal on peidetud seadmesõlm tegelik põhjus

Piiratud teenus näeb teist puud kui shell, kuhu te trükite. Chroot-jailid, konteineripildid ja karastatud unit-failid esitavad tavaliselt /dev, milles on vähem sõlmi kui hosti omas. Kui tõrkuv teostus avab /dev/urandom tee nime järgi, piisab sellest erinevusest käivituse rikkumiseks, samal ajal kui host ise näib täiesti terve. Väljaspool jaili eksisteeriv seade ei tõesta midagi selle kohta, mida vangistatud protsessil on lubatud avada.

Iga juhuslik liides ei vaja aga teed. Linuxi süsteemikõne getrandom ei võta vastu failinime ega failideskriptorit, ja selle käsiraamatu leht märgib, et see omadus on kasulik just seal, kus chroot peidab seadmete teed.

Seega on puuduva sõlme seletus hüpotees koodi ühe haru kohta, mitte reegel juhuslike arvude kohta üldiselt. See peab paika, kui tõendid nimetavad tee, ja see on oletus, kui tõendid nimetavad midagi muud.

Loe veajärjekorda, seejärel protsessi vaadet

Küsimuse lahendamiseks on kiireim lugeda seda, mida teek on juba registreerinud, ja seejärel vaadata otse jaili-sisest vaadet. Alustage OpenSSL-i ehitusest, mille teenus tegelikult laadis, sest teenusepakkujate virnad erinevad põhiversioonide ja distributsioonide vahel. Seejärel küsige systemdilt, milline protsess töötab ja millised piirangud sellele kehtivad. Alles siis, kui mõlemad faktid on laual, tasub loetleda sõlmed, mida see protsess näeb.

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

Käivitage need lugemised sama protsessi vastu, mitte selle shelli vastu, mis juhtub lahti olema. Võrrelda hosti /dev mitteseotud protsessi vaatega on viis, kuidas vale sõltuvus saab kaks korda parandatud.

Lisa sõltuvus alles siis, kui oskad seda nimetada

Kui tõendid tõesti nimetavad tee, on parandus väike: tehke see üks tee jailis kättesaadavaks ja jätke kõik muu rahule. Üksiku sõlme bind-mount on tavaliselt piisav, ja mknod sõlme standardsete major- ja minorarvudega annab sama tulemuse paigaldustes, kus mountimine pole valik. Liivakasti laiendamine, juurdepääsu andmine igale märgiseadmele või PrivateDevices väljalülitamine vahetab sihitud paranduse püsiva turberegressiooni vastu.

Entroopiadeemon ei asenda seda parandust. Paketid nagu haveged muudavad, kuidas kerneli basseini toidetakse; need ei saa luua teed, mille avamiseks vangistatud protsessil on luba. Ühe paigaldamine võib muuta tervisegraafiku paremaks, samal ajal kui avamiskõne ikka ebaõnnestub. Hoidke kaks probleemi lahus, muidu omistatakse järgmine tõrge jälle valele kihile.

Kontrolli generaatorit ja tunnelit eraldi

Taaskäivitus on ainus test, mis kasutab uuesti sama konfiguratsiooni, sama unit-faili ja sama isoleeritust, mis tõrke tekitasid. Käivitage see ja lugege seejärel uusimaid journali kirjeid, mitte varasema käivituse valimit.

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

Otsige sellest väljundist kahte eraldi asja: teadet juhusliku allika kadumise kohta ja tunnelit, mis jõuab oma tavalisse käivitumise vahe-eesmärki. Generaator, mis jälle töötab, kõrvaldab ühe kohaliku tõrke ega ütle midagi serveri identiteedi, volituste ega marsruutimise kohta. Testige seda sama kliendi konfiguratsiooniga, mis varem ebaõnnestus, et tulemus oleks võrreldav, mitte ainult parem.