Dotaz: arch sifrovany

[tom]

Příloha:

• ArchEncrypt.png (97447 bytů)

Dobry den,

Snazim sa z ucebnych dovodov nainstalovat vo virtualboxe plne sifrovany Arch vratane /boot.Postupoval som podla nasledujuceho navodu >

https://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/#fn:1

Skusal som aj ine postupy, no po reboote sa zaseknem v grub-rescue.

Neviete poradit ako to vyriesit?Asi to bude nejaka drobnost, ale neviem si rady.

Dakujem

Odpovědi

[Peter Golis]

A dal si načítať tie dva moduly teda?

[Jendа]

grub-install spouštět s -v, podívat se, jaké moduly požaduje po grub-mkimage.

[k3dAR]

sice slo o Debian10, ale mozne ten problem nove verze Grubu mas i v Archu, zkoukni tohle, pripadne zkus zda to odemknes z Grub Rescue rucne...
jinak howto od Pavel Kogan povazuju za spravne, opet sem sice pouzil jen jeho novejsi zapisek pro *buntu/Mint, ale aspon o sem videl tak jine navody (i pro Arch(vcetne ArchWiki)) z jeho zapisku (=tvuj link) vychazeji... jedine nejake ty zmeny novych verzi (napr. ten Grub)

[Andrej]

Co takhle podívat se do howto speciálně pro Arch? Nějaká stránka z roku 2014 nemusí vůbec odpovídat dnešní realitě.

Máš tam nainstalované potřebné moduly? Nezapomněl jsi na GRUB_ENABLE_CRYPTODISK=y v /etc/default/grub nebo něco takového? Generuješ /boot/(efi/)?grub/grub.cfg automaticky, nebo se ho snažíš nějak sesmolit ručně?

Na všech mých strojích se GRUB k šifrovanému filesystému dostává přibližně takto:

insmod part_gpt
insmod cryptodisk
insmod luks
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha256
insmod btrfs
cryptomount -u <magické číslo>
set root='cryptouuid/<magické číslo>'

To magické číslo je UUID příslušného LUKS oddílu, zapsané bez pomlček. Je to totéž UUID, které máš například v /etc/crypttab pro ten oddíl. Nebo se dá zjistit pomocí blkid, lsblk -f a podobných příkazů.

Ale bacha, je tam pár nepříjemností, se kterými musíš počítat:

• GRUB zatím nepodporuje LUKS2. Aby to fungovalo, musí to být původní LUKS. To není žádný zásadní problém a původní LUKS bude ještě dlouho podporovaný. Jenom je potřeba o tom vědět a nesnažit se v cryptsetup luksFormat o nějaké super hyper moderní nastavení. LUKS2 je bezva, řeší spoustu nedostatků původního LUKS, ale prostě teď v tuhle chvíli ho GRUB ještě nedovede číst.
• Pozor na --iter-time! To je parametr cryptsetup, který se zadává u luksFormat a luksAddKey. Nechce se mi zacházet do podrobností, co dělá, takže stručně: Delší --iter-time znamená lepší zabezpečení v případě slabého hesla, ale odpovídajícím způsobem delší dobu pro dešifrování master klíče. Proč to u GRUBu vadí a jinde ne? Protože GRUB nepoužívá hardwarovou akceleraci šifrování (AES-NI). Takže něco, co se později v userspace spočítá třeba za sekundu, může v GRUBu trvat třeba 10 sekund. A GRUB má pevně stanovený timeout pro odemčení LUKS slotu, který je kolem 10–15 sekund nebo tak. Takže na běžném slabém notebookovém procesoru (a ve virtualizaci také!) se může klidně stát, že GRUB nestihne vypočítat master klíč do vypršení té své interní lhůty a prostě to vzdá.
  • Co s tím? Nepoužívat --iter-time 2000, který je momentálně implicitní, ale zkusit třeba starší implicitní volbu 500. Se silným heslem nebo s náhodným dlouhým klíčem v souboru to nemá absolutně žádný vliv na bezpečnost. Se slabým heslem je to samozřejmě jiná věc.
  • Jak změnit --iter-time u již existujícího LUKS oddílu? To lze pomocí luksAddKey, luksKillSlot a luksDump (pro výpis seznamu slotů). Pozor, doba potřebná pro dešifrování master klíče disku se řídí podle slotu s nejdelším --iter-time. Takže --iter-time je třeba zkrátit všude; jinými slovy, je třeba napřed přidat pomocí luksAddKey sloty s kratším --iter-time (a se stejnými hesly nebo klíči, které už tam jednou jsou) a poté pomocí luksKillSlot odstranit původní sloty s delším --iter-time. Jinak se GRUB toho master klíče nedobere včas.

[k3dAR]

Jak sem psal, z tveho linku:

Instructions at Pavel Kogan's blog show how to encrypt the /boot partition while keeping it on the main LUKS partition when using GRUB

Postup na ArchWiki vidim totoznej, jen klic v /root a Kogan v / s tim ze mu nastavuje 000, a jeste vidim druhej rozdil ze v mkinitcpio.conf ma ArchWiki cestu v zavorce...

[Andrej]

Závorka podle mě nehraje roli. Je to Bash a ten skript, který to celé interpretuje, je uzpůsobený tak, že se dají používat jak pole, tak i tokeny ve stringu. Konkrétně je tam toto (tedy všechno nakonec skončí jako pole):

arrayize_config() {
    set -f
    [[ ${MODULES@a} != *a* ]] && MODULES=($MODULES)
    [[ ${BINARIES@a} != *a* ]] && BINARIES=($BINARIES)
    [[ ${FILES@a} != *a* ]] && FILES=($FILES)
    [[ ${HOOKS@a} != *a* ]] && HOOKS=($HOOKS)
    [[ ${COMPRESSION_OPTIONS@a} != *a* ]] && COMPRESSION_OPTIONS=($COMPRESSION_OPTIONS)
    set +f
}

Jinak ta zmínka o /boot partition je silně zavádějící; nemá žádný smysl mít oddělený /boot oddíl a na svých strojích nic takového nemám. K takovému dělení není důvod a ušetří to navíc obrovskou spoustu vrásek třeba v situaci, kdy se chrootnu do kořenového oddílu, chci tam něco poupravit — třeba po změně typu virtualizačního kontejneru nebo tak — a zapomenu namountovat ten /boot, protože jsem zvyklý na x-systemd.automount, který v chrootu nenastane. Inu, bez odděleného /boot oddílu celý tento nesmysl odpadá a bootuje se z běžného "hlavního" filesystému.

[tom]

Dakujem pani,

Na Wiki stranke sa pise,ze je podporovany len LUKS1-teda stary.Luks2 este nie je podporovany.Skusil som pri vytvarani particie zadat --type luks1 a znovu nainstaloval.A zda sa,ze to ide, musim sice 2x zadavat heslo, ale to nevadi.Este si instalaciu zopakujem aspon 2x aspon aby som sa lepsie zorientoval. Este raz dakujem.

[k3dAR]

spis si jeste 2x precti ten tvuj link, protoze tam samozrejme resi i to aby jsi zadaval heslo jen 1x do Grubu...
to ze ho zadavas 2x je to ze system uz nevi, ze jsi to predtim odemknul (resp. natazene jadro uz to odemcene zas nema), a druhe zadavani LUKS hesla je do initramdisku, to se prave obejte tim, ze pripravis keyfile, pridas ho do LUKS slotu jako dalsi "klic" a nastavis aby initramdisk timto keyfilem odemykal automaticky... celej postup tam je, bud si vynechal celou cast o keyfile, nebo treba jen jednu vec z ni a proto to po tobe chce to druhe heslo

[tom]

Ja viem, cital som to dokonca.S tym klucom to skusim neskor.Teraz mi islo hlavne o to sifrovanie. Este raz dakujem, ak budu problemy ozvem sa.

[Andrej]

S heslem není žádný velký problém. LUKS kontejner má (jestli se nepletu) nějakých 8 slotů a v každém může být heslo nebo klíč. Aby se heslo zadávalo jenom jednou, stačí využít 2 sloty a princip je tento:

1. Vytvoří se dva sloty, jeden s heslem (při vytváření LUKS oddílu), druhý s klíčem ze souboru (pomocí luksAddKey).
2. Soubor s klíčem se uloží někam do adresáře /root nebo zkrátka tam, kam běžní uživatelé příliš nemůžou.
3. Do /etc/crypttab se přidá záznam, který odemyká příslušný LUKS oddíl pomocí toho souboru s klíčem, tedy bez nutnosti interakce s uživatelem.
4. Soubor s klíčem se přidá do initcpio (a pochopitelně skončí ve stejném adresáři, v jakém je na běžném filesystému).
5. Pak stačí zkontrolovat, jestli soubor s klíčem i /etc/crypttab jsou v initcpio archivu a jestli náhodou initcpio archiv není čitelný pro někoho jiného než roota.
6. A nezapomenout přidat sd-encrypt do pole HOOKS v /etc/mkinitcpio.conf; typy a pořadí hooků jsou popsané zde. Právě tento hook zajišťuje přidání programu cryptsetup a souboru /etc/crypttab. Soubor s klíčem je třeba přidat ručně v poli FILES.

Bootování funguje takto:

1. GRUB se zeptá uživatele na heslo.
2. GRUB z šifrovaného hlavního oddílu rozluští master klíč, pak dešifruje a načte kernel a jeho initcpio.
3. Kernel začne bootovat se svým initcpio filesystémem v RAM, kde najde /etc/crypttab a také soubor s klíčem.
4. Během initcpio fáze se hook sd-encrypt postará — na základě souboru s klíčem a /etc/crypttab, které jsou v initcpio dostupné — o regulérní otevření LUKS oddílu kernelem, aby se objevil v /dev/mapper/<zařyzeňy>.
5. Kernel (resp. systemd v tom initramdisku) je pak schopen podle UUID filesystému (které je už známé, protože LUKS kontejner je otevřený a filesystém v něm je vidět) namountovat kořenový filesystém, přemountovat z initcpio na běžný filesystém a je vyhráno.

Není to žádná věda; jen je třeba mít jasno v tom, co se tam děje a kde a proč.

[lertimir]

No, nejsem si jistý, jak to s použitím záznamu v /etc/crypttab je. V Archu píší, že se crypttab čte až systém nabootuje (druhý odstavec). A v tvém odkazu na Arch hned následující část popisuje, že klíč dáš do konfigurace mkinitcpio a do příkazové řádky grubu. Já mám v /etc/cryptab pouze další disky ne root oddíl.

[Andrej]

Klíč v příkazové řádce GRUBu nemám.

Tady jsou detaily o crypttab.

[tom]

Dobry vecer,

Rad by som si nainstaloval sifrovane niekolko distribucii.Chcem sa spytat,ci je mozne zdielanie swap particie medzi niekolkymi linuxami. Cital som,ze by to mohlo sposobit chaos,ak by bol jeden linux hibernovany a zaroven by nabehol iny,druhy linux?

Za odpovede dakujem.

[k3dAR]

nezavisle na sifrovani, sdilet swap mezi distribucema POKUD je chces hibernovat je urcite blbost, ani me to nikdy nenapadlo zkouset, tak nevim zda by system poznal ze to neni jeho hibernace a smazal ji, nebo zda by se pokousel o obnovu coz by zkolobavalo...
pokud bys nechtel hibernovat, tak "sdilet" swap neni problem...

[Andrej]

Chcem sa spytat,ci je mozne zdielanie swap particie medzi niekolkymi linuxami.

Toto jsou dva nesmysly v jednom.

1. Máme rok 2019. Swap je soubor, ne oddíl. Oddíl to byl v minulém desetiletí, když ještě většina souborových systémů neuměla swapovací soubory. Nevýhoda oddílu je, nepříliš překvapivě, že místo je vyčleněné předem a nedá se využít k jiným účelům, když se swap nepoužívá.
2. Swap určený k původnímu účelu (tedy k jinému než uspávání počítače) je úplně passé a zbytečný. Pokud máš pocit, že potřebuješ swap, kup si místo toho víc RAM. Pokud máš stále pocit, že potřegbuješ swap, asi něco děláš špatně. Jasně, můžeš mít pro každou distribuci oddělený swapovací soubor, což prináší spoustu flexibility, ale já osobně bych si na jednom filesystému netrofl uspat jednu distribuci a pak ze swapovacího souboru probutit jinou. Jako jo, třeba by to fungovalo, čistě zázrakem, ale zkoušet bych to nechtěl. Nemá to smysl.

[k3dAR]

ad 1. v jeho pripade by to znamenalo ze pro kazdy system bude mit zvlast swapfile, tedy kazdy oddil pro kazdy system bude muset byt pripraven vetsi o pripadnou velikost swapfile (osobne bych si netroufl mit vice systemu na jednom btrfs oddilu)

ad 2. nevim jak swapfile (nepouzivam a mel sem za to ze nelze(tedy asi se to zmenilo) pouzit pro uspani-na-disk), ale s swap oddilama nevim proc by mel byt problem uspat system1 do swap1 a probudit uspanej system2 z swap2... jedine teoreticke problemy co me napadaji by teoreticky stejne tak nastaly kdyz by byl uspanej jen 1 system a na oddil(y) pouzivane tim systemem by se vlezlo napr. z USBLive... tedy ze by byl uspan proces co zapisuje(/stahuje) na disk dlouhej soubor a ja(nebo nejaka aplikace) mu z jineho systemu ten soubor smazal

[lertimir]

Andreji, jen otázka jak to vlastně myslíš. Souhlas s tebou, že na systém patří btrfs, ale na druhou stranu btrfs nemá rádo swap. A také velikost swapu při současných kapacitách medií není tak kritická abych ji nealokoval celou. A také v oddíle mě nikdy nenastane fragmentace (ale souhlas u SSD a NVMe je to jedno).

[k3dAR]

Andrej zije v jinem HW svete, pro jeho 512GB RAM by na 2TB systemovem disku zbytecne zabral 25%... netusi ze normalni clovek ma 8-16GB RAM a vyhrazenej oddil na 256-512GB SSD neni zadnej problem

[lertimir]

No myslím, že by sis měl rozvážit, co vlastně chceš. Připomínky k téhle myšlence:

1. Je naprostá pitomost sdílet cokoliv, swap, systémové oddíly, datové oddíly, pokud jeden ze sdílených systému je hibernován. Sdílený swap je totálka, protože v při hibernaci v něm je obraz operační paměti a pokud se do něj zasáhne hibernovaný systém to z největší pravděpodobností nenajede. Diskové systémy taková hrůza není, protože s pomocí journalovacích FS se z nekonzistentního stavu obvykle dostanou, ale někdy něco nemusí vyjít. Při vypnutí systému dostaneš vše na discích do konzistentního stavu.
2. Swap:
   • je naprosto zbytečný na rotačních discích. Jejich rychlost a seek time jsou při současné kapacitě pamětí nedostatečné. (čistě pro porovnání. V roce 95 pamět u pracovních stanic cca 64MB (u normál PC 2MB) a rychlost SCSI rozhraní a disků cca 10-20MB/s, tedy přenos paměti na disk za cca 4-8sec max, nyní 8GB paměti do rotačního disku při rychlosti 150MB/s dostaneme tak za minutu, nemluvě o tom, že mnoho lidí má mnohem více operační paměti.)
   • V zásadě použití může mít swap na NVMe.
   • Swap na hibernaci může mít smysl na notebooku, ale při současných spotřebách myslím, že zcela stačí uspání do RAM, notebook v uspání do ram spotřebuje tak cca 7-8% baterie za den a mezitím se ke zdroji uživatel dostane.
3. Hrát si s mnoha distribucemi v šifrovaném režimu považuji za zbytečné a spíše škodlivé. Vzhledem k otázkám máš znalostní deficit a v šifrovaném režimu můžeš více věci pokazit. Pokud potřebuješ distribuční turistiku, tak ji udělat na běžné instalaci a pokud navíc mám i nějaké obavy o data, tak třeba zašifrovat /home, nemít swap a /tmp mít v tmpfs na dobu, než se rozhodneš pro distribuci. A po rozhodnutí pro distribuci udělat solidní trvalou instalaci s šifrováním všeho, co potřebuješ. A vždy platí první bezpečnostní zásada: Definovat proti čemu obranu buduji.

[tom]

Ahoj,

Suhlasim, ze sa v tomto moc neorientujem.Len si potvrdil, co som sa docital.Teda,ze je zdielanie jednej swap particie hlupost. Samozrejme si dam poradit. Na jednom PC mam devuan a tam je swapfile, to ma za nasledok, ze uspanie funguje, no hibernacia nie. Ja som videl nejaku prezentaciu p. Celetku a tam bol slide, v ktorom mal rozlozenie asi taketo> Jeden LUKS oddiel a tom niekolko roznych distribucii

[k3dAR]

sdilet swap pro hibernace je nemozne, ale sdilat swap kdyz bys nehibernoval lze...

nezkousel sem, ale tady mas postup pro Debian jak zprovoznit hibernaci s swapfile a to i vcetne toho kdyz je ulozen na sifrovanem oddilu

zalezi na tobe, muzed mit GPT rozdelenej disk kde (krome EFI oddilu a/nebo GRUBLegacy oddilu) budes mit oddil nad kterym bude LUKS, nad nim LVM, v nem lv pro system1, home1, swap1, pak pro system2, home2, swap2 atd.., nevyhoda je ze jakmile ten LUKS odemknes, z tech systemu bude root pristup do vsech ostatnich systemu a/nebo kdyz bys neco s LUKS podelal, ze se nedostanes k zadnemu systemu...
nebo muzes mit oddil LUKS1 (na nem LVM a lv system1, home1, swap1), dalsi oddil s LUKS2 (na nem LVM a lv system2, home2, swap2) atd, vyhoda je opak tech predchozich nevyhod, nevyhoda neni zadna, tedy pokud pouzijes GPT rozdeleni, pokud bys chtel (neni duvod ani pro BIOS/Legacy boot) mit MBR/MSDOS rozdeleni, tak bys tam byl omezen poctem moznych oddilu...

[k3dAR]

ad 1.) sdilet systemove oddily mezi systemama? to by melo jakej vyznam? ze kdyz budu chtit SystemA tak ho budu startovat z OddiluB? sdilet datovej oddil nevim co by bylo za problem, viz

ad 2.) swap na rotacnim disku pro hibernaci neni problem, kdyz by mel tazatel rotacni disk a chtel swap i na odswapovani, pokud by tim nechtel "rozsirit RAM", ale chtel to jako zachranu aby system nezabil procesy kdyz by z nejakeho duvodu dosla RAM ma stale vyznam, sice se pri odswapovani na chvili zasekne, ale pak ma moznost sam zvolit ktere aplikace zavre a neprijit o ty co potrebuje bezet...
(samozrejme nepopiram ze SSD pri dnesnich cenach neni problem poridit (SATAIII 500GB za ~1600))
problem s uspanim do ram je ze LUKS zustava odemcenej, lze to sice obejit ale neni to podporovana vec distrem a nevim zda muzou pri tom (odpojovani rootfs, zamceni luks, prepnuti na rootfs z initramfs pred uspanim) nastat zbytecne problemy, pri uspani na disk (do sifrovaneho swapu) je to bezproblemove...

ad 3.) vice sifrovanych dister neni zbytecne - pokud chce vsechny zkouset/pouzivat, budou ve vsech nejaka osobni data tak proc je nesifrovat vsechny? ani skodlive - pokud by byla obava ze neco podela, neni problem mit pro kazde distro 1 oddil a zvlast LUKS na kazdem, takze nemuze jeden "rozbitej LUKS" ovlivnit dalsi distra...

[lertimir]

Ad 1 ze systému by mohl mít sdílené /etc. A problém s datovým oddílem muže nastat ve chvili kdy má hibernováno a jiný systém s datovým oddílem pracuje. Ad 2. pak jsi to zdůvodnil, že při současných cenách SSD mít cokoliv s brutálním random přístupem na rotačním disku blbost. Ano souhlasím že cold boot attack se na uspaný komp provést dá. Ad 3. Ty vážně si myslíš, že více dister provozovat na jednom hw způsobem tím způsobem, že si s nimi uživatel hraje má smysl šifrovat? Ano pokud šifrování je součásti zkoušení, ale pokud je cilem toho provozování vybrat si distro, které funkcionalitou, správou, repozitáři a UI tazateli vyhovuje tak to celé projít způsobem, kdy otestuji to co považuji za důležité a pak po výbšru provedu konečné nastavení.

[k3dAR]

ad 1) dobre, sdilet etc urcite neni dobrej napad, pokud by to snad nekoho opravdu napadlo
kdyz mi systemA zapisuje na datovy-disk soubor1 a ja ho hibernuju, tak se syncne zapis na disk, pouze nebude soubor zatim celej, kdyz pak pustim systemB a budu pristupovat(cist/zapisovat) na stejnej datovy-disk, nemuzu preci nic ohrozit, dokud by me nenapadlo pristupovat k tomu rozkopirovanemu souboru1 pred hibernovanim systemuA... ale to jake bloky jsou volne/obsazene preci po pro buzeni z hibernace bude systemA resp. filesystem na datovy-disk zjistovat az pri pokracovani zapisu, nema nejakou cache v hibernacnim oddilu/souboru kde by mel zapamatovane jake bloky byli volne pred zacatkem zapisovani, to by znamenalo ze by na datovy-disk nezavisle na (ne/)hibernaci slo zapisovat vzdy jen max 1 soubor najednou

ad 2) zduvodnil sem ze nakup SSD je prirozena volba, pokud ale z jakehokoliv duvodu je stavajici HDD chteno/potreba/nutno/to_je_jedno pouzit, plati co sem psal o nezbytecnosti swapu na rotacnim disku
nejde jen o cold boot attack, muze jit o proste vyuziti diry v sporici/lockeru/sluzby/atd... v tom probuzenem_z_ram/bezizim_systemu/s_odemcenym_luks

ad 3) vazne v tom nevidim problem, naopak nesifrovat vsechny ty distra bych chapal jen v pripade, ze by k tomu sendul doma v patek vecer, a do nedele vecer prosel (treba) 10 dister a jedno si vybral, ale jakmile si bude chtit nainstalovat na NB 10 dister a par mesicu je postupne/na_preskacku skouset, s tim ze samozrejme bude prenaset NB, nekde ho (vypnutej) nechavat, zapinat/vypinat, restartovat do dalsiho systemu podle nalady atd, tak proc to vse nesifrovat? nenapada me jedinej problem kterej by mohl nastat (obzvlast pokud by jak sem psal mel kazdej system svuj vlastni LUKS)

[lertimir]

Ad1. co a kdy se syncne to závisí na aplikaci. Pokud máš rozeditorovaný soubor na aplikaci záleží co má v paměti a kdy zavolá zápis do disku. A když do toho souboru zasáhneš z jiného systému ve chvili kdy je rozeditován tak máš problém, a přiom jsi už mohl na to že máš rozeditováno zapomenout. Nebo jinak řečeno, uřídit to samozřejmě jde, ale klade to vyšší nárok na uživatele. Další věcí je, že ti tam může jet nějaká databáze v uživatelském prostoru. Třeba díky tomu, že uživatel zaškrtl automatickou indexaci. Další vec na sdílení uživatelského prostoru může být neshoda UID, díky tomu, že různá distra začínají uživatelům přiřazovat od jiného základu (potkal jsem kromě obvyklejšího od 1000 i od 500), nebo že udělam jeden virtuál pro přítelkyni, ale zapomenu na to, že když ji udělám jako prvního uživatele bude mít stejné UID jako já v jiném virtuálu.

ad3. No myslím si, že nainstalovat 10 dister není správná cesta na výběr, protože se v tom utopí a na druhou stranu ani cesta mít několik dister pár měsíců je také špatná cesta.

Rozumější mít etapový výběr. 1. jak aktuální chce mít distribuci (od rolling distra až k dlouhé periodě jako debian s 2 lety) 2. jaké grafické prostředí a to lze vyzkoušet na jednom distru. 3 jestli ho přitahuje nějaká specifická věc. např. ubuntu/mint přístup, integrovaný yast v opensuse apod. 4. pokud ještě je ve výběru více než 1-2 distribuce tak rozsah repozitářů. (první krok je čistě intelektuální bez instalace, druhý je skoro jedno na čem se provede. Třetí začne s tím jak mám dobře grafické prostředí integrované do distra a jak se o něj starají.)