Linux: ta bort blockering av poolen /dev/random

Som bekant har /dev/random, en kryptografiskt säker pseudorandom number generator (CSPRNG), ett olyckligt problem – blockeringar. I denna artikel diskuteras hur man kan lösa detta problem.

Under de senaste månaderna har random number generation i kärnan blivit något omarbetad, men problem i det här delsystemet har hanterats under en längre tid. Tidsramar.De senaste ändringarna gjordes för att förhindra långvarig blockering av systemanropet getrandom() vid systemstart, men orsaken till detta var beteendet hos den blockerande random poolen. Den senaste patchen skulle ta bort denna pool, och det förväntades att den skulle gå vidare till den primära kärnan.

Andy Lutomirski publicerade den tredje versionen av patchen i slutet av december. Den gör »två huvudsakliga semantiska ändringar i Linux random API«.Patchen lägger till ett nytt flagg GRND_INSECURE till systemanropet getrandom() (även om Lutomirski refererar till det som getentropy(), vilket implementeras i glibc med getrandom() med fasta flaggor); detta flagg får anropet att alltid returnera det begärda antalet data, men utan garanti för att dessa data är slumpmässiga. Kärnan kommer bara att göra sitt bästa för att ge den bästa slumpmässiga data som den har för tillfället. »Förmodligen det bästa man kan göra är att kalla det 'INSECURE' ('osäkert') för att förhindra att denna API används för saker som kräver säkerhet.«

Patcharna tar också bort den blockerande poolen. För närvarande stödjer kärnan två pooler av slumpmässiga data, varav en motsvarar /dev/random och den andra /dev/urandom, som beskrivs i denna artikeln från 2015. Den blockerande poolen är en pool för /dev/random; läsning för denna enhet kommer att blockeras (detta antyder dess namn) tills tillräcklig entropi har samlats in från systemet för att tillfredsställa begäran. Ytterligare läsningar från denna fil blockeras också om det saknas tillräcklig entropi i poolen.

Borttagning av blockeringspool innebär att läsning från /dev/random beter sig som getrandom() med flaggor som är noll (och omvandlar flaggan GRND_RANDOM till noop). Efter initiering av den kryptografiska slumpgeneratorn (CRNG) kommer läsning från /dev/random och anrop av getrandom(…,0) inte att blockera och kommer att returnera det begärda antalet slumpmässiga data.

Lutomirski säger: «Jag anser att Linux blockeringspool har blivit föråldrad. Linux CRNG genererar utdata som är tillräckligt bra för att använda till och med för att generera nycklar. Blockeringspoolen är inte starkare på något materiellt sätt, och för att upprätthålla den krävs mycket infrastruktur av tveksamt värde».

Ändringar har gjorts med sikte på att befintliga program verkligen inte ska skadas, och faktiskt kommer problemen med lång väntan för saker som GnuPG-nyckelgenerering att minska.

«Dessa serier ska inte störa några befintliga program. /dev/urandom förblir oförändrat. /dev/random blockeras fortfarande omedelbart efter start, men blockeras mindre än tidigare. getentropy() med befintliga flaggor kommer att returnera ett resultat som kommer att vara lika lämpligt för praktiska ändamål som tidigare».

Lutomirski påpekade att frågan om huruvida kärnan ska tillhandahålla så kallade «äkta slumpmässiga tal» fortfarande är öppen, vilket delvis var kärnans syfte att göra. Han ser bara en anledning till detta: «efterlevnad av statliga standarder». Lutomirski föreslog att om kärnan ska tillhandahålla detta, så bör det göras genom ett helt annat gränssnitt eller flyttas till användarutrymmet, vilket ger användaren möjlighet att extrahera råa händelseprov som kan användas för att skapa en sådan blockeringspool.

Stephan Müller föreslog att hans uppsättning patchar För Linuxs slumpgenerator (LRNG) (för närvarande version 26) kan vara ett sätt att tillhandahålla verkliga slumpmässiga nummer för applikationer som behöver det. LRNG "uppfyller fullt ut kraven i 'Riktlinjer för entropikällor som används för att generera slumpmässiga bitar' SP800-90B", vilket gör det till en lösning på statliga standardproblem.
Matthew Garrett motsatte sig termen "verkliga slumpmässiga data", och noterade att valda enheter i princip kan modelleras tillräckligt noggrant för att bli förutsägbara: "vi drar inte från kvantiska händelser här."

Müller svarade att termen kommer från den tyska standarden AIS 31 för att beskriva en slumpgenerator som bara ger resultat "med samma hastighet som den grundläggande brusets källa producerar entropi."

Bortsett från terminologiska oenigheter, kommer närvaron av en låsningpool, som föreslagits av LRNG-patchar, bara att leda till olika problem, åtminstone om den kan nås utan privilegier.

Som Lutomirski sa: "Det löser inte problemet. Om två olika användare kör dumma program, som gnupg, kommer de bara att utarma varandra. Jag ser att det just nu finns två huvudproblem med /dev/random: det är benäget för DoS (dvs. resursutarmning, skadliga effekter eller något liknande), och eftersom inga privilegier krävs för att använda det är det också benäget för missbruk. Gnupg är felaktigt, det är en fullständig kollaps. Om vi lägger till ett nytt icke-privilegierat gränssnitt som används av gnupg och liknande program, kommer vi att förlora igen."

Müller noterade att tillägget av getrandom() nu gör att GnuPG kan använda detta gränssnitt, eftersom det ger den nödvändiga garantin för att poolen har initierats. Baserat på diskussioner med GnuPG-utvecklaren Werner Koch, anser Müller att garantin är den enda anledningen till att GnuPG för närvarande läser direkt från /dev/random. Men om det finns ett icke-privilegierat gränssnitt som är sårbart för tjänsteavbrott (som dagens /dev/random), så kommer det enligt Lutomirski att användas felaktigt av vissa applikationer.

Teodor Tsao (Theodore Yue Tak Ts’o), utvecklare av Linux underhållssystem för slumpmässiga tal, verkar ha ändrat åsikt om nödvändigheten av en blockeringspool. Han sa att borttagningen av denna pool skulle effektivt ta bort idén att Linux har en riktig slumpgenerator (TRNG): “Det här är inte meningslöst, eftersom det är exakt vad *BSD alltid har gjort.”

Han är också orolig för att tillhandahållandet av TRNG-mekanismer bara kommer att fungera som en lockbete för programvaruutvecklare och anser att det är omöjligt att garantera TRNG i kärnan med tanke på de olika typer av hårdvara som stöds av Linux. Problemet löses inte ens av möjligheten att arbeta med hårdvara endast på grundval av root-rättigheter: “Programvaruutvecklare anger att deras program ska installeras som root av säkerhetsskäl, eftersom det är det enda sättet att få tillgång till ‘verkligt bra’ slumpmässiga tal.”

Müller frågade om Tsao hade dragit sig tillbaka från att implementera blockeringspoolen som han själv föreslog för länge sedan. Tsao svarade att han planerar att ta patcharna från Lutomirsky och är aktivt emot att lägga till blockerande gränssnitt tillbaka i kärnan.

“Kärnan kan inte ge några garantier om huruvida brusets källa har karaktäriserats korrekt. Det enda en utvecklare av GPG eller OpenSSL kan få är en vag känsla av att TRUERANDOM är 'bättre', och eftersom de vill ha mer säkerhet, kommer de utan tvekan att försöka använda den. Vid en viss punkt kommer det att blockeras, och när någon annan smart användare (kanske en distributionsspecialist) sätter in det i init-skriptet och systemen slutar fungera, återstår det för användarna att klaga till Linus Torvalds själv.”

Tsao förespråkar också att kryptografer och de som verkligen behöver TRNG ges möjlighet att samla in sin egen entropi i användarrummet för att använda den efter eget gottfinnande. Han säger att insamling av entropi inte är en process som kärnan kan utföra på alla typer av stöd av hårdvara, dessutom kan kärnan själv inte bedöma mängden entropi som tillhandahålls av olika källor.

Kärnan bör inte blanda olika brus källor, och den bör självklart inte försöka hävda att den vet hur många bitar entropi den får när den försöker spela något "ryckigt entropi spel" på en oerhört enkel CPU-arkitektur för användartillämpningar inom IOT/Embedded, när allt är ur synk med en enda master-generator, när det inte finns några CPU-instruktioner för att omordna eller omdöpa register, etc.

Man kan diskutera tillhandahållandet av verktyg som försöker göra dessa beräkningar, men sådana saker bör utföras på varje användares utrustning, något som för de flesta användare av distributionen helt enkelt är opraktiskt. Om det dock endast är avsett för kryptografer, låt det ske i deras användarrum. Och låt oss inte förenkla GPG, OpenSSL, etc., så att alla säger: "vi vill ha "äkthet av slumpmässighet" och accepterar inte mindre." Man kan diskutera hur vi tillhandahåller gränssnitt för kryptografer så att de kan få den information de behöver genom åtkomst till primära brus källa, åtskilda och namngivna, och kanske kommer någon gång brus källan att kunna autentisera sig i biblioteket eller applikationen i användarrummet.

Det förekom en liten diskussion om hur ett sådant gränssnitt skulle kunna se ut, eftersom vissa evenemang kan ha säkerhetskonsekvenser. Cao påpekade att tangentbordsskanningskoder (dvs. tangenttryckningar) blandas i en pool som en del av insamlingen av entropi: "Att flytta detta till användarrummet, även genom ett privilegierat systemanrop, skulle vara, minst sagt, omdömeslöst." Det är fullt möjligt att andra tidpunkter för händelser kan skapa någon form av informationläckage genom sidokanaler.

Därmed väcks känslan av att det längevarande problemet med Linux slumpgeneratorer är på väg att lösas. De förändringar som slumpgeneratorerna har genomgått på sistone har faktiskt lett till DoS-problem under deras användning. Nu har effektiva sätt för att få de bästa slumpmässiga siffror som kärnan kan erbjuda dykt upp. Om TRNG fortfarande önskas för Linux, måste denna brist åtgärdas i framtiden, men troligtvis kommer detta inte att ske inom själva kärnan.

Lite reklam 🙂

Tack för att ni stannar kvar hos oss. Gillar ni våra artiklar? Vill ni se fler intressanta material? Stöd oss genom att göra en beställning eller rekommendera oss till era vänner, moln-VPS för utvecklare från $4,99, en unik motsvarighet till entry-level servrar som vi har skapat för er: Allt om VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps från $19 eller hur man korrekt delar en server? (alternativ med RAID1 och RAID10 finns tillgängliga, upp till 24 kärnor och upp till 40GB DDR4).

Dell R730xd är två gånger billigare i datacentret Equinix Tier IV i Amsterdam? Bara hos oss 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100TB från $199 i Nederländerna! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — från $99! Läs om Hur man bygger en företagsinfrastruktur med Dell R730xd E5-2650 v4-servrar som kostar 9000 euro för en bråkdel?

Källa: habr.com