Nabigo ang RAND_bytes sa OpenVPN: error sa library o kulang na node

RAND_bytes() failed ay isang pahayag tungkol sa isang lokal na primitive, hindi tungkol sa account, sa paunang ibinahaging susi o sa malayong port. Dalawang magkaibang kabiguan ang gumagawa ng parehong linya at nag-iiwan ng magkaibang ebidensya. Ang isa ay cryptographic backend na tumatangging maglabas ng bytes; ang isa pa ay prosesong hindi umaabot sa pinagmumulan ng entropy kung saan itinayo ang code nito. Ang paghihiwalay sa kanila ay nangangailangan ng isang pagbasa sa pila ng error at isang sulyap sa tanawin ng file system ng nakakulong na proseso, at ang pagsusuring iyon ay dapat mangyari bago gumawa ng anuman sa ilalim ng /dev.

Ano ang ipinagkaiba ng return value

Ang dokumentadong kontrata ay naghihiwalay ng tatlong kinalabasan, hindi dalawa: 1 para sa tagumpay, -1 kapag hindi sinusuportahan ng naka-load na paraang RAND ang kahilingan, at 0 para sa iba pang kabiguan, na iniiwan ang paliwanag sa pila ng error. Ang sanggunian ng RAND_bytes ay nagdadagdag ng puntong madaling lampasan: ang default na generator ay kumukuha ng binhi mula sa operating system sa mga sinusuportahang platform, at kapag nabigo ang pagbibinhi, nananatili ito sa error state sa halip na magbalik ng mahuhulaang bytes.

Isa lang sa mga bilang na iyon ang naglalarawan sa kapaligiran. Ang -1 ay usapin ng build, provider o feature, dahil humingi ang code ng bagay na hindi inaalok ng aktibong implementasyon. Ang 0 na may reklamo sa pagbibinhi ay usapin ng kapaligiran, dahil hindi talaga nakakuha ng entropy ang generator. Ang bilang mismo ay hindi kailanman nagsasabi kung alin, at ang pangalan ng function ay hindi rin.

Kapag nakatagong device node ang tunay na dahilan

Ang isang limitadong serbisyo ay nakakakita ng ibang puno kaysa sa shell na kinakalkal mo. Ang mga chroot jail, container image at hardened na unit file ay regular na nagpapakita ng /dev na may mas kaunting node kaysa sa host. Kung binubuksan ng nabigo na implementasyon ang /dev/urandom ayon sa pathname, sapat na ang pagkakaibang iyon para masira ang pagsisimula habang ang host mismo ay mukhang ganap na malusog. Ang device na umiiral sa labas ng jail ay walang pinatutunayan tungkol sa kung ano ang pinapayagang buksan ng nakakulong na proseso.

Hindi lahat ng random interface ay nangangailangan ng path, gayunman. Ang system call na getrandom sa Linux ay hindi tumatanggap ng filename o file descriptor, at itinuturo ng manual page nito na ang katangiang iyon ay kapaki-pakinabang mismo sa lugar kung saan itinatago ng chroot ang mga path ng device.

Kaya ang paliwanag ng kulang na node ay isang hipotesis tungkol sa isang sangay ng code, hindi isang tuntunin tungkol sa mga random na bilang sa pangkalahatan. Itinatag ito kapag binabanggit ng ebidensya ang isang path, at haka-haka ito kapag binabanggit ng ebidensya ang ibang bagay.

Basahin ang pila ng error, pagkatapos ang tanawin ng proseso

Ang pinakamabilis na paraan upang maayos ang tanong ay basahin ang naitala na ng library, pagkatapos ay direktang tingnan ang tanawin sa loob ng jail. Magsimula sa build ng OpenSSL na talagang na-load ng serbisyo, dahil nagkakaiba ang provider stack sa pagitan ng mga major version at ng mga distribution. Pagkatapos ay itanong sa systemd kung aling proseso ang tumatakbo at anong mga paghihigpit ang applicable dito. Pagkatapos lamang na ang dalawang katotohanan ay nasa mesa ay sulit na ilista ang mga node na nakikita ng prosesong iyon.

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

Patakbuhin ang mga pagbasang iyon laban sa parehong proseso, hindi laban sa shell na nagkataong bukas. Ang paghahambing ng /dev ng host sa tanawin ng walang kaugnayang proseso ay ang paraan kung paano nadodoble ang pag-aayos ng maling dependency.

Idagdag ang dependency pagkatapos mo lamang itong mapaangalan

Kapag binabanggit ng ebidensya ang isang path, maliit lang ang pag-aayos: gawing available ang nag-iisang path na iyon sa loob ng jail at hayaang manatili ang lahat ng iba. Karaniwang sapat ang bind mount ng nag-iisang node, at ang mknod na may standard na major at minor number ng node ay nagbibigay ng parehong resulta sa mga instalasyong hindi opsyon ang pag-mount. Ang pagpapalawak ng sandbox, pagbibigay ng access sa bawat character device o pag-off ng PrivateDevices ay nagpapalit ng naka-target na pagwawasto para sa permanenteng security regression.

Ang entropy daemon ay hindi kapalit ng pag-aayos na iyon. Binabago ng mga package tulad ng haveged kung paano pinapakain ang kernel pool; hindi sila makakagawa ng pathname na pinapayagang buksan ng nakakulong na proseso. Ang pag-install ng isa ay maaaring gawing mas maganda ang health graph habang nabigo pa rin ang open call. Panatilihing hiwalay ang dalawang problema, kung hindi ay maitatalaga na naman ang susunod na kabiguan sa maling layer.

I-verify nang hiwalay ang generator at ang tunnel

Ang restart ay ang tanging pagsubok na muling gumagamit ng parehong configuration, parehong unit file at parehong confinement na nagdulot ng kabiguan. Patakbuhin ito, pagkatapos ay basahin ang pinakabagong journal entry sa halip na sample mula sa naunang boot.

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

Maghanap ng dalawang magkaibang bagay sa output na iyon: ang mensahe tungkol sa random source na nawawala, at ang tunnel na umaabot sa karaniwang start milestone nito. Ang generator na gumagana muli ay nag-aalis ng isang lokal na kabiguan at walang sinasabi tungkol sa identity ng server, credentials o routing. Subukan iyon gamit ang parehong client configuration na nabigo dati, upang ang resulta ay maihahambing at hindi lamang mas mahusay.