Trable s urandom seed

8.11.2020 15:52 | Přečteno: 2205× | Linux | | poslední úprava: 8.11.2020 15:52

Na embedded zařízeních občas po bootu nenajelo sshd.

Instaloval jsem APU2 - jednodeskový počítač s překvapivě výkonnou x86 a skutečným mSATA (takže neřešíte microSD karty jako u různých Ovoce Pi). Neměl jsem k tomu připojené žádné periferie, a po bootu trvalo několik minut, než se tam dalo přihlásit po síti. Po přihlášení na lokální konzoli se ukázalo, že visí zaseklý proces sshd -t, a až časem se to odsekne, zaloguje se random: crng init done a sshd začne přijímat spojení. Jenom pro představu, takhle vypadá debianí sshd unita:

[Service]
ExecStartPre=/usr/sbin/sshd -t
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS

a -t je nějaký parametr co testuje konfiguraci. Takže to čeká už v tom. Mimochodem tohle se blbě ladí, protože když do systému začnete rejpat, tak mu tím přidáváte entropii a k problému nedojde.

Jedno z nalezených řešení doporučovalo nainstalovat haveged. Ten se snaží entropii sehnat různě, kdo ví kde, a s kdo ví jakou kvalitou. To mi ale přijde nekoncepční -- tenhle problém se přece odjakživa řeší tím, že se při vypínání uloží náhodné bajty na disk, a při bootu se načtou, a tím je hned entropie dostatek.

V systemd se o toto stará služba systemd-random-seed.service. Ta data bere ze souboru /var/lib/systemd/random-seed. A tady zjistíme, že když se do jaderného zásobníku entropie vkládají data, tak se o nich dá říct, jestli jim má jádro věřit (resp. kolik entropie obsahují, a dáte tam hodnotu od 0 po délku dat). Jádro pak podle toho (ne)zvýší odhad, jak moc entropie má k dispozici, a procesy vyžadující kvalitní entropii se odseknou, až když je tento odhad nějak vysoký. A ta systemd služba říká, že data ze souboru se započítat nemají.

Naštěstí v novém systemd se kouká na proměnnou prostředí SYSTEMD_RANDOM_SEED_CREDIT, která nastavuje přesně toto. Můžete si to vyzkoušet:

# cat /proc/sys/kernel/random/entropy_avail
46
# /lib/systemd/systemd-random-seed load     -- loadnutí seedu s defaultním nastavením
# cat /proc/sys/kernel/random/entropy_avail
53     -- nic zásadního se nezměnilo
# SYSTEMD_RANDOM_SEED_CREDIT=force /lib/systemd/systemd-random-seed load      -- vynucení důvěry
# cat /proc/sys/kernel/random/entropy_avail
2457   -- a už je entropie dost

Takže řešení je udělat systemctl edit systemd-random-seed.service, napsat tam

[Service]
Environment="SYSTEMD_RANDOM_SEED_CREDIT=force"

a hotovo. Mimochodem ten soubor se seedem se aktualizuje jen při korektním vypínání počítače, pokud vaše počítače běží a vypínají se jen nekorektně při výpadku napájení, možná by stálo za to dát /lib/systemd/systemd-random-seed save do cronu.

Co ale udělat, pokud nemáte dostatečně nový systemd, nebo nemáte systemd vůbec? Například v Debianu Buster systemd ještě tuto volbu nepodporuje, je to až v buster-backports. Můžete to udělat ručně, to vkládání entropie se dělá jedním ioctl. Tady je skript v Pythonu, co to dělá. Používá se takto: cat uložený_náhodný_soubor | ./rndaddentropy.py. Přidejte si to třeba do rc.local a vyřešeno.

Pro systemd hatery dodávám, že třeba init z historického Debianu Lenny vypadá, že entropii z uloženého seedu taky neoznačuje jako důvěryhodnou. Ale je možné, že tehdejší kernely to nerozlišovaly. Teprve nedávno se nějaké věci měnily.

       

Komentáře

[pavele]

V CentOS je rngd, neřeší právě toto?

[Jendа]

Možná, ale já nechtěl démona, když to jenom potřebuju při bootu správně inicializovat.

[Miriam (ta pravá)]

Řešila jsem stejný problém, pomohlo mi toto: https://thedonald.win/

Náš administrátor shledal tento komentář závadným.

Vulgarity.

Zobrazit komentář

[-]

Četl jsem "trable s uranem" a čekal jsme report o nějakém incidentu v Brmlabu.

[ewew]

Mohol by si dať detaily ako si to objednal ?

[Jendа]

Šel jsem na https://www.i4wifi.cz/cs/225578-apu-system-board-pc-engines-apu2d2 a zmáčkl jsem tlačítko Koupit.

[trekker.dk]

<povzdech>Pár let zpátky bych přesně věděl, na co bych to využil. Dneska takovejch hraček a žádná práce pro ně </povzdech>

[ewew]

Možno tento projekt ? Len otázne či to bude fungovať aj tomto hw.

[👻]

voproti rpi to má jakoby navíc bzučák taky :O ;D

[Max]

Já jsem kdysi řešil, že se java aplikační server Oracle Weblogic spouští hodně dlouho, náhodně dlouho, jednou hned, podruhé až za 2min atd. Při spuštění si také generuje entropii. Nakonec jsem to vyřešil nasazením rngd.
Zdar Max

[Ivan]

Muzu se zeptat jaka je to verze? Nejaka starsi vykopavka anebo neco soucasneho?

Kdysi jsem se v tomhle problemu dost vrtal, ale jsem dospel k nazoru ze to muzu vypustit a ze soucasne techologie uz tohle maji poresene.

[luky]

Mne pomohlo CONFIG_GCC_PLUGIN_LATENT_ENTROPY (seed nemuzu ukladat, protoze system bezi z RO uloziste).

[trekker.dk]

Systemd-hater hlásí, že v balíku initscripts je skript /etc/init.d/urandom, který při vypnutí počítače z urandom uloží kernel.random.poolsize bajtů do souboru a po zapnutí udělá cat > /dev/urandom.

Zjevně to stačí, protože ještě před vydáním Debianu Buster to vypadalo, že budu muset řešit to samé: boot zůstal viset na inicializaci rng. Nejdřív jsem to chtěl řešit tím haveged (akorát spuštěným jen jednorázově), ale nakonec to nebylo potřeba - hádám, že přidali právě tenhle skript.

[Jendа]

Ne, zápisy do /dev/urandom se právě necreditují. Jediný způsob, o kterém vím, je právě přes to ioctl.

[trekker.dk]

No, hádat se nebudu, ale

• jinej init skript, kterej má ve jméně "rand", na serverech nemám
• když jsem pouštěl to haveged, tak jsem to dělal s parametrem "vygeneruj mi nějaký počet bajtů" a výsledek jsem natrubkoval do /dev/urandom - to stačilo, aby se mi boot na inicializaci random poolu nezasekl
• nakonec nedělám ani to, a boot se nezasekává

Tak asi kouzlo Ale pro mě za mě, dokud to funguje, šťourat se v tom nebudu.

[Ivan]

Tohle je tema na nekonecnou diskuzi. Dneska je jsou uz obe zarizeni /dev/random a /dev/urandom bezpecna. A na internetu je spousta clanku ktere porovnavaji vlastnosti obou generatoru. Napr Java 10 uz pouziva /dev/urandom.

[👻]

pro cryptografii jakože teda asi i tamto sshd je v unixu preferovaný /dev/urandom hele :O :O

Fact: /dev/urandom is the preferred source of cryptographic randomness on UNIX-like systems.

[Petr Tomášek]

APU2? To bylo se slušným výkonem před 5 lety. Dnes už by to chtělo něco silnějšího. (Jinak používám APU a APU2 jako routery...)

[Peter Golis]

Kde sú tie časy, keď HW v CPU nemalo RNG. A do serverov sa inštaloval daemon ktorý vyrátaval náhodné čísla čítaním z pripojeného stereo mikrofónu ktorý počúval šum v serverovni.

[Agáta]

Ok, boomer.