Dotaz: Migrace systému na btrrfs raid1 - systemd UEFI secure boot

[lertimir]

Tak Zkusím se zeptat na radu. Mám systém (Arch) na SSd, který je postupně kopírován během dost let mezi několika zařízeními. Současný boot je LEGACY boot s grub2 z plně zašifrovaných disků (včetně /boot). Nedávno jsem si do stanice koupil NVMe tabletku a moje idea je přemigrovat sistém. Konfigurace cílové migrace: Plně zašifrovaný UEFI boot z NVMe s tím, že boot bude UEFI ->následně Grub2 který bootne btrfs raid 1 mezi oddíly na NVMe tabletce a SSD disku. Přemýšlím o cestách k cíli.

1. Zcela nová instalace. Instalovat nový systém na NVMe s Uefi, grub a systemd boot (zašifrovaná) a pak vyexportovat ze starého SSD (a nainstalovat na NVMe) seznam nainstalovaných balíků z depozitářů. Tím bych měl fakticky dva booty nový a stary. Následně smazat původní SSD a pripnout původní root oddíl jako rozříření nového oddílu na NVME do RAID 1 pole pro btrfs.
2. Postupný přechod současné instalace. z legacy boot na UEFI boot, pak z klasického bootu na systemd a naposled připojit NVMe do Raid 1 (to že by systém botoval fakticky přes ssd a ne nvme asi nevadí protože je tam jen chviličku.

co myslíte? nebo ještě jiná.

---

---

Odpovědi

[Josef Kufner]

Koukni na Sicherboot. Na nešifrovaný EFI oddíl dáš podepsané jádro a zbytek už bude dle libosti.

[Andrej]

Taky kernel + initramdisk může být plně šifrovaný (protože GRUB podporuje LUKS). Jediný povinně nešifrovaný oddíl je FAT32 UEFI oddíl, na kterém pak stačí mít pouze moduly GRUBu a jinak nic.

[Aleš Kapica]

Varianta druhá, kterou používám já je - hodit vidle na UEFI, a používat legacy boot.

[lertimir]

jaké vidle?

[Aleš Kapica]

Normální, na seno

[Andrej]

Legacy boot má spoustu nevýhod a (negativních) důsledků, které sahají daleko za pouhý způsob hledání bootovacího média. Takže něco takového bych ani náhodou, ba ani omylem nedělal.

[Aleš Kapica]

Zkus se rozpovídat

[Andrej]

Řekl bych, že web se o tom už rozpovídal víc než dost, takže nemusím já.

Všeho všudy zmíním jako kuriozitu, že dokonce i Snowdenova oblíbená instituce se o tom rozpovídala. Tak kdoví, třeba má v tom UEFI tajný univerzální backdoor. (Který by ovšem bylo snazší dostat do nějakého starého BIOSu, takže to asi nebude ono.)

[Aleš Kapica]

Systémové disky do 2TB nevyžadují GPT. Používám jenom linux. Secure boot mi nic zajímavého nepřináší. Také šifrování partition považuji za opruz, protože nic zajímavého na mých datech není. Naopak za backdoor považuji FAT, proto nevidím důvod, proč bych měl mít partition s tímto FS, když mi stačí Btrfs v raid1. Zavaděč mám v obou MBR pouze pro případ, že by jeden z těch mSATA disků chcípnul.

[lertimir]

No to je v zasadě legrační. Samozřejmě pokud jsi spokojen, když by na tvém počitači nabootoval někdo jiný nějakou life distribucí a přečetl si vše, co máš na discích, tak nepotřebuješ ani secure boot a ani šifrování. Nicméně tak jsem se neptal, požadavek je plně zašifrovaný systém, takže tvůj přístup je pro mne zcela irelevantní.

[Aleš Kapica]

Požadavek - plně zašifrovaný systém. Otázka: Proč?

Nehledě na to, že to, že to tak nepoužívám, neznamená že to nejde. Jenombych nešifroval na úrovni blokového zařízení. Ale to už jsme probírali jindy a jinde.

[k3dAR]

tady se letimir preklep, nechtel napsat system, ale disk = coz psal v #0 dotazu... a to s Legacy NEudelas, muzes sice pouzit Grub s aktivovanou podporou LUKS, mit LUKS pres "celej" disk, ale Grub bude NEsifrovane, NEpodepsane nahran v MBR + Cast mezi MBR a prvnim oddilem, to muze pak nekdo podvrhnout a ziskat pristup k LUKS heslu a nasledne datum...

to ze se ptas proc, neznamena ze odpoved neni jasna, ale jen to ze ti to asi stale nedochazi

[Aleš Kapica]

Ano. Skutečně mi nedochází, proč podstupovat takový oser. Citlivá data na pracovní stanici podle mě nemají co dělat. Rozhodně ne v takové formě aby byly jednoduše čitelné. Ovšem pak nastupuje otázka: Co jsou citlivá data? A komu by vůbec stálo za námahu se je snažit získat.

Možná se mýlím, ale mám neodbytný pocit, že zde se řešení tohoto problému věnují jen paranoici.

[k3dAR]

predne, neni to zadnej oser a jak sem psal, nejde jen o data, ale o treba o odchyceni tvejch prihlasovacich udaju do prohlizece kde bys klidne pri vypnuti mazal cache...
ale omlouvej si svoji neznalost/omezenost jak chces, mi "paranoici" co se vyjadrujeme k dotazu kde jde o FDE se ti uz smat nebudeme

[Aleš Kapica]

Oser je, že ti furt něco na pozadí šifruje data, což žere výkon a energii. Ne si to nastavit. A před odchycením tvých přihlašovacích údajů přes prohlížeč ti to stejně nepomůže, pokud si nedáš bacha.

[k3dAR]

to sifrovani zajistuje HW podpora pri sifrovani AES-NI v CPU, takze vykon nic nezere a energii v porovnani s tim co zere OS+SW je zanedbatelna...
ze odchytit prihlasovaci udaje lze i FDE ale neni argument pro to ze je FDE nepodstane nebo snad pro paranoiky

[Josef Kufner]

Celý oser je o tom, že pri instalaci zmáčkneš navíc šipku dolu při volbě, zda šifrovat a pak zapneš autologin, abys nezadával heslo k účtu, když už jsi zadal to k disku. Toť vše.

[jiwopene]

Já to mám převrácené – až během přihlášení se mi odemkne disk stejným heslem.

[k3dAR]

to ale asi nemas FDE protoze jinak by ten system co ti nabidne prihlaseni z FDE nemel bez zadani heslo jak nastartovat

[jiwopene]

Už jsem se v diskusi trochu ztratil ☺ – nemám FDE, šifrovaně jen uživatelská data a pár dalších věcí.

[k3dAR]

pokud to mas pres encfs, tak bacha

[Peter Golis]

To sú veľmi závažné bezpečnostné problémy:

1. Útočník môže zmeniť konfigurák pre toto šifrovanie ak má naň právo zápisu. To je ale všeobecná hrozba, nejedná sa o problém encfs.
2. Človek uvidí časové značky a veľkosti súborov, ale už nie ich obsah alebo názvy.

Tradičný háčkovací nástroj (gumený obušok) je nebezpečnejší, nezanecháva trvalé stopy.

[Petr Fiedler]

Masakr!

[jiwopene]

Tak to je na mě trochu moc, ale pokud už má někdo takový přístup k systému, tak už může rovnou vyměnit encfs za něco svého. Já šifruji hlavně kvůli tomu, aby vyhozený/reklamovaný/odložený/kdovíjaký disk neobsahoval citlivá data – beru to tak, že kdyby měl někdo přístup k mému počítači, tak si s ním může dělat cokoliv – HW keyloggeru, který se dá celkem snadno sehnat, Secure Bootem nezabráním.

encfs nepoužívám a nikdy jsem ho ještě nepoužil. Z FUSE mám pořád takový pocit že to kolečko jádro-userspace-jádro-userspace-… je moc dlouhé. Proti FUSE jako takovému nic nemám, ale pro každodenní používání mi nepřipadá vhodný.

[k3dAR]

SecureBoot (s vlasntima klicema) zajisti nenastartovani podvrzeneho systemu, zadat heslo pro odemceni LUKS neni vetsi opruz nez zadavat heslo do LoginScreenu, kterej muze s LUKS byt samozrejme autologin a zajisti ze ti nikdo nejen neodzici jakekoliv data, ale ani nezkompromituje system kterej by pak mohl predavat veskere tve uhozy do klavesnice, krome tech dat z disku... pokud v tom nevidis rozdil tak asi zahod PC, opust IT a jdi pestovat zeleninu

[jiwopene]

Na podvržení systému je takový ten jumper, který resetuje nastavení. Pokud si někdo s tím dá dost práce, tak, pokud nekontrolujete nastavení Secure Boot při každém spuštění, nepoznáte nic.

[k3dAR]

jasne, nebo vyndat baterku, prepsat eeprom, atd... nicmene snad uznas ze to vyzaduje vetsi zakrok, nez kdyz ma nekdo nesifrovanej disk a nahodis USBLive a vytahnes si co chces, nebo neco pridas

[Jendа]

Já musím říct, že se mi EFI boot taky líbí -- jednoduše dropnu na tu malou partition soubor, a nemusím řešit nějakou instalaci do MBR a strkání dat do místa před první partition. Jenom si ještě musím načíst, jak se ručně udělá ta binárka (grubx64.efi) když v ní chci nějaké extra moduly -- zatím jsem většinou používal automatiku v tom systému a vyšlo to, ale chtěl bych si umět vyrobit vlastní monolitický GRUB a o nic se nestarat. Moje distribuce dodává 1.7MB velkou binárku monolithic/grubx64.efi, zatímco nainstalovaný /boot/efi/EFI/debian/grubx64.efi má jenom 132 kB. Nevím, jestli v té monolithic jsou moduly _všechny_, ale jednou jsem to použil a nabootovalo to.

[k3dAR]

spis se podivej na ten sicherboot s (jen) vlastnima klicema v efi a extra moduly si pores rovnou do initramfs

[jiwopene]

Už jsem to někdy dělal (viz grub-mkimage(1)). Funguje to podobně jako initrd vestavěný do jádra – předáte tomu skriptu obraz disku (memdisk) nebo konfigurační soubor a vygeneruje bootovatelný obraz GRUBu. Pro Leagcy BIOS tam je velikostní limit. Bylo to něco kolem 32 kiB.

[Josef Kufner]

Je to jedno. Buď budeš mít nešifrovaný Grub, nebo jádro. Citlivé údaje by neměly být ani v jednom. Podstatné je, aby to bylo celé podepsané, včetně všech modulů a konfiguračních souborů, a Secure Boot to mohl při zavádění ověřit. Pokud použiješ Sicherboot, tak se initramdisk zapeče do jádra a ten jeden soubor je podepsaná EFI binárka, kterou jde přímo bootovat a u které nejde nic měnit, ani volby jádra (dokud Secure Boot nevypneš).

[k3dAR]

Grub pouzivaji jen dinosauri... LUKS sice podporuje, ale bez HW sifrovani, tzn. je to pomale, naproti tomu ten Josefem zminenej Sicherboot si vystaci se zadanim hesla az jen v initramfs, kde uz je HW sifrovani, tzn. je to rychle, navic mas efi binarku od sicherboot (s jadrem a initramfs v sobe) podepsanou vlastnima klicema, takze nehrozi ze by nekdo podvrhnul backdorovanej Grub...

[Jendа]

Já tomu teda nerozumím, ale GRUB snad natahuje jenom jádro a initramdisk, tj. maximálně desítky MB, a to i bez HW akcelerace šifrování musí být hned, ne?

[Andrej]

Bohužel ne. Tady má předřečník tentokrát pravdu, pokud jde o výkon.

Vůbec nejde o rychlost dešifrování kernelu. To je celkem „okamžité“, protože je to celkem běžná symetrická šifra, která se klidně přečte i bez HW akcelerace. (A ano, GRUB (zatím) nepoužívá AES-NI.)

Jde o PBKDF (Password-Based Key Derivation Function). Ta je naschvál pomalá. Většinou se totiž počítají cca statisíce (někdy miliony) hashovacích iterací po nějakou předem stanovenou dobu (implicitně 2 sekundy, pokud se nepletu), než se dojde od člověkem čitelného hesla k LUKS klíči od slotu (který potom následně odemyká master klíč).

Cílem je, aby slabá hesla neznamenala nutně slabé klíče ve slotech. Nevýhodou je, že samotný výpočet PBKDF pak může být klidně časově náročnější než čtení mnoha set MB kernelu + initramdisku.

No a problém je, že když s AES-NI (nebo jinou akcelerací) ty statisíce iterací PBKDF proběhnou (dejme tomu) za dvě sekundy (nebo co si nastavíš v cryptsetup luksAddKey / cryptsetup luksFormat), tak bez HW akcelerace (tedy v GRUBu) bude tentýž výpočet PBKDF a otevření slotu trvat ultra-hyper-dlouho.

Moje zkušenost na skoro dnešním HW (8. generace notebookových procesorů Intel) je, že 2-sekundová PBKDF bude v GRUBu trvat kolem 15 sekund. To je dlouho, ve srovnání s tím, co se očekává od bootu z SSD.

Na starším hardware (4. generace notebookových procesorů Intel) jsem musel ten čas pro PBKDF snížit (u všech používaných slotů; jinak to nemá ten očekávaný efekt) na 500 milisekund, což byla kdysi dávno původní implicitní hodnota. Jinak se totiž v GRUBu stalo, že GRUB dosáhl nějakého svého interního timeoutu (který se nastaví nevímjak; na to jsem nepřišel) a tvrdil, že nemůže odemknout žádný slot, i když měl platné heslo.

Takže tady souhlasím s výhradami ohledně výkonu: Dokud GRUB nebude umět AES-NI (neřkuli vícevláknovost, která je hlavní feature u LUKS2 a PBKDF2), bude tohle kámen úrazu. Na desktopovém hardwaru není co řešit. Nicméně na notebooku, hlavně když bootuje v úsporném režimu na baterii, to může být problém.

[lertimir]

Díky všem za reakce. Sice to většinou byly odpovědi na jinou otázku než jsem poslal. A to na otázku, jak má cílový systém vypadat a ne na otazku jak do něj domigrovat, ale i tak mi z diskuse plyne, že rozumnější bude cesta 1. Tedy na NVMe postavit systém odspoda znovu než řešit migraci. O sicherboot si přečtu. Stanice je desktop, takže cíl bude podepsané EFI a asi si zkušebně projdu cestu jak s Grubem tak přímo s initramfs.

[k3dAR]

no s migraci... muzes na NVMe udelat 512-1024MiB EFI oddil (pokud bys sel (a doporucuju) do sicherboot, tak at se ti pripadne vejde vice "jader+initramfs"), pak LUKS\BTRFS, prelejes tam system+data, zmenis /etc/fstab, rebootnes, doisntalujes sicherboot, klice co vygeneruje narves do EFI kde predtim smazes stavajici Microsofti... pak puvodni disk pridas do btrfs raidu (coz postup pred/po neznam z praxe, tak nekomentuju :)
nevim co myslis to migraci z klasickeho boot na systemd, pokud init tak to asi s diskem nesouvisi, pokud neco kolem zavadece, tak sicherboot pouziva systemd-boot, kdy sicherboot je v podstate "jen" sada skriptu co ti pripravej vlastni klice, pripravej polozku boot menu pri instalaci/aktualizaci jadra/initramfs s vygenerovanou a podepsanou tvejma klicema efi binarkou obsahujici kernel+initramfs...

[lertimir]

nevim co myslis to migraci z klasickeho boot na systemd, pokud init tak to asi s diskem nesouvisi, pokud neco kolem zavadece, tak sicherboot pouziva systemd-boot, kdy sicherboot je v podstate "jen" sada skriptu co ti pripravej vlastni klice, pripravej polozku boot menu pri instalaci/aktualizaci jadra/initramfs s vygenerovanou a podepsanou tvejma klicema efi binarkou obsahujici kernel+initramfs...

myslím tím tohle. System je Arch a initramfs stavím podle hooků v této tabulce ve sloupečku "busybox init". Jak jsem psal je to vlastně mnohaletá konfigurace přepisovaná s jednoho systému na druhý. Nicméně pokud chci z initramfs současně otevřít více než jeden device potřebuji přejít z hooku encrypt na sd-encrypt (to je potřeba abych se dvou device odemkl dva zašifrované oddíly a z nich udělal btrfs RAID 1 a tím pádem je třeba změnit celé generování initramfs a samozřejmě potřebuji to udělat "správně" abych si nenaběhl do situace, kdy mi systém nenajede a mám v něm jen zašifrované disky. (Ano, hlavičky i kliče mám jinde bezpečně uloženy, ale byla by to otrava.)

Navíc sicherboot pracuje s jinak nazvaným initramfs než pracuje Arch, takže pro jeho použití budou třeba ještě další změny. Ta situace, kterou popisuje Andrej, tedy mít v /efi podepsaný Grub, který odemkne disk, hodí Grub menu, po grub menu natáhne jádro a initramfs ze zašifrovaného /boot, a ze zapečeného kliče v initramfs si jádro odemkne disk ještě jednou a jede dál, mi připadá jako přímočará a jediná nevýhoda je pomalejší odemykání, díky tomu že grub nepoužije HW akceleraci.

[k3dAR]

uz chapu, nicmene s tim zkusenost nemam, ale teoreticky, kdyz si po prechodu na UEFI pripravis initramfs postaru, tak (pokud se nemusi pro tu zmenu neco odebrat z rootfs co by "busybox initu" schazelo) pokud s "initramfs systemd init" nenajede, tak bys mel nastatovat vyberem v Grubu toho puvodniho ne?

[k3dAR]

coz se jeste vice projevi, kdyz ma clovek (s Grub) kvuli tomu aby po 1 odemceni pres Grub po natazeni jadra nemusel odemknout znovu LUKS pres initramfs, v initramfs luks keyfile co to odemne jiz sam, takze ma aktivni 2 key sloty (v prvnim to interaktnivni, v druhem z keyfile) a zada (do Grub) spatne heslo (coz se mi s 3x znakovym velke/male/specialniznaky) obcas stane, takze se ta cekaci doba v Grub zdvojnasobi protoze se checkuje i ten druhej slot, nez to zarve ze se spatne zadalo LUKS heslo a hodi to do Grub rescue radku, v kterem bud musi rucne pustit cryptomount s parametrem oddilu, nebo udelat reboot... pri sicherboot tim ze se zadava heslo az/jen v initramfs se jednak pouzije AES-NI a kdyz se zada blbe, tak se ani nekontroluje druhej slot protoze keyfile v nem neni potreba... a jeste ta zminena nevyhoda ze Grub muze podstrcit "backdorovanej" kdyz ho podepise defaultnim klicem, ale se sicherboot a tvejma klicema ti nikdo nic nepodvrhne (resp. jedine pri rozebrani NB, vyrvani baterky a/nebo preflashovanim eeprom)

[Andrej]

To je sice všechno pravda, ale pak zase nemůžu mít ultra-tajný kernel + initramdisk, protože je "jenom" podepsaný a každý se na něj může podívat. Všechno má svá pro a proti.

Že současná podpora LUKS v GRUBu potřebuje reimplementaci, to je celkem jasné. PBKDF2 se tam prakticky nedá vypočítat, takže i když GRUB teoreticky LUKS2 podporuje, tohle omezení zatím nepřekonal.

Všechno dohromady (Sicherboot + rychlé otevirání LUKS + tajný kernel) by se asi dalo zařídit pomocí Sicherboot + kexec(), ale konfigurace by byla značný voser, pokud na to není nějaký hotový toolchain.