RAND_bytes mislukkast i OpenVPN: bibliotekfeil eller manglande node

RAND_bytes() failed er ei utsegn om éin lokal primitiv, ikkje om kontoen, den førehandsdelte nøkkelen eller fjernporten. To svært ulike feil gjev same linja og lèt att ulike spor. Den eine er ein kryptografisk backend som nektar å senda ut byte; den andre er ein prosess som ikkje når entropikjelda han vart bygd for. Å skilja dei krev éi lesing av feilkøen og eitt blikk på filsystemvisinga til den innestengde prosessen, og den kontrollen høyrer til før noko vert oppretta under /dev.

Kva returverdien skil

Den dokumenterte kontrakten skil tre utfall, ikkje to: 1 for suksess, -1 når den innlasta RAND-metoden ikkje støttar førespurnaden, og 0 for andre feil, med forklaringa overlaten til feilkøen. RAND_bytes-referansen legg til eit punkt som er lett å oversjå: standardgeneratoren startar frå operativsystemet på støtta plattformer, og når den oppstarten feilar, vert han ståande i ein feiltilstand i staden for å levera føreseielege byte.

Berre eitt av desse tala skildrar miljøet. Ein -1 er eit spørsmål om bygg, leverandør eller funksjonalitet, fordi koden bad om noko den aktive implementeringa ikkje tilbyr. Ein 0 med ei klage om oppstart er eit miljøspørsmål, fordi generatoren ikkje fekk tak i entropi i det heile. Talet åleine seier aldri kva av dei, og funksjonsnamnet gjer det heller ikkje.

Når ein skjult eining-node er den eigentlege årsaka

Ein innestengd teneste ser eit anna tre enn skalet du skriv i. Chroot-fengsel, containerbilete og herda unit-filer viser rutinemessig ein /dev med færre nodar enn verten sin. Viss implementeringa som feilar opnar /dev/urandom via stinamnet, er den skilnaden nok til å bryta oppstarten medan verten sjølv ser heilt frisk ut. Ei eining som finst utanfor fengselet beviser ingenting om kva den innestengde prosessen har lov til å opna.

Ikkje alle tilfeldige grensesnitt treng ein sti, likevel. Systemkallet getrandom i Linux godtek korkje filnamn eller fildeskriptor, og manualsida merkjer seg at denne eigenskapen nettopp er nyttig der ein chroot gøymer einingstiar.

Så forklaringa om den manglande noden er ein hypotese om éin grein av koden, ikkje ei regel om tilfeldige tal generelt. Ho held når prova nemner ein sti, og ho er gjetting når prova nemner noko anna.

Les feilkøen, så prosessvisinga

Den raskaste måten å avgjera spørsmålet på er å lesa kva biblioteket alt har registrert, og deretter sjå direkte på visinga inne i fengselet. Byrja med OpenSSL-bygget tenesta faktisk lasta, fordi leverandørstakkar er ulike mellom hovudversjonar og mellom distribusjonar. Spør deretter systemd kva prosess som køyrer og kva avgrensingar som gjeld for han. Først når begge fakta ligg på bordet, er det verdt å lista nodane den prosessen kan sjå.

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øyr desse lesingane mot same prosess, ikkje mot skalet som tilfeldigvis er ope. Å samanlikna /dev til verten med visinga til ein urelatert prosess er korleis den gale avhengnaden vert reparert to gonger.

Legg til avhengnaden først når du kan namngje han

Når prova faktisk nemner ein sti, er reparasjonen liten: gjer nettopp den stien tilgjengeleg inne i fengselet og lat alt anna vera. Ei bind-montering av den eine noden er vanlegvis nok, og mknod med standard major- og minortala til noden gjev same resultat på installasjonar der montering ikkje er eit alternativ. Å utvida sandkassen, gje tilgang til kvar teikneining eller slå av PrivateDevices byter ei målretta retting mot ein permanent tryggleiksregresjon.

Ein entropi-demon erstattar ikkje den reparasjonen. Pakkar som haveged endrar korleis kjernebassenget vert fora; dei kan ikkje laga eit stinamn som ein innestengd prosess har lov til å opna. Å installera ein kan få ein helsegrafen til å sjå betre ut medan open-kallet framleis feilar. Hald dei to problema frå kvarandre, elles vert neste feil igjen tilskriven feil lag.

Kontroller generatoren og tunnelen kvar for seg

Ein omstart er den einaste testen som brukar same konfigurasjon, same unit-fil og same innestenging som frambrakte feilen. Køyr han, og les deretter dei nyaste journaloppføringane i staden for eit utval frå ein tidlegare oppstart.

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

Sjå etter to atskilde ting i den utskrifta: meldinga om tilfeldigheitskjelda som forsvinn, og tunnelen som når sin vanlege oppstartsmilepæl. Ein generator som verkar igjen fjernar éin lokal feil og seier ingenting om serveridentitet, påloggingsdetaljar eller ruting. Test det med same klientkonfigurasjon som feila før, slik at resultatet blir samanliknbart og ikkje berre betre.