Dotaz: Sifrovani v Linuxu - bezpecnost a spolehlivost pri obnove dat

[Lukas]

Dobry den,
mam par otazek ohledne sifrovani v Linuxu. Chci delat cistou instalaci Ubuntu s 3mi oddily: /, /home, swap(, mozna jeste 1 oddil neco jako /media/zaloha nebo tak neco), vse na 1 fyzicky magneticky HDD. Je lepsi zasifrovat:
1. cely disk - cim, jak na to, co je nejbezpecnejsi?
2. jen jednotlive oddily - cim, jak na to, co je bezpecnejsi?
3. jen domovksy adresar pomoci ecrypt jak mi to nabizi instalator v posl. kroku instalace?
4. napada me jeste sifrovani na urovni jednotlivych souboru a adresaru stylem co je moc tajne to zasifrovat, jinak zbytek oddilu nesifrovany, ale to asi pouzit nechci - ale cim treba?

Idealne pro nejvyssi bezpecnost bych sifroval cely disk - tj. moznost 1 - pri utoku napr. fyzicky vyndanim HDD a nasazenim do jineho kompu nebo bootu z LiveCD, budou chranena vsechna uzivatelska i jina data, system, programy i zbytky toho co zbylo ve swapu, tak by to melo fungovat podle clanku - funguje to tak i v realu, ne? Ze kdyz utocnik nezna heslo tak se muze jit maximalne klouzat a k datum se nedostane? Je to sifrovani celeho HDD - bod 1 - nejlepsi volba nebo je lepsi neco jineho? Pro nejvetsi bezpecnost myslim ze je to nejlepsi, protoze pri sifrovani jen uzivatelskych dat a nesifrovanem zbytku muze utocnik podstrcit do / nejakeho skudce nebo vycist data z konfiguraku systemu, nebo vytahnout nejaka dulezita data co zbyla ze swapu. Co myslite vy?
Potrebuji se zeptat, cetl jsem ruzne clanky, psalo se, ze pokud uzivatel u vsech 4 druhu sifrovani nezapomene heslo (coz je ale jeho vlastni blbost za kterou zadna technologie nemuze a odmena za tuto jeho blbost je mu ztrata zasifrovanych dat), ze sifrovani funguje OK a vicemene bezproblemove a relativne spolehlive z hlediska funkce, spolehlivosti i odolnosti vuci nabouravani vc. brute force utoku. Je to pravda?
Taky jsem ale cetl, ze pokud dojde k sebedrobnejsi chybe HW a nebo SW, ktera by u nesifrovanych disku/oddilu/adresaru mela jen drobne nasledky (1 necitelny soubor nebo jen jeho mala cast necitelna) nebo zadne nasledky (vse citelne), tak na sifrovanych discich/oddilech/slozkach muze dojít k extremne velkym az neopravitelnym problemum - napr. poskozeny nebo necitelny nebo nedesifrovatelny cely disk, cely oddil, nekolik adresaru nebo rozsahla cast disku nebo oddilu a ze tyto problemy casto nejsou schopny opravit a data desifrovat a zachranit ani profi laboratore. Ze dalsi extremne velke az neresitelne problemy pristupu k datum muzou nastat v pripade 1, 2, 3 v pripade potreby precist disk v jinem PC klidne i s Linuxem toho sameho distra a verze (napr. kdyz puvodni PC odejde), nebo pri 1, 2, 3 pri preinstalaci Linuxu v / a snaze zachovat uzivatelska data v /home (pripadne jinych datovych oddilech pokud jsou) nebo pri snaze o obnoveni omylem smazanych a jeste nicim neprepsanych dat. Do jake miry je to pravda, ze sifrovana data jsou na poskozeni daleko nachylnejsi nez nesifrovana?
Budu radsi kdyz to budu vedet vsechno jeste pred instalaci a podle toho se budu moct rozhodnout a spravne stanovit pomer soukromi vs spolehlivost pristupu, nez kdyz se do neceho pustim a pak vinou drobne HW nebo SW chyby nebo nekompatibility, coz se muze stat vzdycky, prijdu nenavratne o vsechna dukezita data.
Moc dekuji za vase vysvetleni a nazory k tematu.

Odpovědi

[Jendа]

https://forum.root.cz/index.php?topic=20621.msg305018;topicseen

Co je tohle za módu crosspostovat současně?

[lertimir]

Na rootu už má odpověď a v zásadě správnou takže se s tím nemusíme zabývat.

[Pavel 'TIGER' Růžička]

Myslím si, že to dělá identický člověk, a kdo ví, třeba má poruchu osobnosti.

[PetebLazar]

Nevím zda si tazatel připouští útok na data zaživa, tj. když jsou systému/aplikacím na storage šifrovaná data dostupná v čitelné podobě. Většina dnešních útoků patrně nebude vedena proti off-line storage. Běžící počítač se dá ukrást i včetně UPS a notebook zapnutý s nabitým akumulátorem. Pokud má utočník dostatek času může si počkat na objevení nějaké zranitelnosti (tu využít vůči stále běžícímu od aktualizací odstavenému systému), průměrná doba čekání na zranitelnost by se dnes mohla pohybovat někde v řádu týdnů až měsíců.

[k3dAR]

(za me) urcite sifrovat CELY disk (tedy i pripadne oddelenej /boot i swap) => pomoci LUKS
+ zazalohovat LUKS hlavicku, tim se zajisti ze pripadne poskozeni disku v casti s LUKS neznemozni precist data (udelal by se pak obraz disku a pouzila zaloha hlavicky)
odemceni disku z jineho systemu a/nebo LiveCD/USB je bezproblemova, pouze je potreba aby obsahovalo >=verzi cryptsetup, resp. aby podporovalo pouzite sifrovani

jen strucne k sifrovani jen home pomoci ecryptfs, nepouzivam ale co sem zahledl ma nejake zranitelnosti a zaroven z podstaty nesifrovaneho swapu nepovazuju za vhodne reseni...

[Josef Kufner]

Na Debianu jsem nedávno dokonvergoval k nešifrovanému EFI oddílu, kde mám nesifrované jádro se zapečeným initrd a podepsané vlastními klíči pro Secure Boot (pomocí sicherboot). Žádný Grub, bootuju rovnou jádro z EFI, ale sicherboot udržuje konfiguraci systemd-boot, což funguje taky dobře. Zbytek disku je pak šifrované LVM s / a swapem tak, jak to dělá instalátor.

[lertimir]

Na archu mám zašifrované vše i boot a buduje GRUB2 s crypt modulem. Na openSuse manželky je standardní boot, který bootuje z UEFI do GRUB2 a pak do suse nešifrováno nic. A grub je tam proto, že umožňuje efektivní a jednoduchý boot libovolného existujícího snapshotu btrfs root.

[lertimir]

velmi zajímavá záměna (bootuje na buduje) , je vidět, má mysl je více u rekonstrukce koupelny.

[Josef Kufner]

No vidíš, já /boot nepoužívám (tedy až na to, že to je v podstatě dočasný adresář při aktualizacích). Jestli je nešifrovaný Grub nebo jádro je úplně jedno. Podstatné je, aby to nešlo snadno vyměnit za něco ošklivého, což efektivně znamená, že tam cheme mít jednu podepsanou EFI binárku, která nepoužívá žádné další soubory.

[lertimir]

jak řešíš zpětné snapshoty? já mám tak cca 8 zpětných snapshotů, vždy se vyrobí před a po aktualizaci asamozřejmě mají různá jádra jak ty aktualizace probíhají. Arch toho má hodně openSUSE méně.

[Josef Kufner]

Nijak.

Ještě se mi snad nestalo, že by staré jádro se starým initrd nenabootovalo nový systém, či naopak. Teda, kdysi dávno jednou jo... přecházelo se na systemd a stará jádra neměla podporu cgroups, ale to je hodně specifická výjimka. Typicky si nechávám jedno nebo dvě starší osvědčená jádra i se starším initrd pro případ, že bych to aktuální rozvrtal.

O snapshotech systému jsem už párkrát uvažoval a přijde mi to jako dobrý nápad, ale ještě jsem se nesetkal s dostatečnou motivací. Debian je při aktualizacích dostatečně spolehlivý.

[marbu]

+1 šifrovat celý disk, zálohovat LUKS hlavičku a zálohovat data na disku ...