OpenVPN дотор RAND_bytes амжилтгүй болсон: сангийн алдаа эсвэл дутуу цэг

RAND_bytes() failed нь нэг локал примитив тухай мэдэгдэл бөгөөд бүртгэл, урьдчилан хуваалцсан түлхүүр эсвэл алсын портын тухай биш. Хоёр огт өөр гэмтэл ижил мөрийг үүсгэж, өөр ул мөр үлдээдэг. Нэг нь байт гаргахаас татгалздаг криптограф backend; нөгөө нь кодыг нь зориулж барьсан энтропийн эх үүсвэрт хүрч чадахгүй процесс юм. Тэдгээрийг ялгахад алдааны дарааллыг нэг удаа унших, хоригдсон процессын файлын системийн харагдац руу нэг харах шаардлагатай бөгөөд энэ шалгалт /dev доор ямар нэгэн зүйл үүсгэхээс өмнө хийгдэх ёстой.

Буцаах утга юуг ялгадаг

Баримтжуулсан гэрээ хоёр биш, гурван үр дүнг ялгадаг: амжилтад 1, ачаалсан RAND арга хүсэлтийг дэмжихгүй үед -1, бусад гэмтэлд 0 байх ба тайлбар нь алдааны дараалалд үлддэг. RAND_bytes-ийн лавлагаа анхааралдаа авахад хэцүү нэг цэг нэмдэг: өгөгдмөл үүсгэгч дэмжигдсэн платформууд дээр үйлдлийн системээс үр авдаг бөгөөд тэр үр суулгац бүтэлгүйтвэл урьдчилан таамаглахуйц байт буцаахын оронд алдааны төлөвт үлддэг.

Эдгээр тоонуудын зөвхөн нэг нь орчныг тодорхойлдог. -1 нь бүтээц, нийлүүлэгч эсвэл боломжийн асуудал, учир нь код идэвхтэй хэрэгжүүлэлтийн санал болгодоггүй зүйлийг шаардсан. Суулгацын гомдолтой 0 нь орчны асуудал, учир нь үүсгэгч энтропи огт авч чадаагүй. Тоо дангаараа аль нь болохыг хэзээ ч хэлдэггүй, функцийн нэр ч хэлдэггүй.

Нуугдсан төхөөрөмжийн цэг жинхэнэ шалтгаан болох үед

Хязгаарлагдсан үйлчилгээ таны бичиж буй shell-ээс өөр модыг хардаг. Chroot-ын шоронгууд, контейнерын дүрсүүд болон хатуужсан unit файлууд хосттой харьцуулахад цөөн цэг агуулсан /dev-г тогтмол үзүүлдэг. Хэрэв бүтэлгүйтэж буй хэрэгжүүлэлт /dev/urandom-ийг замын нэрээр нээвэл хост өөрөө төгс эрүүл харагдаж байхад тэр ялгаа эхлэлийг эвдэхэд хангалттай. Шоронгийн гадна оршин байгаа төхөөрөмж нь хоригдсон процесс юуг нээх эрхтэй гэдгийг юу ч нотолдоггүй.

Гэхдээ санамсаргүй интерфейс бүр зам шаарддаггүй. Linux-ийн getrandom системийн дуудлага файлын нэр ч, файлын дескриптор ч хүлээж авдаггүй бөгөөд түүний гарын авлагын хуудас энэ шинж чанар нь chroot төхөөрөмжийн замыг нуудаг газарт яг тохиромжтой гэдгийг тэмдэглэдэг.

Тиймээс дутуу цэгийн тайлбар нь кодын нэг салбарын тухай таамаглал бөгөөд санамсаргүй тооны тухай ерөнхий дүрэм биш. Нотолгоо зам нэрлэх үед энэ хүчинтэй бөгөөд нотолгоо өөр зүйл нэрлэх үед таамаг хэвээр байна.

Эхлээд алдааны дарааллыг, дараа нь процессын харагдацыг уншина уу

Асуултыг шийдэх хамгийн хурдан арга бол сан аль хэдийн бүртгэсэн зүйлийг уншиж, дараа нь шорон доторх харагдац руу шууд харах юм. Үйлчилгээ үнэхээр ачаалсан OpenSSL бүтээцээс эхэл, учир нь нийлүүлэгчийн стекүүд үндсэн хувилбар болон түгээлтүүдийн хооронд ялгаатай. Дараа нь systemd-ээс аль процесс ажиллаж байгаа, түүнд ямар хязгаарлалт үйлчлэхийг асуу. Хоёр баримт ширээн дээр ирсний дараа л тэр процессын харж чадах цэгүүдийг жагсаах нь үнэ цэнэтэй.

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

Эдгээр уншилтыг ижил процесс дээр хий, санамсаргүй нээлттэй байгаа shell дээр биш. Хостын /dev-г хамааралгүй процессын харагдацтай харьцуулах нь буруу хамаарлыг хоёр удаа засах арга юм.

Хамаарлыг нэрлэж чадсаны дараа л нэмнэ үү

Нотолгоо замыг үнэхээр нэрлэх үед засвар бага: тэр ганц замыг шорон дотор боломжтой болгож, бусад бүхнийг тайван орхи. Ганц цэгийн bind mount ихэвчлэн хангалттай бөгөөд mknod цэгийн стандарт major болон minor дугааруудтайгаар mount сонголтгүй суулгацууд дээр ижил үр дүн өгдөг. Sandbox-ыг өргөтгөх, символ бүрийн төхөөрөмжид хандалт өгөх эсвэл PrivateDevices-г унтраах нь зорилтот засварыг байнгын аюулгүй байдлын регрессээр солино.

Энтропийн демон тэр засварыг орлохгүй. haveged зэрэг багцууд цөмийн сан хэрхэн тэжээгдэхийг өөрчилдөг; тэд хоригдсон процесс нээх эрхтэй зам үүсгэж чадахгүй. Нэгийг суулгах нь нээх дуудлага хараахан бүтэлгүйтэж байхад эрүүл мэндийн графикийг сайхан харагдуулж болно. Хоёр асуудлыг тусдаа бариарай, эс бөгөөс дараагийн гэмтэл дахин буруу давхаргад хамааруулагдана.

Үүсгэгч болон туннелийг тусад нь шалгана уу

Дахин эхлүүлэх нь бүтэлгүйтэл үүсгэсэн ижил тохиргоо, ижил unit файл, ижил тусгаарлалтыг дахин ашигладаг цорын ганц туршилт юм. Үүнийг ажиллуул, дараа нь өмнөх эхлэлээс авсан дээж биш, журналын хамгийн сүүлийн бичлэгүүдийг унш.

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

Тэр гаралтаас хоёр тусдаа зүйлийг хай: санамсаргүй эх үүсвэрийн тухай мэдэгдэл алга болох, туннель өөрийн ердийн эхлэлийн мөчид хүрэх. Дахин ажиллаж буй үүсгэгч нэг локал бүтэлгүйтлийг арилгаж, серверийн таних мэдээлэл, нэвтрэх мэдээлэл эсвэл чиглүүлэлтийн тухай юу ч хэлдэггүй. Үүнийг өмнө нь бүтэлгүйтсэн ижил клиентийн тохиргоотой туршиж үз, ингэснээр үр дүн зөвхөн дээр биш, харьцуулах боломжтой байх болно.