RAND_bytes hiba az OpenVPN-ben: könyvtárhiba vagy hiányzó csomópont

RAND_bytes() failed egyetlen helyi primitívumról szóló állítás, nem a fiókról, az előre megosztott kulcsról vagy a távoli portról. Két nagyon különböző hiba ugyanazt a sort hozza létre, és különböző nyomokat hagy. Az egyik egy kriptográfiai háttér, amely megtagadja a bájtok kibocsátását; a másik egy folyamat, amely nem éri el azt az entrópiaforrást, amelyre a kódját építették. Az elkülönítésükhöz egy hibasor-olvasás és egy pillantás kell a bezárt folyamat saját fájlrendszer-nézetére, és ennek az ellenőrzésnek minden /dev alatt létrehozott dolog előtt kell megtörténnie.

Mit különböztet meg a visszatérési érték

A dokumentált szerződés három eredményt különböztet meg, nem kettőt: 1 a sikerhez, -1 amikor a betöltött RAND-metódus nem támogatja a kérést, és 0 az egyéb hibákhoz, a magyarázatot a hibasorra hagyva. A RAND_bytes-referencia hozzátesz egy könnyen átnézhető pontot: az alapértelmezett generátor a támogatott platformokon az operációs rendszerből vesz magot, és amikor ez a magozás meghiúsul, hibás állapotban marad ahelyett, hogy kiszámítható bájtokat adna vissza.

Csak egyetlen szám írja le a környezetet. A -1 építési, szolgáltatói vagy funkciókérdés, mert a kód olyat kért, amit az aktív megvalósítás nem kínál. A 0 magozási panasszal környezeti kérdés, mert a generátor egyáltalán nem tudott entrópiát szerezni. A szám önmagában soha nem mondja meg, melyik, és a függvény neve sem.

Amikor egy rejtett eszközcsomópont a valódi ok

Egy korlátozott szolgáltatás más fát lát, mint a shell, amelybe gépelsz. A chroot-börtönök, a konténerképek és a megerősített unit-fájlok rendszeresen kevesebb csomópontot tartalmazó /dev-t mutatnak, mint a gazdagépé. Ha a hibázó megvalósítás /dev/urandom-t az útvonal szerint nyitja meg, ez a különbség elég az indítás elrontásához, miközben maga a gazdagép teljesen egészségesnek látszik. A börtönön kívül létező eszköz semmit sem bizonyít arról, mit nyithat meg a bezárt folyamat.

Nem minden véletlen interfésznek kell azonban útvonal. A Linux getrandom rendszerhívása sem fájlnevet, sem fájlleírót nem fogad el, és a kézikönyv lapja megjegyzi, hogy ez a tulajdonság éppen ott hasznos, ahol egy chroot elrejti az eszközútvonalakat.

Tehát a hiányzó csomópont magyarázata egy kódelágazásra vonatkozó hipotézis, nem általános szabály a véletlen számokról. Akkor áll meg, amikor a bizonyíték útvonalat nevez meg, és találgatás, amikor a bizonyíték valami mást nevez meg.

Először a hibasort, aztán a folyamat nézetét olvasd

A kérdés eldöntésének leggyorsabb módja elolvasni, mit rögzített már a könyvtár, majd közvetlenül megnézni a börtönön belüli nézetet. Kezdd azzal a OpenSSL-builddel, amelyet a szolgáltatás valóban betöltött, mert a szolgáltatói vermek főverziók és disztribúciók között eltérnek. Kérdezd meg utána a systemd-t, melyik folyamat fut, és milyen korlátozások vonatkoznak rá. Csak akkor érdemes felsorolni a csomópontokat, amelyeket az a folyamat lát, ha mindkét tény az asztalon van.

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

Ezeket az olvasásokat ugyanazon a folyamaton végezd, ne azon a shellen, amely éppen nyitva van. A gazdagép /dev-jét egy független folyamat nézetével összehasonlítani az az út, amelyen a rossz függőség kétszer javításra kerül.

Csak akkor add hozzá a függőséget, ha meg tudod nevezni

Amikor a bizonyíték tényleg útvonalat nevez meg, a javítás kicsi: tedd elérhetővé azt az egy útvonalat a börtönön belül, és hagyj minden mást békén. Egyetlen csomópont bind mountja általában elég, és mknod a csomópont szokásos major és minor számaival ugyanezt az eredményt adja olyan telepítéseken, ahol a mountolás nem lehetőség. A homokozó szélesítése, minden karakteres eszközhöz való hozzáférés megadása vagy PrivateDevices kikapcsolása célzott javítást cserél állandó biztonsági regresszióra.

Az entrópia-démon nem helyettesíti ezt a javítást. Az olyan csomagok, mint a haveged, megváltoztatják, hogyan táplálják a kernel poolt; nem tudnak olyan útvonalat létrehozni, amelyet egy bezárt folyamat megnyithat. Egy telepítése javíthatja az egészségügyi grafikont, miközben az open hívás továbbra is meghiúsul. Tartsd külön a két problémát, különben a következő hiba megint a rossz rétegnek lesz tulajdonítva.

A generátort és az alagutat külön ellenőrizd

Az újraindítás az egyetlen teszt, amely ugyanazt a konfigurációt, ugyanazt az unit-fájlt és ugyanazt az elkülönítést használja újra, amelyek a hibát okozták. Futtasd, majd olvasd a legújabb naplóbejegyzéseket, ne egy korábbi indítás mintáját.

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

Két külön dolgot keress abban a kimenetben: a véletlen forrásról szóló üzenet eltűnését és az alagút szokásos indítási mérföldkövének elérését. Egy újra működő generátor eltávolít egy helyi hibát, és semmit sem mond a szerver identitásáról, a hitelesítő adatokról vagy az útválasztásról. Teszteld ugyanazzal a klienskonfigurációval, amely korábban meghiúsult, hogy az eredmény összehasonlítható legyen, és ne csak jobb.