OpenVPN ішінде RAND_bytes сәтсіз аяқталды: кітапхана қатесі немесе жоқ түйін

RAND_bytes() failed — бір жергілікті примитив туралы мәлімдеме, ал есептік жазба, алдын ала бөлінген кілт немесе қашықтағы порт туралы емес. Екі мүлдем басқа ақау бірдей жолды шығарады және әртүрлі із қалдырады. Біреуі байт шығарудан бас тартатын криптографиялық бэкенд; екіншісі өз коды салынған энтропия көзіне жете алмайтын процесс. Оларды ажырату үшін қателер кезегін бір рет оқу және тұтқындағы процестің файлдық жүйе көрінісіне бір қарау қажет, және бұл тексеру /dev астында бірдеңе жасалмас бұрын орындалуы керек.

Қайтарылатын мән нені ажыратады

Құжатталған шарт екі емес, үш нәтижені ажыратады: сәттілік үшін 1, жүктелген RAND әдісі сұранысты қолдамаса -1 және басқа ақаулар үшін 0, түсіндірме қателер кезегінде қалады. RAND_bytes анықтамасы назардан тыс қалуы оңай тармақты қосады: әдепкі генератор қолдау көрсетілетін платформаларда операциялық жүйеден тұқым алады, және бұл тұқымдау сәтсіз болса, ол болжамды байттарды қайтарудың орнына қате күйінде қалады.

Осы сандардың тек біреуі ортаны сипаттайды. -1 құрастыру, жеткізуші немесе функция мәселесі, себебі код белсенді іске асыру ұсынбайтын нәрсені сұрады. Тұқымдау шағымымен келген 0 — орта мәселесі, себебі генератор энтропияны мүлдем ала алмады. Санның өзі қайсысы екенін ешқашан айтпайды, функция атауы да айтпайды.

Жасырын құрылғы түйіні шын себеп болғанда

Шектелген қызмет сіз теріп отырған қабықтан басқа ағашты көреді. 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

Бұл оқуларды сол процестің өзінде орындаңыз, кездейсоқ ашық қалған қабықта емес. Хосттың /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'

Сол шығыстан екі бөлек нәрсені іздеңіз: кездейсоқ көз туралы хабардың жоғалуы және туннельдің әдеттегі іске қосылу кезеңіне жетуі. Қайта жұмыс істейтін генератор бір жергілікті ақауды жояды және сервер идентификациясы, тіркелгі деректері немесе маршруттау туралы ештеңе айтпайды. Мұны бұрын сәтсіз болған сол клиент конфигурациясымен сынап көріңіз, нәтиже тек жақсырақ емес, салыстырмалы болсын.