RAND_bytes malsukcesis en OpenVPN: biblioteka eraro aŭ mankanta nodo

RAND_bytes() failed estas aserto pri unu loka primitivo, ne pri la konto, la antaŭe kunhavigita ŝlosilo aŭ la fora pordo. Du tre malsamaj paneoj produktas tiun saman linion kaj lasas malsamajn spurojn. Unu estas kriptografia malantaŭo, kiu rifuzas eligi bajtojn; la alia estas procezo, kiu ne atingas la entropifonton, por kiu ĝia kodo estis konstruita. Apartigi ilin postulas unu legadon de la erarvico kaj unu rigardon al la dosiersistema vido de la malliberigita procezo, kaj tiu kontrolo apartenas antaŭ ĉio, kio kreiĝas sub /dev.

Kion la revenvaloro distingas

La dokumentita kontrakto apartigas tri rezultojn, ne du: 1 por sukceso, -1 kiam la ŝargita RAND-metodo ne subtenas la peton, kaj 0 por aliaj paneoj, lasante la klarigon al la erarvico. La RAND_bytes-referenco aldonas punkton facile preteratenteblan: la implicita generatoro semas sin el la operaciumo sur subtenataj platformoj, kaj kiam tiu semado malsukcesas, ĝi restas en erara stato anstataŭ redoni antaŭvideblajn bajtojn.

Nur unu el tiuj nombroj priskribas la medion. -1 estas demando pri konstruo, provizanto aŭ trajto, ĉar la kodo petis ion, kion la aktiva efektivigo ne ofertas. 0 kun plendo pri semado estas media demando, ĉar la generatoro tute ne povis akiri entropion. La nombro sola neniam diras kiun, kaj la funkcia nomo ankaŭ ne.

Kiam kaŝita aparata nodo estas la vera kaŭzo

Limigita servo vidas alian arbon ol la ŝelo, en kiun vi tajpas. Chroot-malliberejoj, ujbildoj kaj harditaj unuodosieroj kutime prezentas /dev kun malpli da nodoj ol tiu de la gastiganto. Se la paneanta efektivigo malfermas /dev/urandom laŭ vojnomo, tiu diferenco sufiĉas por rompi la ŝarĝadon, dum la gastiganto mem aspektas perfekte sana. Aparato ekzistanta ekster la malliberejo pruvas nenion pri tio, kion la malliberigita procezo rajtas malfermi.

Ne ĉiu hazarda interfaco bezonas vojon, tamen. La sistema voko getrandom de Linukso akceptas nek dosiernomon nek dosierpriskribilon, kaj ĝia manlibra paĝo rimarkigas, ke tiu eco utilas ĝuste tie, kie chroot kaŝas aparatajn vojojn.

Do la klarigo pri la mankanta nodo estas hipotezo pri unu branĉo de la kodo, ne regulo pri hazardaj nombroj ĝenerale. Ĝi validas, kiam la pruvoj nomas vojon, kaj ĝi estas konjekto, kiam la pruvoj nomas ion alian.

Legu la erarvicon, poste la procezan vidon

La plej rapida maniero solvi la demandon estas legi, kion la biblioteko jam registris, kaj poste rigardi rekte la vidon ene de la malliberejo. Komencu per la OpenSSL-konstruo, kiun la servo efektive ŝargis, ĉar provizantaj stakoj malsamas inter ĉefaj versioj kaj inter distribuaĵoj. Poste demandu systemd, kiu procezo ruliĝas kaj kiuj limigoj validas por ĝi. Nur post kiam ambaŭ faktoj kuŝas sur la tablo, indas listigi la nodojn, kiujn tiu procezo povas vidi.

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

Rulu tiujn legadojn kontraŭ la sama procezo, ne kontraŭ la ŝelo, kiu hazarde estas malfermita. Kompari la /dev de la gastiganto kun la vido de nerilata procezo estas kiel la malĝusta dependaĵo ripariĝas dufoje.

Aldonu la dependaĵon nur post kiam vi povas nomi ĝin

Kiam la pruvoj ja nomas vojon, la riparo estas malgranda: faru tiun unu vojon disponebla ene de la malliberejo kaj lasu ĉion alian trankvile. Bind-mounto de la unuopa nodo kutime sufiĉas, kaj mknod kun la normaj major kaj minor numeroj de la nodo donas la saman rezulton en instalaĵoj, kie muntado ne estas opcio. Larĝigi la sablujon, doni aliron al ĉiu signa aparato aŭ malŝalti PrivateDevices interŝanĝas celitan riparon kontraŭ daŭra sekureca regreso.

Entropia demono ne anstataŭas tiun riparon. Pakaĵoj kiel haveged ŝanĝas, kiel la kerna naĝejo estas nutrita; ili ne povas krei vojnomon, kiun malliberigita procezo rajtas malfermi. Instali unu povas igi sanan grafeon aspekti pli bone, dum la malferma voko ankoraŭ malsukcesas. Tenu la du problemojn apartaj, alie la sekva paneo denove estos atribuata al la malĝusta tavolo.

Kontrolu la generatoron kaj la tunelon aparte

Restartigo estas la sola testo, kiu reuzas la saman agordon, la saman unuodosieron kaj la saman izoladon, kiuj kaŭzis la paneon. Rulu ĝin, kaj poste legu la plej novajn ĵurnalajn rikordojn anstataŭ specimenon el pli frua lanĉo.

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

Serĉu du apartajn aferojn en tiu eligo: la mesaĝon pri la hazarda fonto malaperanta, kaj la tunelon atingantan sian kutiman lanĉan mejloŝtonon. Generatoro, kiu denove funkcias, forigas unu lokan paneon kaj diras nenion pri servila identeco, legitimiloj aŭ enkursigado. Testu tion per la sama klienta agordo, kiu antaŭe malsukcesis, por ke la rezulto estu komparebla kaj ne nur pli bona.