OpenVPN-də RAND_bytes uğursuz oldu: kitabxana xətası və ya çatışmayan qovşaq

RAND_bytes() failed bir yerli primitiv haqqında ifadədir, hesab, əvvəlcədən paylaşılmış açar və ya uzaq port haqqında deyil. İki çox fərqli nasazlıq eyni sətri yaradır və fərqli izlər buraxır. Biri bayt verməkdən imtina edən kriptoqrafik arxa plandır; digəri kodunun istifadə etmək üçün qurulduğu entropiya mənbəyinə çata bilməyən prosesdir. Onları ayırmaq bir xəta növbəsi oxunuşu və həbsə salınmış prosesin fayl sistemi görünüşünə bir baxış tələb edir və bu yoxlama /dev altında hər hansı şey yaradılmadan əvvəl edilməlidir.

Qaytarılan dəyər nəyi fərqləndirir

Sənədləşdirilmiş müqavilə iki deyil, üç nəticəni ayırır: uğur üçün 1, yüklənmiş RAND metodu sorğunu dəstəkləmədikdə -1 və digər nasazlıqlar üçün 0, izahat isə xəta növbəsində qalır. RAND_bytes istinadı asanlıqla gözdən qaçan bir nöqtə əlavə edir: standart generator dəstəklənən platformalarda əməliyyat sistemindən toxum alır və bu toxumlama uğursuz olduqda proqnozlaşdırıla bilən baytlar qaytarmaq əvəzinə xəta vəziyyətində qalır.

Bu rəqəmlərdən yalnız biri mühiti təsvir edir. -1 qurma, təchizatçı və ya funksiya məsələsidir, çünki kod aktiv tətbiqin təklif etmədiyi bir şey istəmişdir. Toxumlama şikayəti ilə gələn 0 isə mühit məsələsidir, çünki generator ümumiyyətlə entropiya əldə edə bilməmişdir. Rəqəm tək başına heç vaxt hansının olduğunu demir, funksiyanın adı da demir.

Gizli cihaz qovşağı əsl səbəb olduqda

Məhdudlaşdırılmış xidmət yazdığınız qabıqdan fərqli bir ağac görür. Chroot həbsxanaları, konteyner obrazları və bərkidilmiş unit faylları adətən hostdakından daha az qovşaq saxlayan /dev təqdim edir. Uğursuz tətbiq /dev/urandom faylını yol adı ilə açırsa, bu fərq host özü tamamilə sağlam görünərkən işə salmanı pozmağa kifayət edir. Həbsxananın xaricində mövcud olan cihaz, həbs edilmiş prosesin nəyi aça biləcəyi barədə heç nə sübut etmir.

Lakin hər təsadüfi interfeysə yol lazım deyil. Linux-un getrandom sistem çağırışı nə fayl adı, nə də fayl deskriptoru qəbul edir və onun təlimat səhifəsi bu xüsusiyyətin məhz chroot cihaz yollarını gizlədiyi yerdə faydalı olduğunu qeyd edir.

Beləliklə, çatışmayan qovşaq izahı kodun bir qoluna dair fərziyyədir, təsadüfi ədədlər haqqında ümumi qayda deyil. Sübutlar bir yol adlandırdıqda keçərlidir və sübutlar başqa bir şey adlandırdıqda təxmindir.

Əvvəlcə xəta növbəsini, sonra proses görünüşünü oxuyun

Sualı həll etməyin ən sürətli yolu kitabxananın artıq qeyd etdiklərini oxumaq və sonra həbsxananın içindəki görünüşə birbaşa baxmaqdır. Xidmətin həqiqətən yüklədiyi OpenSSL quruluşu ilə başlayın, çünki təchizatçı yığınları əsas versiyalar və distribusiyalar arasında fərqlənir. Sonra systemd-dən hansı prosesin işlədiyini və hansı məhdudiyyətlərin tətbiq olunduğunu soruşun. Yalnız hər iki fakt masada olanda həmin prosesin görə bildiyi qovşaqları sadalamağa dəyər.

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

Bu oxunuşları eyni proses üzərində aparın, təsadüfən açıq olan qabıq üzərində deyil. Hostun /dev dəyərini əlaqəsiz bir prosesin görünüşü ilə müqayisə etmək səhv asılılığın iki dəfə təmir olunduğu yoldur.

Asılılığı yalnız adlandıra bildikdən sonra əlavə edin

Sübutlar həqiqətən bir yol adlandırdıqda təmir kiçikdir: o tək yolu həbsxananın içində əlçatan edin və qalan hər şeyə toxunmayın. Tək qovşağın bind mount-u adətən kifayət edir və mknod qovşağın standart major və minor nömrələri ilə mount-un seçim olmadığı quraşdırmalarda eyni nəticəni verir. Sandbox-ı genişləndirmək, hər simvol cihazına giriş vermək və ya PrivateDevices seçimini söndürmək məqsədli düzəlişi daimi təhlükəsizlik reqressiyası ilə dəyişir.

Entropiya demonu bu təmirin əvəzi deyil. haveged kimi paketlər kernel hovuzunun necə qidalandığını dəyişir; həbs edilmiş prosesin açmasına icazə verilən bir yol yarada bilməzlər. Birini quraşdırmaq açma çağırışı hələ də uğursuz olarkən sağlamlıq qrafikini daha yaxşı göstərə bilər. İki problemi ayrı saxlayın, əks halda növbəti nasazlıq yenə yanlış təbəqəyə aid ediləcək.

Generatoru və tuneli ayrıca yoxlayın

Yenidən başlatma nasazlığı yaradan eyni konfiqurasiyanı, eyni unit faylını və eyni təcridi təkrar istifadə edən yeganə testdir. Onu işə salın və sonra əvvəlki işə salmadan götürülmüş nümunə yerinə jurnalın ən yeni qeydlərini oxuyun.

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

Həmin çıxışda iki ayrı şey axtarın: təsadüfi mənbə ilə bağlı mesajın yox olması və tunelin adi işə salma mərhələsinə çatması. Yenidən işləyən generator bir yerli nasazlığı aradan qaldırır və server kimliyi, etimadnamələr və ya marşrutlaşdırma barədə heç nə demir. Bunu əvvəl uğursuz olan eyni müştəri konfiqurasiyası ilə sınaqdan keçirin ki, nəticə yalnız daha yaxşı deyil, müqayisə edilə bilən olsun.