Administrace komentářů

…s intel gen6 procesorem…

Cokoliv 4. a novější generace už bude mít AES-NI instrukce, tj. problém s výkonem rozhodně nebude.

Kdyz budu mit LUKS na cely ten velky datovy disk…

Side note: Ten systémový SSD by měl být taky 100% (nebo téměř 100%, musí-li se z něj bootovat) šifrovaný; fakt není důvod to mít jinak. Šifrování brání například modifikaci systému při vypnutém serveru a několika dalším záludnostem, které jsou sice krajně nepravděpodobné, ale když se proti nim lze relativně snadno bránit, pak proč ne…

je ten LUKS stabilni a bezpecny?

Ano.

…(nebo toho bude pulka leaknuta v nesifrovanych logach na tom systemovem disku?)…

A právě proto má být všechno šifrované, systémový disk také (ne-li především).

Predpokladam, ze nutnost zadavat nejaky klic nebo heslo/frazi pri kazdem bootu pred pripojenim datoveho disku.

Dle nastavení. Může to být založené na TPM. Pak to ale chrání jen před ukradením disku, ne před ukradením celého počítače. (A těžko říct, zda lze věřit TPM, pokud jde o NSA backdoory a o spolehlivost, tedy (ne)možnost zálohovat klíče pro případ selhání…) Nebo může být klíč k LUKS na nějakém bootovacím flashdisku, který lze odpojit. Pak musí člověk na ten flashdisk myslet. Nebo to může být asymetrická kryptografie a hardwarový klíč; pokud možno víc klíčů <—> LUKS key slotů pro případ poruchy jednoho.

Nebo je třeba smířit se se zadáváním hesla při bootu. To lze buď vyžadovat lokálně, nebo taky vzdáleně přes SSH. To druhé pomůže, když člověk potřebuje svůj NAS přebootovat z druhého konce světa.

…mozna horsi rychlost.

Propustnost šifrování s AES-NI je někde v řádu jednotek GB/s, v závislosti na typu procesoru, může to být klidně třeba 10 GB/s. Který disk dá řádově 10 GB/s propustnosti? Zkrátka, krk láhve bude rozhodně disk (nebo i SSD, s výjimkou fakt dobrých PCIe modelů), nikoliv procesor.

Tedy, vyšší vytížení procesoru vlivem šifrování tam samozřejmě bude, ale na propustnost by to opravdu (ale opravdu) nemělo mít vliv. Propustnost určuje disk.

Pouziva se to siroce?

LUKS je zkrátka standard, těžko si lze představit něco širšího.

Bude to v pohode s XFS nebo Ext4?

Ne, nebude. Máme rok 2023, disky už nemají 10 GB, spíš mívají klidně 10 TB, takže zastaralé filesystémy nejsou a nebudou v pohodě. Neumí korektně zálohovat přes atomické snapshoty, nechrání před silent data corruption, nemají ani náznak škálovatelnosti (příklad: který z nich dokáže po přidání dalšího disku přetransformovat sám sebe na RAID1 — bez odmountování?) atd.

Kdo to s NASem a se svými daty myslí dobře, volí Btrfs. (Jen tu a tam, kdo velmi dobře ví, co dělá, zvolí možná ZFS, například je-li skalním fanouškem FreeBSD. Leč kdykoliv se někdo ptá, který FS, odpověď je vždy Btrfs.)

Bud jsem uplne blbej, nebo tem lidem, co si to tak nastavi, nedochazi, ze to zcela neguje cely ten duvod proc to delat a je to uplne nesmyslne, je to jako chtit se naucit plavat, a rict, ze to budu delat jen pokud pri tom nebudu mokry nebo ve vode??

Někdy to chce pozorněji číst dokumentaci. Jindy je zas pravda, že špatné dokumentace se na webu povaluje přehršel.

Automatické zadávání klíče při startu (přesněji: odkaz na klíč přímo v /etc/crypttab) má obvykle za cíl, aby se klíč zadával jednou, nikoliv víckrát. Příklad:

1. GRUB se zeptá uživatele na heslo k LUKS.
2. GRUB sám pro sebe vypočítá master key a dokáže tak číst LUKS oddíl.
3. GRUB najde v kořenovém LUKS oddílu souborový systém (kde Btrfs samozřejmě patří mezi podporované).
4. GRUB načte ze souborového systému (uvnitř LUKS) kernel a initramdisk a spustí kernel.
5. Initramdisk má v sobě nešifrovaný klíč k LUKS, který je přístupný během první fáze bootování.
6. Systém (tedy, systemd, udev, cryptsetup a kamarádi) načte během initramdiskové fáze nešifrovaný klíč a otevře jím automaticky (znovu, nezávisle na GRUBu) šifrovaný kořenový oddíl.
7. A normálně se nabootuje a nic už se podruhé na heslo neptá, byť je kořenový oddíl šifrovaný.

Kontrolní otázka, soudruzi: Proč nevadí, že je v initramdisku uložený nešifrovaný klíč k LUKS oddílu? Protože initramdisk samotný je šifrovaný (na šifrovaném oddílu) a musí ho napřed dešifrovat GRUB (na základě hesla od uživatele).

To↑ je základní princip (částečně) automatického odemykání. Pochopitelně to ovšem nebude fungovat, pokud je třeba zadávat heslo skrz SSH. K tomu je potřeba mít nějaký kernel a initramdisk (ne nutně ten finální provozní, ale zkrátka nějaký) v nešifrované podobě, ideálně zabezpečený přes SecureBoot + Sicherboot nebo něco podobného.

Další možnosti jsem zmiňoval výše; tam je třeba volit podle situace a požadavků. (Je stroj fyzicky dobře zabezpečený? Musí být schopen nabootovat bez přítomnosti obsluhy? Musí být schopen nabootovat kdykoliv a hned nebo smí čekat na heslo poskytnuté přes SSH? Je přijatelné, aby ztráta části hardwaru vedla ke ztrátě dat, nebo musí být klíče zálohované?)