Fórum Root.cz
Hlavní témata => Distribuce => Téma založeno: the poloprdoch 12. 07. 2015, 19:08:52
-
Pochvalen bud pan Jezis Kristus,
Existuje nejaky setup nejake dobre spravovane linuxove distribuce, kdy start probiha z usb flasky, ale pak system bezi ze zasifrovaneho vnitrniho mirroru, takze flashku lze vyjmout (do pristiho restartu), pricemz vnitrni disky jsou zasifrovane od prvniho sektoru do posledniho, takze bez flashky neni mozne system nejn nastartovat, ale ani (po)zmenit cokoli na discich?
Tim myslim setup, ktery zvladne i stredne zdatny poloprdoch a aktualizace spravce distribuce zustanou funkcni.
PS TPM neni k dispozici
Cest vasi praci soudruzi!
-
A je nutné tu flashku za chodu odpojovat? Co by se pak mělo stát – měl by systém plynule přejít do režimu pouze pro čtení? Nebo by se po opětovném připojení měl synchronizovat?
Nevím o tom, že by to někde bylo jako předvolba nebo dokonce výchozí chování, ale neměl by být problém si to v běžné distribuci (např. ubuntu/kubuntu, fedora, suse) naklikat při instalaci – nastavíš si RAID a nad ním šifrovaný oddíl (a v něm třeba LVM nebo rovnou souborový systém) + /boot dáš jen na flashku.
Ale spíš bych se na RAID vykašlal a udělal to jinak:
- disk: celý šifrovaný a na něm data a swap
- flashka (nebo externí disk): nešifrovaný /boot + šifrovaný oddíl a na něm zálohy dat
Když použiješ Btrfs, tak můžeš zálohovat (rsyncem), jak často chceš, a nebude to zabírat skoro žádné místo navíc (u snapshotů se ukládají se jen rozdíly). Zatímco u RAIDu bys měl jen zálohu poslední verze.
Nicméně nezapomínej, že když dáš počítač z ruky, stále tu nějaká rizika jsou (i když je to dost dobré řešení oproti ostatním). Útočník ti může do počítače nainstalovat HW keylogger nebo upravit BIOS/UEFI, aby ukradl heslo k disku nebo rovnou data.
-
Nicméně nezapomínej, že když dáš počítač z ruky, stále tu nějaká rizika jsou (i když je to dost dobré řešení oproti ostatním). Útočník ti může do počítače nainstalovat HW keylogger nebo upravit BIOS/UEFI, aby ukradl heslo k disku nebo rovnou data.
Anebo provede velmi jednoduchý a rychlý cold boot attack (https://en.wikipedia.org/wiki/Cold_boot_attack) a heslo vytáhne z paměti.
-
Anebo provede velmi jednoduchý a rychlý cold boot attack (https://en.wikipedia.org/wiki/Cold_boot_attack) a heslo vytáhne z paměti.
Proc bych neco tak zbytecne sloziteho mel delat? Sejmu ho baseballkou zezadu pres palici a vezmu si flasku, ne? Ale na to jsem se neptal.
-
A je nutné tu flashku za chodu odpojovat? Co by se pak mělo stát – měl by systém plynule přejít do režimu pouze pro čtení? Nebo by se po opětovném připojení měl synchronizovat?
Flasku bych rad mel u sebe. Kbyby tam byla nutna pro beh, nemohl bych odejit. Nechci se chranit pred tlupou profesoru z MIT ani pred vladou. Jen pred ruznymi vykuky, co jim z googlu vypadne neco zajimaveho.
Prijde mi, ze mit na flashce nejaky zavadec desifrujici /boot a uloziste klicu uz prece musel nekdo vymyslet. Nic, co by se muselo aktualizovat casteji nez BIOS.
-
A neslo by se poohlednout po uplne normalnim distru s instalatorem, ktery podporuje full disk enryption a pri instalai strcit /boot na tu flasku?
-
Mozna tady: http://ubuntuforums.org/showthread.php?t=949870
-
prodávají se i flesky s hw klavesnici pro kod,
jinak /boot nikdy nezasifrujes a je to také naprosto zbytečné nota bene když ho budeš mít na flesce
-
/boot muze byt na libovolnem filesystemu. Podminkou je, aby mu zavadec rozumel. Takze otazkou pouze je, zda uz nekdo nejaky gencrub+ napsal :)
Mit /boot na flashce neni predmetem dotazu.
Dik
-
Nicméně nezapomínej, že když dáš počítač z ruky, stále tu nějaká rizika jsou (i když je to dost dobré řešení oproti ostatním). Útočník ti může do počítače nainstalovat HW keylogger nebo upravit BIOS/UEFI, aby ukradl heslo k disku nebo rovnou data.
Anebo provede velmi jednoduchý a rychlý cold boot attack (https://en.wikipedia.org/wiki/Cold_boot_attack) a heslo vytáhne z paměti.
Pokud uz budu resit fyzickej utok, tak samosebou mam case s detekci otevreni (a to nejen nejakym cumprdlikem, ale minimalne nejakou mrizkou po celym krytu), takze jakmile nekdo narusi integritu, prvni co se stane je likvidace klice.
-
Mit /boot na flashce neni predmetem dotazu.
Pak jsem nepochopil dotaz. Co tedy mělo znamenat "start probiha z usb flasky, ale pak system bezi ze zasifrovaneho vnitrniho mirroru"?
-
V BIOSu je nastaveno, ze se startuje z flashky, zavadec (~ grub ci lilo...) je na flashce (i s klicem), vnitrni disky nemusi mit zadny oddil aktivni, ani na vnitrnich discich neni (jiny/puvodni) zavadec.
-
normalni instalace napr. Xubuntu 14.04 LTS... pri instalaci zaskrtnou sifrovani disku a zavadec instalovat na USB Flash, nasledne po restartu vygenerovat klic na USB Flash, ten sparovat s HDD sifrovanim... po vytazeni USB Flash pak ale logicky nemuze fungovat uspesne aktualizace pri aktualizovani grub a/nebo jadra, tim ze nechces aby na HDD byl jiny/puvodni zavadec (jadro se sice aktualizuje ale nasledne volani update-grub v ramci procesu aktualizace zkolabuje, kdyz bude grub a jeho config na vytazenem USB)...
tedy otazka jestli potrebujes nutne zavadec na USBFlash, jestli by nebylo resenim na USBFlash mit pouze klic k HDD, na HDD pak zavadec (grub) i s jeho konfiguraci, a pri startu z HDD by bylo zadavano rucne heslo pro desifrovani (HDD by byl nepristupny i z LiveCD) a v pripade vsunute USBFlash by nebyl dotaz na heslo, ale pouzilo by se automaticky keyfile z USB...
samotny dotaz na heslo (po uspesnem odzkouseni ze funguje keyfile z usb) by sel take odstranit...
tedy pokud otazka znela, lze toto udelat na "jedno tuknuti", tak ne, ale neni k tomu potreba vynalezat kolo, jen se naucit upravit trosku vyplet ;)
-
Nevim to jiste, ale nemyslim si, ze se pri updatu jadra aktualizuje i bootsrap kod. Konfigurace grubu je ulozena v /boot/grub, coz by prave melo byt zasifrovane na disku (bezici system by /boot videl uz desifrovany). Update grubu (ktery neni zdaleka tak casty) by mohl pripadnou aktualizaci bootstrap kodu nahravat do /dev/null, pripadne nekam do souboru v /boot (protoze pro start systemu v tomhle pripade stejne neni treba). Ale klidne i na disk, stejne se z toho nebude dat nastrtovat a taky by zavadec na flashce mohl preventivne bootstrap kod na vnitrnich discich pro jistotu prubezne kontrolovat a zneplatnovat (protoze teoreticky jedine tam muze byt neco infikovaneho, co si sahne na flashku)
Pokud BIOS bude spoustet neco z vnitrnich disku, co se bude ptat na klic/heslo, vzdycky tam muze nejaky vykuk nahrat neco stazeneho z netu, co si ten klic/heslo nekam poznamena nebo podobne. Infekci v BIOSu nepredpokladam (jedna vec je upravit neco na disku a uplne jina upravit BIOS nejake zakladni desky). Jak uz jsem psal tripismenkove agentury a bostonske profesory zanedbavam.
-
V BIOSu je nastaveno, ze se startuje z flashky, zavadec (~ grub ci lilo...) je na flashce (i s klicem), vnitrni disky nemusi mit zadny oddil aktivni, ani na vnitrnich discich neni (jiny/puvodni) zavadec.
Pokud by ti nevadilo že na flashce bude kromě zavaděče i kernel a initramdisk, tak je to přece přesně ono.
Nevim to jiste, ale nemyslim si, ze se pri updatu jadra aktualizuje i bootsrap kod.
Ne. Maximálně se aktualizuje konfigurace zavaděče pokud se nový kernel jmenuje jinak.
-
A pokud ti jde o pakárnu s updatem, tak na flashce můžeš mít systém, který disk odemkne, a potom spustí nový kernel z šifrovaného disku pomocí kexec.
-
ok, dik, tohle zkusim pogoogit
-
Nebo jestli mas nejaky odkaz? Dik
-
Odbočka
Pánové nechci rušit, chci nabídnout ;) ... V PCBSD (a možná/jistě i jinde...) je možnost zašifrovat CELÝ disk a dokud nezadám správné heslo a nerozešifruje si to (co?celý disk sectory), tak mě to nepustí (pokud se nepletu) narozdíl od jiných distrubucí, OS apd. ani do grubu / dál. Co vy na to?
-
Odbočka
Pánové nechci rušit, chci nabídnout ;) ... V PCBSD (a možná/jistě i jinde...) je možnost zašifrovat CELÝ disk a dokud nezadám správné heslo a nerozešifruje si to (co?celý disk sectory), tak mě to nepustí (pokud se nepletu) narozdíl od jiných distrubucí, OS apd. ani do grubu / dál. Co vy na to?
A jak to funguje? Napadá mě jenom že by tam byl jejich vlastní zavaděč. A tím jsme přesunuli problém z "jak zabezpečit GRUB" na "jak zabezpečit jejich zavaděč".
-
Funguje ;) "kouzlem" (nebo nějakým kozlem :D). Asi bych se měl na to podívat když tvrdí, že je disk od prvního po poslední sektor šifrovaný ... Klíčové slovo GELI
https://en.wikipedia.org/wiki/Geli_%28software%29 (https://en.wikipedia.org/wiki/Geli_%28software%29) a třeba ještě http://blog.pcbsd.org/2015/03/a-look-at-the-upcoming-features-for-10-1-2/ (http://blog.pcbsd.org/2015/03/a-look-at-the-upcoming-features-for-10-1-2/) Ale vlastně nevím, co = jakou bezpečnost zakladatel vlákna hledá...
-
Mit /boot na flashce neni predmetem dotazu.
Pak jsem nepochopil dotaz. Co tedy mělo znamenat "start probiha z usb flasky, ale pak system bezi ze zasifrovaneho vnitrniho mirroru"?
dotaz je zrejme na zpusob zvany chainloader, kdo pamatuje jeste lilo. s tim, ze prvni chain je na flashce a obsahuje crypto kanal predavani informaci k druhemu v chainu.
-
Nevim to jiste, ale nemyslim si, ze se pri updatu jadra aktualizuje i bootsrap kod. Konfigurace grubu je ulozena v /boot/grub, coz by prave melo byt zasifrovane na disku (bezici system by /boot videl uz desifrovany). Update grubu (ktery neni zdaleka tak casty) by mohl pripadnou aktualizaci bootstrap kodu nahravat do /dev/null, pripadne nekam do souboru v /boot (protoze pro start systemu v tomhle pripade stejne neni treba).
pokud jde o odolny system, tak tohle je zrejme nedostatecne reseni.
optimalni kombinace je chainloader s kryptem na flashce.
hardwarovy read only zamek na cmos a bios
po bootu z flashky pripojit desifrovany /boot pockat do vytazeni flashky a po odpojeni pokracovat v bootu z desifrovaneho /boot
pripojit zbytek desifrovaneho systemu a odpojit boot
pokracovat initem
na spravna mista pridat verifikaci integrity
zrejme asi databazi balicku mit jeste na jinem oddilu a ten pripojit pred initem a provest verifikaci a odpojit.
atd atd.
-
dotaz je zrejme na zpusob zvany chainloader, kdo pamatuje jeste lilo. s tim, ze prvni chain je na flashce a obsahuje crypto kanal predavani informaci k druhemu v chainu.
Dobře, a v čem je to lepší než mít na flashce celý /boot? Asi kvůli updatům. A mít na flashce systém s kexec?
Klíčové slovo GELI
https://en.wikipedia.org/wiki/Geli_%28software%29 (https://en.wikipedia.org/wiki/Geli_%28software%29) a třeba ještě http://blog.pcbsd.org/2015/03/a-look-at-the-upcoming-features-for-10-1-2/ (http://blog.pcbsd.org/2015/03/a-look-at-the-upcoming-features-for-10-1-2/)
První odkaz popisuje něco jako cryptsetup na Linuxu. Druhý odkaz nepíše o full disk encryption.
-
dotaz je zrejme na zpusob zvany chainloader, kdo pamatuje jeste lilo. s tim, ze prvni chain je na flashce a obsahuje crypto kanal predavani informaci k druhemu v chainu.
Dobře, a v čem je to lepší než mít na flashce celý /boot? Asi kvůli updatům. A mít na flashce systém s kexec?
Klíčové slovo GELI
https://en.wikipedia.org/wiki/Geli_%28software%29 (https://en.wikipedia.org/wiki/Geli_%28software%29) a třeba ještě http://blog.pcbsd.org/2015/03/a-look-at-the-upcoming-features-for-10-1-2/ (http://blog.pcbsd.org/2015/03/a-look-at-the-upcoming-features-for-10-1-2/)
První odkaz popisuje něco jako cryptsetup na Linuxu. Druhý odkaz nepíše o full disk encryption.
Takže se omlouvám za dezinformaci. Grub naběhne jako první, uvítá a zeptá se na heslo: "Attempting to decptrypt master key ... Enter passphrase for ..." Je možné, že to je v linuxu stejné/podobné jako cryptsetup - to jsem si ještě nezkoušel. Doporučuji si projet jejich pěkný obrázkový názorný průvodce instalací, kde píší píší o "full disk encryption..." viz. http://www.linuxbsdos.com/2014/11/27/how-to-configure-full-disk-encryption-in-pc-bsd-10-1/ (http://www.linuxbsdos.com/2014/11/27/how-to-configure-full-disk-encryption-in-pc-bsd-10-1/) a mechanismus/klíčové slovo je GELI
-
Nicméně nezapomínej, že když dáš počítač z ruky, stále tu nějaká rizika jsou (i když je to dost dobré řešení oproti ostatním). Útočník ti může do počítače nainstalovat HW keylogger nebo upravit BIOS/UEFI, aby ukradl heslo k disku nebo rovnou data.
Anebo provede velmi jednoduchý a rychlý cold boot attack (https://en.wikipedia.org/wiki/Cold_boot_attack) a heslo vytáhne z paměti.
Pokud uz budu resit fyzickej utok, tak samosebou mam case s detekci otevreni (a to nejen nejakym cumprdlikem, ale minimalne nejakou mrizkou po celym krytu), takze jakmile nekdo narusi integritu, prvni co se stane je likvidace klice.
Stačí nejdřív odpojit proud a až potom otevřít case a chladit paměti. I kdyby nevytáhli klíč přesně, přibližná podoba klíče je více než dostatečná pro následný brute-force.
-
Stačí nejdřív odpojit proud a až potom otevřít case a chladit paměti. I kdyby nevytáhli klíč přesně, přibližná podoba klíče je více než dostatečná pro následný brute-force.
Nelze držet klíč jen v registrech/cachi procesoru?
-
Stačí nejdřív odpojit proud a až potom otevřít case a chladit paměti. I kdyby nevytáhli klíč přesně, přibližná podoba klíče je více než dostatečná pro následný brute-force.
A už se to někomu povedlo s DDR3/DDR4? Četl jsem že mají buňky tak malé, že to není prakticky realizovatelné ani s chlazením předem, natož pak vypnout za tepla a až pak otevřít case. https://brmlab.cz/pipermail/brmlab/2014-December/007864.html
Spíš bych se bál o nějaké obejití case-open detekce a následné připojení zařízení do PCIe, které si vynutí DMA přístup. Nebo o crashnutí kernelu pomocí USB zařízení (povedlo se mi omylem) po kterém zůstane viset, ale mechanismus na detekci už nefunguje.
-
Nelze držet klíč jen v registrech/cachi procesoru?
Teoreticky, praktická a ověřená implementace ale AFAIK zatím není. Spíš se to řeší pomocí TPM (OP ale uváděl, že jej nemá).
A už se to někomu povedlo s DDR3/DDR4? Četl jsem že mají buňky tak malé, že to není prakticky realizovatelné ani s chlazením předem, natož pak vypnout za tepla a až pak otevřít case. https://brmlab.cz/pipermail/brmlab/2014-December/007864.html
Hmm, tohle je hodně zajímavé. Ale na konci se tam píše, že není jasné, jestli za to může konstrukce DDR3, což by obejít nešlo, nebo řadič, což by teoreticky obejít šlo.
Pořád to ale jde obejít při vyvolání panic resetu (pokud je nastaven — na serverech bývá, aby při kernel panic nikdo nemusel jezdit do serverovny), protože to je warn boot, nicméně je to samozřejmě o dost složitější.
Spíš bych se bál o nějaké obejití case-open detekce a následné připojení zařízení do PCIe, které si vynutí DMA přístup. Nebo o crashnutí kernelu pomocí USB zařízení (povedlo se mi omylem) po kterém zůstane viset, ale mechanismus na detekci už nefunguje.
Anebo pomocí FireWire či Thunderboltu, pokud tam jsou, prostě přečíst celou paměť :)
-
Odbočka
Pánové nechci rušit, chci nabídnout ;) ... V PCBSD (a možná/jistě i jinde...) je možnost zašifrovat CELÝ disk a dokud nezadám správné heslo a nerozešifruje si to (co?celý disk sectory), tak mě to nepustí (pokud se nepletu) narozdíl od jiných distrubucí, OS apd. ani do grubu / dál. Co vy na to?
Že se pleteš :) Pokud myslíš geli, tak to je kernel modul, který se musí natáhnout z disku, který tímpádem nesmí být šifrovaný. Čili máš nešifrovanou partition, kde je /boot. Pokud myslíš nějaký jiný způsob, tak by to chtělo link...
S GPT by to asi nějak implementovat šlo, místo gptzfsboot by se tam nahrál nějaký gptzfscryptoboot, ale nevím o tom, že by to někdo implementoval.
-
Nelze držet klíč jen v registrech/cachi procesoru?
Teoreticky, praktická a ověřená implementace ale AFAIK zatím není. Spíš se to řeší pomocí TPM (OP ale uváděl, že jej nemá).
Jak tohle funguje s šifrovaným filesystémem/blokovým zařízením není náhodou pak ten klíč také v paměti? Přece přes ten TPM nehoním stovky MB/s z/na disk ne? Nebo musím spoléhat na HW šifrování disku?
-
Jak tohle funguje s šifrovaným filesystémem/blokovým zařízením není náhodou pak ten klíč také v paměti? Přece přes ten TPM nehoním stovky MB/s z/na disk ne? Nebo musím spoléhat na HW šifrování disku?
U TPM stačí klíč zašifrovat správným stavem systému. Pokud najede kompromitovaný systém, klíč nerozšifruje.
-
Jak tohle funguje s šifrovaným filesystémem/blokovým zařízením není náhodou pak ten klíč také v paměti? Přece přes ten TPM nehoním stovky MB/s z/na disk ne? Nebo musím spoléhat na HW šifrování disku?
U TPM stačí klíč zašifrovat správným stavem systému. Pokud najede kompromitovaný systém, klíč nerozšifruje.
To chápu. Mě zajímá, ale použití TPM při cold boot útoku nebo při dumpu paměti skrz DMA.
-
To chápu. Mě zajímá, ale použití TPM při cold boot útoku nebo při dumpu paměti skrz DMA.
Proti tomu TPM nijak nepomůže, není na to designovaný. http://superuser.com/questions/566114/full-disk-encryption-with-tpm-not-subject-to-cold-boot-attack