RAND_bytes gagal di OpenVPN: galat pustaka atau node yang hilang

RAND_bytes() failed adalah pernyataan tentang satu primitif lokal, bukan tentang akun, kunci yang dibagi sebelumnya, atau port jarak jauh. Dua kegagalan yang sangat berbeda menghasilkan baris yang sama dan meninggalkan bukti yang berbeda. Yang satu adalah backend kriptografis yang menolak mengeluarkan byte; yang lain adalah proses yang tidak mencapai sumber entropi yang menjadi dasar kodenya dibangun. Memisahkan keduanya memerlukan satu pembacaan antrean galat dan satu lihat pada tampilan sistem berkas proses yang terkurung, dan pemeriksaan itu harus dilakukan sebelum apa pun dibuat di bawah /dev.

Apa yang dibedakan nilai kembali

Kontrak yang didokumentasikan membedakan tiga hasil, bukan dua: 1 untuk sukses, -1 ketika metode RAND yang dimuat tidak mendukung permintaan, dan 0 untuk kegagalan lain, dengan penjelasan dibiarkan di antrean galat. Referensi RAND_bytes menambahkan satu poin yang mudah terlewat: generator bawaan mengambil benih dari sistem operasi pada platform yang didukung, dan ketika pembenihan itu gagal, ia tetap dalam keadaan galat alih-alih mengembalikan byte yang dapat diprediksi.

Hanya satu dari angka-angka itu yang menggambarkan lingkungan. -1 adalah persoalan build, penyedia, atau fitur, karena kode meminta sesuatu yang tidak ditawarkan implementasi aktif. 0 dengan keluhan pembenihan adalah persoalan lingkungan, karena generator sama sekali tidak bisa memperoleh entropi. Angka itu sendiri tidak pernah mengatakan yang mana, dan nama fungsinya juga tidak.

Kapan node perangkat yang tersembunyi menjadi penyebab sebenarnya

Layanan yang dibatasi melihat pohon yang berbeda dari shell tempat Anda mengetik. Jail chroot, image kontainer, dan berkas unit yang dikeraskan rutin menyajikan /dev yang berisi lebih sedikit node daripada milik host. Jika implementasi yang gagal membuka /dev/urandom berdasarkan nama jalur, perbedaan itu cukup untuk merusak awal jalan sementara host sendiri tampak sangat sehat. Perangkat yang ada di luar jail tidak membuktikan apa pun tentang apa yang boleh dibuka proses yang terkurung.

Tidak setiap antarmuka acak membutuhkan jalur, namun. Panggilan sistem getrandom di Linux tidak menerima nama berkas maupun deskriptor berkas, dan halaman manualnya mencatat bahwa sifat ini berguna justru di tempat chroot menyembunyikan jalur perangkat.

Jadi penjelasan node yang hilang adalah hipotesis tentang satu cabang kode, bukan aturan tentang angka acak secara umum. Ia bertahan ketika bukti menyebutkan jalur, dan ia dugaan ketika bukti menyebutkan hal lain.

Baca antrean galat, lalu tampilan proses

Cara tercepat untuk menyelesaikan pertanyaan adalah membaca apa yang sudah dicatat pustaka, lalu melihat langsung tampilan di dalam jail. Mulailah dengan build OpenSSL yang benar-benar dimuat layanan, karena tumpukan penyedia berbeda antar versi utama dan antar distribusi. Lalu tanyakan kepada systemd proses mana yang berjalan dan pembatasan apa yang berlaku untuknya. Hanya setelah kedua fakta ada di meja, daftar node yang dapat dilihat proses itu layak disusun.

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

Jalankan pembacaan itu pada proses yang sama, bukan pada shell yang kebetulan terbuka. Membandingkan /dev host dengan tampilan proses yang tidak terkait adalah cara dependensi yang salah diperbaiki dua kali.

Tambahkan dependensi hanya setelah Anda bisa menamainya

Ketika bukti memang menyebutkan jalur, perbaikannya kecil: sediakan satu jalur itu di dalam jail dan biarkan yang lain. Bind mount satu node biasanya cukup, dan mknod dengan nomor major dan minor standar node menghasilkan hasil yang sama pada instalasi di mana mount bukan pilihan. Memperluas sandbox, memberi akses ke setiap perangkat karakter, atau mematikan PrivateDevices menukar perbaikan bertarget dengan regresi keamanan permanen.

Daemon entropi bukan pengganti perbaikan itu. Paket seperti haveged mengubah cara kumpulan kernel diberi makan; mereka tidak dapat membuat nama jalur yang boleh dibuka proses terkurung. Memasangnya dapat mempercantik grafik kesehatan sementara panggilan buka tetap gagal. Jaga kedua masalah tetap terpisah, atau kegagalan berikutnya akan lagi dikaitkan dengan lapisan yang salah.

Verifikasi generator dan terowongan secara terpisah

Restart adalah satu-satunya uji yang menggunakan kembali konfigurasi, berkas unit, dan kurungan yang sama yang menghasilkan kegagalan. Jalankan, lalu baca entri jurnal terbaru alih-alih sampel dari boot sebelumnya.

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

Cari dua hal terpisah dalam keluaran itu: pesan tentang sumber acak yang hilang, dan terowongan yang mencapai tonggak awal biasanya. Generator yang berfungsi lagi menghilangkan satu kegagalan lokal dan tidak mengatakan apa pun tentang identitas server, kredensial, atau perutean. Uji itu dengan konfigurasi klien yang sama yang gagal sebelumnya, agar hasilnya sebanding dan bukan sekadar lebih baik.