Linux: cael gwared ar y pwll clo /dev/random

Mae'n hysbys bod gan /dev/random, generadur rhifau ffug-hap diogel cryptograffig (CSPRNG), un broblem annifyr: blocio. Mae'r erthygl hon yn esbonio sut y gallwch chi ei ddatrys.

Dros yr ychydig fisoedd diwethaf, mae'r cyfleusterau cynhyrchu rhifau ar hap yn y cnewyllyn wedi'u hailweithio ychydig, ond mae problemau yn yr is-system hon wedi'u datrys yn ehangach. ffrâm amser. Y mwyaf newidiadau diwethaf eu gwneud i atal galwad system getrandom() rhag blocio am amser hir pan fydd y system yn cychwyn, ond y rheswm sylfaenol am hyn oedd ymddygiad blocio'r pwll ar hap. Byddai ardal ddiweddar wedi cael gwared ar y pwll hwn a byddai disgwyl iddo fynd tuag at y prif graidd.

Cyhoeddodd Andy Lutomirski y drydedd fersiwn o'r clwt ddiwedd Rhagfyr. Mae'n cyfrannu "dau newid semantig mawr i API Linux ar hap". Mae'r clwt yn ychwanegu baner GRND_INSECURE newydd i'r alwad system getrandom () (er bod Lutomirsky yn cyfeirio ato fel getentropi (), sy'n cael ei weithredu yn glibc gan ddefnyddio getrandom () gyda baneri sefydlog); mae'r faner hon yn achosi'r alwad i ddychwelyd y swm o ddata y gofynnir amdano bob amser, ond heb warantu bod y data ar hap. Bydd y cnewyllyn yn gwneud ei orau i gynhyrchu'r data hap gorau sydd ganddo ar yr amser penodol. “Mae'n debyg mai'r peth gorau i'w wneud yw ei alw'n 'ANSICR' (anniogel) i atal yr API hwn rhag cael ei ddefnyddio ar gyfer pethau sydd angen diogelwch."

Mae'r clytiau hefyd yn cael gwared ar y pwll blocio. Ar hyn o bryd mae'r cnewyllyn yn cynnal dau gronfa ddata ar hap, un yn cyfateb i /dev/hap a'r llall i /dev/urandom, fel y disgrifir yn hwn Erthygl 2015. Y pwll blocio yw'r pwll ar gyfer /dev/hap; Bydd darllen ar gyfer y ddyfais honno'n rhwystro (sy'n golygu ei enw) nes bod entropi "digon" wedi'i gasglu o'r system i fodloni'r cais. Mae darlleniadau pellach o'r ffeil hon hefyd yn cael eu rhwystro os nad oes digon o entropi yn y pwll.

Mae tynnu'r pwll clo yn golygu bod darllen o /dev/hap yn ymddwyn fel getrandom() gyda baneri wedi'u gosod i sero (ac yn troi baner GRND_RANDOM yn noop). Unwaith y bydd y generadur haprifau cryptograffig (CRNG) wedi'i gychwyn, ni fydd darllen o /dev/hap a galwadau i getrandom (..., 0) yn rhwystro a bydd yn dychwelyd y swm o ddata hap y gofynnwyd amdano.

Dywed Lutomirsky: “Rwy’n credu bod y pwll blocio Linux wedi dod yn anarferedig. Mae CRNG Linux yn cynhyrchu allbwn sy'n ddigon da i'w ddefnyddio hyd yn oed ar gyfer cynhyrchu allweddol. Nid yw’r pwll blocio yn gryfach mewn unrhyw ystyr materol ac mae angen llawer o seilwaith o werth amheus i’w gefnogi.”

Gwnaethpwyd y newidiadau gyda'r nod o sicrhau na fyddai rhaglenni presennol yn cael eu heffeithio mewn gwirionedd, ac mewn gwirionedd, byddai llai o broblemau gydag arosiadau hir am bethau fel cynhyrchu allweddi GnuPG.

“Rhaid i’r penodau hyn beidio ag amharu ar unrhyw raglenni presennol. /dev/urandom yn aros yr un fath. Mae /dev/ar hap yn dal i flociau yn syth ar gist, ond mae'n blocio llai nag o'r blaen. bydd getentropi() gyda'r baneri presennol yn dychwelyd canlyniad sydd yr un mor addas at ddibenion ymarferol ag o'r blaen."

Nododd Lutomirsky ei fod yn dal i fod yn gwestiwn agored a ddylai’r cnewyllyn ddarparu “gwir niferoedd ar hap,” fel y’i gelwir, sef yr hyn yr oedd y cnewyllyn blocio i fod i’w wneud i raddau. Dim ond un rheswm y mae’n ei weld am hyn: “cydymffurfio â safonau’r llywodraeth.” Awgrymodd Lutomirsky pe bai'r cnewyllyn yn darparu hyn, y dylid ei wneud trwy ryngwyneb hollol wahanol, neu dylid ei symud i ofod defnyddwyr, gan ganiatáu i'r defnyddiwr adfer samplau digwyddiad amrwd y gellid eu defnyddio i greu pwll clo o'r fath.

Awgrymodd Stephan Müller fod ei set clytiau ar gyfer Linux Generator Rhif Ar Hap (LRNG) (fersiwn 26 a ryddhawyd ar hyn o bryd) a allai fod yn ffordd o ddarparu niferoedd hap gwirioneddol ar gyfer ceisiadau sydd ei angen. Mae LRNG yn “cydymffurfio’n llawn â Chanllawiau SP800-90B ar Ffynonellau Entropi a Ddefnyddir i Gynhyrchu Darnau Ar Hap,” gan ei wneud yn ateb i broblem safonau’r llywodraeth.
Gwrthwynebodd Matthew Garrett y term “gwir ddata hap,” gan nodi y gallai’r dyfeisiau a samplwyd mewn egwyddor gael eu modelu’n ddigon manwl gywir i’w gwneud yn rhagweladwy: “nid ydym yn samplu digwyddiadau cwantwm yma.”

Ymatebodd Müller fod y term yn dod o safon Almaeneg AIS 31 i ddisgrifio generadur rhif ar hap sydd ond yn cynhyrchu canlyniad "ar yr un gyfradd ag y mae'r ffynhonnell sŵn sylfaenol yn cynhyrchu entropi."

Ar wahân i wahaniaethau terminoleg, bydd cael pwll clo fel yr awgrymir gan y clytiau LRNG yn syml yn arwain at broblemau amrywiol, o leiaf os ceir mynediad iddo heb freintiau.

Fel y dywedodd Lutomirsky: “Nid yw hyn yn datrys y broblem. Os bydd dau ddefnyddiwr gwahanol yn rhedeg rhaglenni gwirion fel gnupg, byddan nhw'n draenio ei gilydd. Gwelaf fod dwy brif broblem gyda /dev/hap ar hyn o bryd: mae’n dueddol o DoS (h.y. disbyddiad adnoddau, dylanwad maleisus neu rywbeth tebyg), a chan nad oes angen unrhyw freintiau i’w ddefnyddio, mae hefyd yn dueddol o gael ei gam-drin. Mae Gnupg yn anghywir, mae'n gwymp llwyr. Os byddwn yn ychwanegu rhyngwyneb di-freintiedig newydd y bydd gnupg a rhaglenni tebyg yn ei ddefnyddio, byddwn yn colli eto."

Nododd Mueller y bydd ychwanegu getrandom () nawr yn caniatáu i GnuPG ddefnyddio'r rhyngwyneb hwn, gan y bydd yn darparu'r warant angenrheidiol bod y pwll wedi'i gychwyn. Yn seiliedig ar drafodaethau gyda datblygwr GnuPG Werner Koch, mae Mueller yn credu mai'r warant yw'r unig reswm y mae GnuPG yn ei ddarllen yn uniongyrchol o /dev/random ar hyn o bryd. Ond os oes rhyngwyneb di-freintiedig sy'n agored i wrthod gwasanaeth (fel y mae /dev/hap heddiw), mae Lutomirsky yn dadlau y bydd yn cael ei gamddefnyddio gan rai cymwysiadau.

Mae'n ymddangos bod Theodore Yue Tak Ts'o, datblygwr is-system rhifau hap Linux, wedi newid ei feddwl am yr angen am gronfa blocio. Dywedodd y byddai cael gwared ar y pwll hwn i bob pwrpas yn cael gwared ar y syniad bod gan Linux wir generadur rhif hap (TRNG): "nid yw hyn yn nonsens, gan mai dyma'n union beth mae BSD bob amser wedi'i wneud."

Mae hefyd yn pryderu y bydd darparu mecanwaith TRNG yn abwyd i ddatblygwyr cymwysiadau ac mae'n credu mewn gwirionedd, o ystyried y gwahanol fathau o galedwedd a gefnogir gan Linux, ei bod yn amhosibl gwarantu TRNG yn y cnewyllyn. Ni fydd hyd yn oed y gallu i weithio gydag offer yn unig gyda breintiau gwraidd yn datrys y broblem: msgstr "Mae datblygwyr cymhwysiad yn nodi bod eu cymhwysiad yn cael ei osod fel gwraidd at ddibenion diogelwch, fel mai dyma'r unig ffordd y gallwch gael mynediad at y rhifau hap 'da iawn'."

Gofynnodd Mueller a oedd Cao wedi rhoi'r gorau i weithredu'r pwll blocio yr oedd ef ei hun wedi'i gynnig ers amser maith. Ymatebodd Cao ei fod yn bwriadu cymryd clytiau Lutomirsky a'i fod yn gwrthwynebu ychwanegu rhyngwyneb blocio yn ôl i'r cnewyllyn.

“Ni all y cnewyllyn roi unrhyw sicrwydd a yw’r ffynhonnell sŵn wedi’i nodweddu’n iawn. Yr unig beth y gall datblygwr GPG neu OpenSSL ei gael yw teimlad annelwig bod TRUERANDOM yn "well", a chan eu bod eisiau mwy o ddiogelwch, heb os, byddant yn ceisio ei ddefnyddio. Ar ryw adeg bydd yn cael ei rwystro, a phan fydd defnyddiwr craff arall (efallai arbenigwr dosbarthu) yn ei fewnosod yn y sgript init a bod y systemau'n stopio gweithio, dim ond i Linus Torvalds ei hun y bydd yn rhaid i ddefnyddwyr gwyno. ”

Mae Cao hefyd yn argymell rhoi ffordd i cryptograffwyr a'r rhai sydd angen TRNG mewn gwirionedd i gynaeafu eu entropi eu hunain mewn gofod defnyddiwr i'w ddefnyddio fel y gwelant yn dda. Dywed nad yw casglu entropi yn broses y gall y cnewyllyn ei pherfformio ar yr holl galedwedd gwahanol y mae'n ei gynnal, ac ni all y cnewyllyn ei hun amcangyfrif faint o entropi a ddarperir gan wahanol ffynonellau ychwaith.

“Ni ddylai’r cnewyllyn fod yn cymysgu gwahanol ffynonellau sŵn gyda’i gilydd, ac yn sicr ni ddylai fod yn ceisio hawlio gwybod faint o ddarnau o entropi y mae’n ei gael pan mae’n ceisio chwarae rhyw fath o “gêm entropi twitchy” ar CPU hynod o syml pensaernïaeth ar gyfer defnyddwyr defnyddwyr. Achosion IOT/Mewnblanedig lle nad yw popeth yn cydamseru ag un prif osgiliadur, lle nad oes unrhyw gyfarwyddyd CPU i aildrefnu neu ailenwi cofrestr, ac ati.”

“Gallwch siarad am ddarparu offer sy'n ceisio gwneud y cyfrifiadau hyn, ond mae'n rhaid gwneud pethau o'r fath ar galedwedd pob defnyddiwr, nad yw'n ymarferol i'r rhan fwyaf o ddefnyddwyr dosbarthu. Os yw hyn wedi'i fwriadu ar gyfer cryptograffwyr yn unig, yna gadewch iddo gael ei wneud yn eu gofod defnyddiwr. A gadewch i ni beidio â symleiddio GPG, OpenSSL, ac ati fel bod pawb yn dweud "rydym eisiau "gwir hap" ac ni fydd yn setlo am lai." Gallwn siarad am sut rydym yn darparu rhyngwynebau i cryptograffwyr fel y gallant gael y wybodaeth sydd ei hangen arnynt trwy gyrchu'r ffynonellau sŵn sylfaenol, wedi'u gwahanu a'u henwi, ac efallai rywsut y gall y ffynhonnell sŵn ddilysu ei hun i lyfrgell neu raglen gofod defnyddiwr. ”

Cafwyd peth trafodaeth am sut olwg fyddai ar ryngwyneb o'r fath, oherwydd er enghraifft, gallai fod goblygiadau diogelwch ar gyfer rhai digwyddiadau. Nododd Cao fod codau sgan bysellfwrdd (h.y. trawiadau bysell) yn cael eu cymysgu i mewn i bwll fel rhan o gasglu entropi: “Byddai dod â hwn i ofod defnyddiwr, hyd yn oed trwy alwad system freintiedig, yn annoeth a dweud y lleiaf.” Mae'n eithaf posibl y gallai amseriadau digwyddiadau eraill greu rhyw fath o ollyngiad gwybodaeth trwy sianeli ochr.

Felly mae'n edrych fel bod problem hirsefydlog gydag is-system rhif hap Linux ar y ffordd i ateb. Mae'r newidiadau y mae'r is-system haprifau wedi'u gwneud yn ddiweddar wedi arwain at broblemau DoS wrth ei defnyddio. Nawr mae yna ffyrdd effeithlon o gael y rhifau hap gorau y gall y cnewyllyn eu darparu. Os yw TRNG yn dal yn ddymunol ar Linux, yna bydd angen mynd i'r afael â'r diffyg hwn yn y dyfodol, ond yn fwyaf tebygol ni fydd hyn yn cael ei wneud o fewn y cnewyllyn ei hun.

Rhai hysbysebion 🙂

Diolch am aros gyda ni. Ydych chi'n hoffi ein herthyglau? Eisiau gweld cynnwys mwy diddorol? Cefnogwch ni trwy osod archeb neu argymell i ffrindiau, cwmwl VPS i ddatblygwyr o $4.99, analog unigryw o weinyddion lefel mynediad, a ddyfeisiwyd gennym ni ar eich cyfer chi: Y gwir i gyd am VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps o $ 19 neu sut i rannu gweinydd? (ar gael gyda RAID1 a RAID10, hyd at 24 craidd a hyd at 40GB DDR4).

Dell R730xd 2 gwaith yn rhatach yng nghanolfan ddata Equinix Haen IV yn Amsterdam? Dim ond yma 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV o $199 yn yr Iseldiroedd! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - o $99! Darllenwch am Sut i adeiladu seilwaith Corp. dosbarth gyda'r defnydd o weinyddion Dell R730xd E5-2650 v4 gwerth 9000 ewro am geiniog?

Ffynhonnell: hab.com

Ychwanegu sylw