RAND_bytes mislukt in OpenVPN: bibliotheekfout of ontbrekend knooppunt

RAND_bytes() failed is een uitspraak over één lokale primitieve, niet over het account, de vooraf gedeelde sleutel of de externe poort. Twee heel verschillende fouten produceren diezelfde regel en laten verschillende sporen achter. De ene is een cryptografische backend die weigert bytes af te geven; de andere is een proces dat de entropiebron niet bereikt waarvoor zijn code is gebouwd. Ze scheiden vraagt één lezing van de foutenwachtrij en één blik op de bestandssysteemweergave van het opgesloten proces, en die controle hoort vóór alles wat onder /dev wordt aangemaakt.

Wat de retourwaarde onderscheidt

Het gedocumenteerde contract onderscheidt drie uitkomsten, niet twee: 1 voor succes, -1 wanneer de geladen RAND-methode het verzoek niet ondersteunt, en 0 voor andere fouten, waarbij de uitleg in de foutenwachtrij blijft. De RAND_bytes-referentie voegt een makkelijk te missen punt toe: de standaardgenerator initialiseert zich op ondersteunde platformen vanuit het besturingssysteem, en wanneer die initialisatie mislukt blijft hij in een foutstatus in plaats van voorspelbare bytes terug te geven.

Slechts één van die getallen beschrijft de omgeving. Een -1 is een kwestie van build, provider of functionaliteit, omdat de code iets vroeg wat de actieve implementatie niet biedt. Een 0 met een klacht over initialisatie is een omgevingskwestie, omdat de generator helemaal geen entropie kon verkrijgen. Het getal alleen zegt nooit welke van de twee, en de functienaam ook niet.

Wanneer een verborgen apparaatknooppunt de echte oorzaak is

Een ingeperkte dienst ziet een andere boom dan de shell waarin u typt. Chroot-jails, containerimages en gehardende unitbestanden laten geregeld een /dev zien met minder knooppunten dan dat van de host. Als de falende implementatie /dev/urandom op padnaam opent, is dat verschil genoeg om de start te breken terwijl de host zelf volkomen gezond lijkt. Een apparaat dat buiten de jail bestaat, bewijst niets over wat het opgesloten proces mag openen.

Niet elke random-interface heeft echter een pad nodig. De systeemaanroep getrandom van Linux accepteert geen bestandsnaam en geen bestandsdescriptor, en zijn manpagina merkt op dat die eigenschap juist nuttig is waar een chroot apparaatpaden verbergt.

De verklaring van het ontbrekende knooppunt is dus een hypothese over één tak van de code, geen regel over willekeurige getallen in het algemeen. Ze houdt stand wanneer het bewijs een pad noemt, en ze is giswerk wanneer het bewijs iets anders noemt.

Lees eerst de foutenwachtrij, dan de procesweergave

De snelste manier om de kwestie te beslechten is lezen wat de bibliotheek al heeft vastgelegd en dan rechtstreeks naar de weergave in de jail kijken. Begin met de OpenSSL-build die de dienst werkelijk heeft geladen, omdat providerstacks verschillen tussen hoofdversies en tussen distributies. Vraag daarna aan systemd welk proces draait en welke beperkingen ervoor gelden. Pas als beide feiten op tafel liggen, loont het de knooppunten op te sommen die dat proces kan zien.

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

Voer die uitlezingen uit tegen hetzelfde proces, niet tegen de shell die toevallig openstaat. De /dev van de host vergelijken met de weergave van een ongerelateerd proces is hoe de verkeerde afhankelijkheid twee keer wordt gerepareerd.

Voeg de afhankelijkheid pas toe als u haar kunt benoemen

Wanneer het bewijs wel een pad noemt, is de reparatie klein: maak dat ene pad beschikbaar binnen de jail en laat al het andere met rust. Een bind-mount van het enkele knooppunt volstaat meestal, en mknod met de standaard major- en minornummers van het knooppunt levert hetzelfde resultaat op installaties waar mounten geen optie is. De sandbox verruimen, toegang geven tot elk karakterapparaat of PrivateDevices uitschakelen ruilt een gerichte correctie voor een blijvende veiligheidsregressie.

Een entropie-daemon vervangt die reparatie niet. Pakketten zoals haveged veranderen hoe de kernelpool wordt gevoed; ze kunnen geen padnaam maken die een opgesloten proces mag openen. Er een installeren kan een gezondheidsgrafiek mooier laten lijken terwijl de open-aanroep nog steeds faalt. Houd de twee problemen gescheiden, anders wordt de volgende fout weer aan de verkeerde laag toegeschreven.

Controleer generator en tunnel afzonderlijk

Een herstart is de enige test die dezelfde configuratie, hetzelfde unitbestand en dezelfde inperking hergebruikt die de fout hebben veroorzaakt. Voer hem uit en lees dan de nieuwste journalregels in plaats van een steekproef uit een eerdere start.

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

Zoek twee afzonderlijke dingen in die uitvoer: het bericht over de random-bron dat verdwijnt, en de tunnel die zijn gebruikelijke startmijlpaal haalt. Een generator die weer werkt, haalt één lokale fout weg en zegt niets over serveridentiteit, inloggegevens of routing. Test dat met dezelfde clientconfiguratie die eerder faalde, zodat het resultaat vergelijkbaar is en niet alleen beter.