Dotaz: sifrovani filesystemu

[Dušan Hokův]

zdar, da se nejak zaridit, aby byl filesystem zasifrovany ( necitelny kdyz vlozim hdd do jineho pc) a to tak, aby napriklad sifra byla primo v bootmanageru nebo treba patchnutem kernelu? Rad bych aby se system po nabootovani spustil bez zadavani nejakeho hesla, ale aby byl zaroven ochranen pred napr. vymazanim rootovskeho hesla v /etc/shadow nebo prectenim startovacich skriptu prave zpusobem, ze cely disk se vlozi do jineho pc a namontuje.

Diky za podnety

Odpovědi

[petr_p]

Podivej se na tohle vlakno z cz.comp.linux.

[Anonym]

Aj ked taketo riesenie je technicky mozne, nema zmysel nad tym rozmyslat, pretoze ak je kluc niekde ulozeny, tak pripadny utocnik ho pri kradezi disku ziska a data pomocou neho desifruje.

[Michal Kubeček]

Přesně tak. Není možné, aby současně byl filesystém chráněn proti přečtení při krádeži a bylo možné nabootovat bez lidské asistence.

[Dušan Hokův]

No ja to spis myslel tak, ze treba nejaky patch do jadra, ze by primo uvnitr pri nastartovani bylo heslo v binarce kernelu nebo nekde schovane uvnitr initrd treba v nejakem patchnutem modulu, cimz by se melo zarucit, ze pokud se nastartuje do normalniho linuxu a tento disk pripoji, neni sance dostat se na takto zasifrovany disk....

[Michal Kubeček]

Ale to je právě k ničemu, je to jako klíč pod rohožkou. Pokud se k tomu heslu má dostat bootloader, dostane se k němu i útočník. Jedině že by to heslo bylo na nějakém médiu (mimo vlastní počítač), u kterého je velká pravděpodobnost, že ho útočník neukradne také.

[AloneInTheDark]

neslo by bootovat z pxe tak, aby po bootu byl image na serveru poskytujici image nedostupny a musel by se "nejak povolit" dalsi boot ? to aby eventuelni utocnik nemohl pomoci ziskat ( napr. zmenou mac na svem stroji ) ten boot image vcetne klice atd. no jak to tak vypada nejjednosussi je asi mit to na usb klici a kopii toho klice v trezoru

[lefti]

to heslo bude muset byt ulozeno mimo sifrovany fs.

[lefti]

Pokud ti jde jen o hesla, tak pouzivej kvalitni sifrovani a nemusis toto resit.

[Michal Kubeček]

???

[lefti]

Nojo, to by nevyresilo pripadnou kompromitaci systemu pri bootu jinyho systemu a nasledne ziskani dat.

[gat.centrum]

To co se snazis vymyslet tak tomu se rika "Autorizacni mechanizmi" PAM, zamer se treba na pouziti sifrovaciho klice ktery bude lezet nekde jinde " FDD, USB, na jinem PC " , nebo overuj MAC adresu sveho PC nebo routru.

[AraxoN]

Myslím, že boot partícia bude zašifrovateľná len ťažko. Na nej zároveň bude musieť byť ten kernel, initrd, alebo niečo čo obsahuje kľúč ku zvyšku disku. Ja som to svojho času poriešil tak, že BOOT, ROOT a pár ďalších (/tmp/, /var/log/, ...) sú nešifrované a potom je tu jedna, ktorá je zašifrovaná cez dm_crypt, a tá sa mountuje len tak, že sa zodpovedná osoba logne cez SSH a zadá heslo. Po reštarte teda nabehne len obmedzený systém, a je treba ho nakopnúť ručne. Jedinú možnosť prieniku vidím v tom, keby útočník nabootoval na mieste z doneseného média a čakal kým sa lognem a nakopnem to. Bootovanie je povolené len z disku, BIOS zaheslovaný, a na otvorenie krytu je v BIOSe log, ktorý by po nečakanom boote mohol napovedať či s tým niekto manipuloval. Akurát ešte musím zistiť, ako sa k tomu logu dostať vzdialene...

[chinook]

Nechtel jsem zakladat nove vlakno, kdyz uz je tu neco podobneho. Potrebuji zasifrovat jeden disk + partition kde je linux. Co jsem cet, tak ten disk co chci zasifrovat musim vyplnit nahodne generovanymi daty. Pak, kdyz budu k zasifrovanemu disku pristupovat, budou se mi nahodne generovana data zobrazovat jako volne misto? Musi byt disk prazdny? Nebo uz na nem mohou byt nejaka data, ktere by se pouze zasifrovaly? Ad2. Rad bych, aby grub se nacet z nejakeho jineho media, kde by bylo ulozeno nejake silne heslo, pomoci ktereho by se disk desifroval. Problem by nastal, kdyby mi nekdo ukrad disk i s mediem, proto bych to chtel chranit jeste nejakym kratsim heslem.

Takze nabootuju napr. z flasky. 
Budu dotazan na heslo. 
Zadam heslo.
Z flasky se stahne nejaky "certifikat" pomoci, ktereho rozsifruje filesystem a nabootuje linux

[Michal Kubeček]

"Volné místo" jsou prostě bloky, o kterých je v jakési centrální kartotéce napsáno, že jsou volné. To předvyplnění náhodnými daty není kvůli funkčnosti (funguje to samozřejmě i bez toho), ale kvůli bezpečnosti, není pak tak snadné poznat, které části jste už použil a které ne.

[Chloop]

Počtení přesně na toto téma: http://gentoo-wiki.com/SECURITY_System_Encryption_DM-Crypt_with_LUKS

Mám na disku jednu malou zašifrovanou partition a klíč je 256KB velký soubor z /dev/urandom. Za pár korun jsem koupil 2 flaskhy po 128MB a na nich mám ten klíč. Jednu u sebe a druhá je záložní.

[chinook]

Z toho co jsem cet tak o data na partition prijdu ze? Tudiz pred sifrovanim musim zalohovat ze?

[Zdeněk Burda]

Zálohuj každopádně, ale o data nemusíš přijít (teda já sem zatím nepřišel nikdy).

z nezašifrovaného disku převedeš data na zašifrovaný pomocí (tohle se dělá jen jednou)

dd if=/dev/hda1 of=/dev/mapper/sifrovany-hda1

dd vezme nezašifrovaná data, zápisem do /dev/mapper/... se data zašifrujou a zapíší se na stejné místo ze kterého je dd vzalo. Musíš to provést najednou bez přerušování.

[Chloop]

Ano, o data přijdeš, protože ten cryptsetup si tu partition naformátuje dle svého, aby do ní mohl ukládat ta šifrovaná data. Takže zálohovat.

[Zdeněk Burda]

Zajímavé, šifroval jsem už několikrát disk přes dm-crypt a nikdy se mi tohle nestalo.

[Chloop]

K šifrování jsem používal cryptsetup-luks. Viz článek na gentoo-wiki.com.

[chinook]

Tak si radsi data zalohuji. Snad se mi nekam vlezou. Jeste mam dotaz k tomu bootovani. Jak se da udelat, abych system nabootoval pres flash disk, kde bude ulozen klic, ale chranen nejakou parafrasi? Tohle jsem nikde nenasel. Pouze u ssl pripojeni na pc.

[tlamik]

http://www.truecrypt.org/

[Peterson Larson]

Ahoj, kdysi jsem o necem podobnem taky uvazoval, ale nikdy jsem to neaplikoval, ale mozna by stalo za to pouvazovat napr. nad, rekneme, stringem (treba prohnanym jeste md5-kou) ziskanym z otisku hardware (nebo jen urciteho kousku) ve tvem compu a toto pouzit jako heslo pro kryptovanou partisnu. Samozrejme pokud bude mit utocnik zcela identicky system/hardware jako ty tak to ztraci vyznam, ale zase na druhou stranu kazdy doma nema compa treba od Della kde je identita takrka absolutni. Zaroven by ale nastal problem pokud bys musel vymenit nejakou soucast... Takze kdyz se nad tim tak zamyslim, interakce pomoci hesla je asi fakticky nejlepsi metoda...

[Shadow]

To by snad šlo udělat pomocí LUKS. V LUKS hlavičce šifrovaného oddílu je místo až na osm hesel, takže byste si zvolil nějaké opravdu silné heslo, které byste si buď pamatoval nebo uložil na bezpečném místě (pro případ změny HW), a přiřadil danému oddílu další heslo složené z vybraných hashovaných informací o HW. Malá úprava initrd a je to.

[chinook]

Mam debian etch. Pri pokusu o zasifrovani disku mi to vyhodi hlasky

cryptsetup -y create cryptdisk /dev/hda5 -c blowfish -h sha512

device-mapper: table: 254:0: crypt: Device lookup failed
device-mapper: ioctl: error adding target to table
device-mapper: ioctl: device doesnt appear to be in the dev hash table
command failed: device-mapper: reload ioctl failed: invalid argument

Co delam spatne? Jedu podle navodu na http://www.debianhelp.org/node/1116

[chinook]

Tak uz jsem to vygoogloval. Chyba je v jadre. S jadrem 2.6.17.2 to jede. Pred tim jsem mel. 2.6.18.3 tusim. Bude potom nejaky problem kdyz prejdu po zasifrovani na nove jadro? Nebo pokud bych je zkompiloval co mam pridat?

[Shadow]

Podpora šifer a hashí se určitě hodí, stejně jako dm-crypt. Nicméně, reagujete-li na můj příspěvek a máte-li zájem použít LUKS, zkuste tenhle návod (je pro Etche).

Vy jste použil "pouze" dm-crypt. Jeho rozdíly oproti LUKS naleznete popsány třeba zde.

Ke kompatibilitě dm-cryptu se nemohu zodpovědně vyjádřit, neb jej nepoužívám, ale implementace by IMHO měla být kompatibilní, minimálně směrem vzhůru. Pokud ne, vždycky můžete nabootovat staré jádro.

[atan]

Ja osobne bych pouzil truecrypt, ktery uz tu nekdo radil, a sifroval jen tajna data a ne system, je to podle me opravdu zbytecny. A k tomu bych jeste pouzil nejaky usb klic, coz se tu taky radilo, nejaka usb klicenka s 128mb, na ktery by byl ulozeny klic.

[Michal Kubeček]

V čem je ten truecrypt lepší než standardní systémové nástroje?

P.S.: obávám se, že 128 milibitů bude na klíč málo… :-)

[atan]

pro me moznost pouziti oddilu i ve windows. clovek nikdy nevi, kde to bude potrebovat nouzove otevrit treba ze zalohy. a v pripade sifrovani vetsi usb/hdd klicenky bych asi o nicem jinym ani neuvazoval (nic jineho multiplatformoveho neznam). P.S.: Tak dobre 128MB ;o)

[Shadow]

LUKS jde otevřít i ve Windows, viz FreeOTFE.

[AraxoN]

Ešte by som chcel doplniť, že šifrovací kľúč sa za normálnej prevádzky (t.j. ak /dev/mapper/niečo existuje) nachádza v pamäti. Správa pamäte nemá informácie o tom, čo je bezpečné swapovať a čo nie, takže sa nedá vylúčiť, že stránka pamäte s kľúčom bude odswapovaná na swap partíciu v NEZAŠIFROVANEJ podobe. V takom prípade útočník môže kľúč dohľadať. Považujem to za málo pravdepodobné, napriek tomu som si to zariadil tak, že swap sa vytvorií až po boote na zariadení /dev/mapper/swap, na ktorého zašifrovanie sa použije reťazec z /dev/random (server má HW RNG, takže lockup pri boote nehrozí). Neviem čo to spraví pri pokuse o hibernáciu, ale keďže sa jedná o server, tak to neriešim.

[petr_p]

Neni pravda. Oblast pameti lze oznacit na neodswappovatelnou (shmctl(,SHM_LOCK,)). Kazdy rozumny program, ktery pracuje s kryptografickym materialem to dela.

[AraxoN]

V tom prípade sa ospravedlňujem za dezinformáciu - ako som nakúpil, tak predávam. Je možné, že nepravdivo...