RAND_bytes u OpenVPN-u nije uspio: pogreška biblioteke ili čvor koji nedostaje

RAND_bytes() failed je tvrdnja o jednom lokalnom primitivu, ne o računu, unaprijed podijeljenom ključu ili udaljenom portu. Dvije vrlo različite greške stvaraju isti redak i ostavljaju različite tragove. Jedna je kriptografski backend koji odbija isporučiti bajtove; druga je proces koji ne doseže izvor entropije za koji je njegov kôd izgrađen. Razdvojiti ih zahtijeva jedno čitanje reda pogrešaka i jedan pogled na datotečni sustav zatvorenog procesa, a ta provjera pripada prije svega što nastane pod /dev.

Što povratna vrijednost razlikuje

Dokumentirani ugovor razlikuje tri ishoda, ne dva: 1 za uspjeh, -1 kada učitana metoda RAND ne podržava zahtjev, i 0 za ostale pogreške, pri čemu objašnjenje ostaje u redu pogrešaka. Referenca RAND_bytes dodaje točku koju je lako previdjeti: zadani generator sije sjeme iz operacijskog sustava na podržanim platformama, a kada to sijanje ne uspije, ostaje u stanju pogreške umjesto da vrati predvidljive bajtove.

Samo jedan od tih brojeva opisuje okruženje. -1 je pitanje gradnje, pružatelja ili značajke, jer je kôd tražio nešto što aktivna implementacija ne nudi. 0 s pritužbom na sijanje je okolišno pitanje, jer generator uopće nije mogao dobiti entropiju. Broj sam po sebi nikada ne kaže koji, a ni ime funkcije.

Kada je skriveni čvor uređaja pravi uzrok

Ograničena usluga vidi drugo stablo od ljuske u koju tipkate. Chroot zatvori, slike kontejnera i očvrsnute unit datoteke redovito prikazuju /dev s manje čvorova od onog na hostu. Ako implementacija koja ne uspijeva otvara /dev/urandom po putanji, ta je razlika dovoljna da slomi pokretanje dok sam host izgleda posve zdravo. Uređaj koji postoji izvan zatvora ne dokazuje ništa o tome što zatvoreni proces smije otvoriti.

Nema svako nasumično sučelje potrebu za putanjom, ipak. Sistemski poziv getrandom u Linuxu ne prihvaća ni ime datoteke ni datotečni deskriptor, a njegova stranica priručnika napominje da je to svojstvo korisno upravo ondje gdje chroot skriva putanje uređaja.

Dakle, objašnjenje čvora koji nedostaje hipoteza je o jednoj grani kôda, a ne pravilo o nasumičnim brojevima općenito. Drži kada dokazi imenuju putanju, a nagađanje je kada dokazi imenuju nešto drugo.

Prvo pročitajte red pogrešaka, zatim pogled procesa

Najbrži način da razriješite pitanje jest pročitati što je biblioteka već zabilježila, a zatim izravno pogledati pogled unutar zatvora. Počnite s gradnjom OpenSSL-a koju je usluga stvarno učitala, jer se stogovi pružatelja razlikuju između glavnih verzija i između distribucija. Zatim pitajte systemd koji proces radi i koja se ograničenja na njega primjenjuju. Tek kada su obje činjenice na stolu, vrijedi popisati čvorove koje taj proces može vidjeti.

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

Izvodite ta čitanja na istom procesu, ne na ljusci koja se slučajno nalazi otvorena. Uspoređivanje /dev hosta s pogledom nepovezanog procesa način je na koji se pogrešna ovisnost popravi dvaput.

Dodajte ovisnost tek kada je možete imenovati

Kada dokazi doista imenuju putanju, popravak je malen: učinite tu jednu putanju dostupnom unutar zatvora i ostavite sve ostalo na miru. Bind mount pojedinačnog čvora obično je dovoljan, a mknod sa standardnim major i minor brojevima čvora daje isti rezultat u instalacijama gdje mount nije opcija. Proširenje sandboxa, davanje pristupa svakom znakovnom uređaju ili isključivanje PrivateDevices mijenja ciljani ispravak za trajnu sigurnosnu regresiju.

Entropijski daemon nije zamjena za taj popravak. Paketi poput haveged mijenjaju kako se hrani jezgreni bazen; ne mogu stvoriti putanju koju zatvoreni proces smije otvoriti. Instalacija jednoga može poboljšati graf zdravlja dok poziv open još uvijek ne uspijeva. Držite ta dva problema odvojenima, inače će sljedeći neuspjeh opet biti pripisan pogrešnom sloju.

Provjerite generator i tunel odvojeno

Ponovno pokretanje jedini je test koji ponovno koristi istu konfiguraciju, istu unit datoteku i istu izolaciju koje su prouzročile neuspjeh. Pokrenite ga, a zatim čitajte najnovije zapise u dnevniku umjesto uzorka iz ranijeg pokretanja.

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

U tom izlazu tražite dvije odvojene stvari: poruku o nasumičnom izvoru koja nestaje i tunel koji doseže svoj uobičajeni pokretački mejnik. Generator koji ponovno radi uklanja jedan lokalni neuspjeh i ne govori ništa o identitetu poslužitelja, vjerodajnicama ili usmjeravanju. Testirajte to istom klijentskom konfiguracijom koja prije nije uspjela, kako bi rezultat bio usporediv, a ne samo bolji.