Názory k článku
Jak vytvořit šifrovaný oddíl v Linuxu

neznaly uzivatel by ocenil, kdyby jste vysvvetlil, jak sifrovane oddily pripojovat automaticky zadanim hesla pri startu systemu.

To bude probráno v posledním dílu seriálu.

Podstatně rychlejší alternativu k tomuto postupu může představovat vytvoření zašifrovaného oddílu pomocí dm-crypt/LUKS a jeho přepis zařízením /dev/zero (popřípadě užitím badblocks – viz výše). Nejsem kryptolog, abych byl schopen říci, nakolik je tato metoda horší než použití /dev/urandom, ale dle mého názoru by neměla být horší o moc.

Určite vhodnejšie je prepísať disk náhodnými dátami a to niekoľkonásobne. Ak je niekto paranoidný, prepíše 25 krát :). Jedná sa ale o ochranu dát, ktoré sa na oddieli nachádzajú pred zašifrovaním. V prípade, že nám o ochranu týchto dát nejde, možeme z podľadu bezpečnosti kľudne v rámci kontroly disku na chyby použiť /dev/zero. Či je to dostatočné aj pre sponenutú kontrolu chýb, neviem.

On nemal na mysli to ze sa pomocou /dev/zero prepise nezasifrovana particia ale ze si najprv vytvorime na tej particii sifrovany disk, ten sifrovany disk namapujeme napr. ako /dev/mapper/docasnydisk a zadame dd if=/dev/zero of=/dev/mapper/docasnydisk. Potom ten docasnydisk odpojime a znova si vytvorime sifrovany oddiel ako keby sme to robili prvykrat.

Jako jisty bonus lze brat, ze kdyz nekdo tuto cast odhali a rozlouskne klic (coz mu nejaky cas zabere), tak ten klic nemuze pouzit na lousknuti skutecnych dat a je mu k nicemu :)

Pokud jste schopen pomocí urandom generovat pseudonáhodná čísla dostatečně rychle (desítky MB/s), pak používejte urandom (mimochodem, kde jste sehnal HW generátor náhodných čísel?). Sám si to můžete "nezávazně" vyzkoušet:

dd if=/dev/urandom of=/dev/null

Naopak, pokud vygenerujete z bídou 3-4MB/s jako já, pak se začnete poohlížet po alternativním řešení, abyste nemusel čekat dny na přípravu zašifrovaného oddílu.

vono stejne zasifrovany /dev/zero bude vytvaret nejakej slozitej ale predse jen periodickej vzorek, ne?

Tak za prvé, pokud si přečtete celou moji formulaci, pak dávám na výběr mezi /dev/zero (což je zrovna ta horší možnost) a programem badblocks (což osobně doporučuji), který generuje sice méně kvalitní pseudonáhodná data, ale generuje je velmi rychle, takže ve spojení s vhodnou šifrou a šifrovacím módem by měl být výstup náhodný dostatečně.

A za druhé, s použitím vhodného šifrovacího módu by vůbec nemělo vadit použití /dev/zero, výstup by měl být navzdory jeho použití taktéž dostatečně náhodný. Ale, jak už jsem uváděl, nejsem krytptolog, abych to dokázal odborně posoudit. Čili, badblocks+dm-crypt/LUKS je podle mého pro zaplnění oddílu náhodnými daty optimální řešení - je dostatečně rychlé a mělo by být i dostatečně "náhodné". Pro příklad v článku jsem právě proto zvolil tuto alternativu.

na disk se zatim komprese pred sifrovanim nepouziva, ne? asi ta komprese je narocnejsi na CPU nez sifrovani

Nepoužívá. Proto u diskového šifrování (a nejen tam, když už jsme u toho) hodně záleží na šifrovacím módu.

a ten napad naplnit disk sifrovanyma nahodnyma datama s jinym heslem, nez pak bude pouzito, je zajimavej, ale nevidim v tom moc zadnou vyhodu

"Jen" mnohonásobně vyšší rychlost oproti urandom. A podle mého názoru, výstup by měl být srovnatelně bezpečný s urandom.

Zdar, možná se to bude někomu hodit (třeba autorovy jako potvrzená toho co bude psát pro jinou distribuci :o) Zrovna předevčírem jsem dával do kupy jeden servřík, kde je RAID políčko ze 4 1TB disků a 2 systémových. Je to je pořadí příkazů, bez nějakých extra komentářů, či vysvětlení, platných obecně. Změny konfigurace potom pro ARCH linux (ale budou asi podobné všade). Popsaný je vytvoření systémových, bootu, instalace. Datové jsou identické, jen jednodušší. Neřeším otázku původních dat, disky byly nové (navíc nevím o tom, že bych měl poruchu osobnosti :) Pakliže tam někdo něco má, pak je vhodné udělat to co píše autor článku. Rozdělení LVM, přsun /var /tmp tu neřeším. Jen prostě čistou hrubou instalaci.

Cca 20 minutek, když jsou svižné disky a rozumná (čti neklikací,nelive) instalace.

Na 1 sys disk se normálně nainstaluje distribuce (nezdržovat partition, nacpat vše do sda1)

Bez záruky (o: Bůch ví, jestli si to pamatuju přesně.

rozdelit disk (vse typ FD)
* 1: 100M boot
2: 8G swap
3: 5G /
4: zbytek LVM (data)

#vytvorit pole (pokud by bylo víc disků, SWAP mít RAID0 nebo 1, BOOT 1 a zbytek 10)
mdadm --create /dev/md0 --level=1 --chunk=64 --raid-devices=2 /dev/sdb3 missing
mdadm --create /dev/md1 --level=1 --chunk=128 --raid-devices=2 /dev/sdb1 missing
mdadm --create /dev/md2 --level=1 --chunk=128 --raid-devices=2 /dev/sdb4 missing
mdadm --create /dev/md3 --level=1 --chunk=256 --raid-devices=2 /dev/sdb2 missing

md0: /
md1: boot
md2: LVM (data)
md3: swap

# kuk jestli funguje co to ma
cat /proc/mdstat

modprobe dm-crypt
modprobe aes-i586
modprobe sha256

# udelat samotne ctrypt odily
cryptsetup -c aes-lrw-benbi -y -s 384 luksFormat /dev/md0
cryptsetup -c aes-lrw-benbi -y -s 384 luksFormat /dev/md2
cryptsetup luksOpen /dev/md0 root
cryptsetup luksOpen /dev/md2 lvm

# pripojit pro instalaci a pripravit dirs
mkreiserfs /dev/md1
mkreiserfs /dev/mapper/root
mkdir /mnt2
mount /dev/mapper/root /mnt2
mkdir /mnt2/var
mkdir /mnt2/tmp
mkdir /mnt2/boot
mkdir /mnt2/dev
mkdir /mnt2/sys
mkdir /mnt2/proc
mount /dev/md1 /mnt2/boot/
chmod u-w /mnt2/proc

# install
cp -rp /bin/ /home/ /sbin/ /usr/ /boot/ /etc/ /lib/ /opt/ /root/ /srv/ /var/ /mnt2/

# zakladni nody pro po init
mknod -m 660 /mnt2/dev/console c 5 1
mknod -m 660 /mnt2/dev/null c 1 3
mknod -m 660 /mnt2/dev/zero c 1 5

# pripojit udev a spol (aby bezelo lilo a pod)
mount -t proc none /mnt2/proc
mount -t sysfs none /mnt2/sys
mount -o bind /dev /mnt2/dev

# zaznamenani RAIDu
mdadm -D --scan >> /mnt2/etc/mdadm.conf

# veskere dalsi upravy jsou v /mnt2, kde funguje chroot (lilo, mdadm, ...)

#uprava lilo.conf
boot=/dev/md0
raid-extra-boot=mbr-only
append="md=0,/dev/sdb3,/dev/sda3 cryptdevice=/dev/md0:root"
menu-scheme=wb:bw:wb:bw
...
root=/dev/md0

# pokud bude lilo prskat, ze neni sda3, dopsat "disk=/dev/sda3 inaccessible", pripadne misto /dev/sda3 pouzit missing. obe po pridani druheho disku zrusit

# upravit mkinitcpio.conf
HOOKS="base udev autodetect pata scsi sata usbinput keymap raid lvm2 encrypt filesystems"

# upravit rc.conf
USELVM="yes"
DAEMONS=(syslog-ng network sshd netfs crond mdadm


# update boot image
chroot /mnt2 mkinitcpio -g /boot/kernel26.img

# fstab
/dev/mapper/root / reiserfs defaults 0 1
/dev/md1 /boot reiserfs defaults 0 1
/dev/mapper/swap swap swap defaults 0 0

# crypttab
swap /dev/md3 SWAP -c aes-cbc-essiv:sha256 -h sha256 -s 256

# update lila
lilo -r /mnt2 -H

# reboot (bylo by košér nejrpve unmount všeho), bootnout z degrad. pole

# udelat RAID stastnym
mdadm --add /dev/md0 /dev/sda3
mdadm --add /dev/md1 /dev/sda1
mdadm --add /dev/md2 /dev/sda4
mdadm --add /dev/md3 /dev/sda2
# poladit mdadm.conf, vyhodit spare/failed, minimalne nastavit MAILADDR

# nez dobehne repllikace, dat si pivo (u tech TB disku je cas i na tocene)

# updatnout LILO, uz nebude prskat (mne prskalo dokud nedobehla replikace)
lilo

Reboot || EOF.

Může mi někdo říct, proč všici používají GRUB ? Ne že bych miloval lilo (hlavně před 10ti rokama to bylo něco ¨tragického), ale přiblbé značení (číslování) disků a konfigurace GRUBu mně osobně docela děsí. S GRUBem a RAIDama jsem měl dycinky problém, spousta řádků, spousta počítání (hlavně když je v poli třeba 8 disků). LILO to zchroupe jemnou úpravou :) Vím, že GRUB i kafe uvaří, ale za jakou cenu ?

Ray

Jsem zapomněl, než se přidá druhej disk do RAID pole, je potřeba partitions:

sfdisk -d /dev/sdb | sfdisk /dev/sda

Ray

Proc je poradi oddilu disku zrovna 3-1-4-2? Je to z duvodu fyzickeho rozmisteni dat na disku nebo je to nejaka vyssi magie jako je treba poradi zapalovani valcu u motoru? (To je ale 1-3-4-2, vice viz http://en.wikipedia.org/wiki/Firing_order .)

Boot je první, aby byl první, hlavně dříve muselo LILO (resp. BIOS) mít boot data relativně vepředu disku (čti kernel, resp. image). Tak se dá (i dnes) třeba na P100 provozovat 500G disk bez problému (sám několik takových strojů mám... ikdyž se nedá například vlézt do BIOSu, protože hned padne na hubu). Funguje to bezproblémově. BIOS zjednodušeně nedošáhne "dál". Pokud LILO/GRUB nenačte svoje data, nemůže pustit kernel. Bez kernelu I/O vysí na BIOSu.... U nových desek je to relativně jedno.

Potom už to je spíše "magie" :o) Jediné by mělo smysl je, aby SWAP byl fyzicky co nejblíže nejčastěji používaným datům (obecně, všechny hojně používaná data). Otázka ale je, co jsou ony nejčastěji používaná data. Navíc, disky si dneska mapujou sektory podle sebe, nedá se tedy spoléhat na geometrii. V konečném důsledku: je to prakticky jedno.

Ideální by bylo, aby nejvíce využitá data byly stejně vzdálené od osy otačení na všech plotnách (jejich fyzický střed). Nevím, nehledal jsem, ale třeba existuje prográmek, který je schopen změřit reakční dobu na disku (stejně jako se dá změřit velikost a počet caches). Potom by jistě šla propustnost (a to i zajisté dost výrazně) zvednout. Koupit velký disk s co nejvíce plotnama, využít jen jeho část (a to bude relativně malá část, třeba jen 15-20 procent kapacity max), zato jednotlivé oddíly umístnit fyzicky nad sebe a minimalizovat seek...

Já jsem si MD0 nazval root, 1 boot jen protože se mi to tak líbí víceméně (o: Jistě se najdě někdo, kdo to dělá opačně a cokoliv jinak je špatně. A co se týče fyzického pořadí.... Boot prvni ze zvyku. Swap druhej taky ze zvyku (třeba na OpenBSD je to více než zvyk). A ty další ? Nezkoumal jsem přesnou geometrii disku, nedělal testy, čili... Je to fuk.

Ray

Chlape, pamatujte si, že visí měkký. Tvrdý nevisí (podle vašeho "nevysí").

Já vím, sypu si popel na hlavu. Sice se to někomu může zdát nepochopitelné, ale čestina patří mezi věci, které vypouštím, želbohu má můj mozek konečnou kapacitu a je zacpán jinejma hovadinama... Jsem shcopný napsat vyděl (ve smyslu viděti), případně uhlý a nechá mne to ledově klidným...

R.

pche ... poradii paaleni ve valciich neni zadna magie ...
jde o vyvaazeni sil na klice ...
.. navic treba skodovka od 1000MB do 120/130 ... pak nevim
.. 1-3-4-2
.. a co teprvaaa boxer (vw...nebo citroen/ol(d)cit)
-)))
to jen tak na vokraj ... aby se nereklo

PS:nekamenovat nepishu czesky ;-)

Redakce očividně považuje slovo degraZZZdovaného. Je to zajímavé, ale bez těch Z se napsat nedá. Jsem rád, že umím další sprosté slovo (o: Ale hlavně, že jsi dali práci s regexp, aby ty Z nestačilo napsat na konci. Achjo. Kam to ten svět spěje ? Ve fóru si člověk nezanadává, finlandie mrzne na mrazáku (fakt :(, jameson chutná jak denaturák, pivo je zelené, nebo pro změnu vidělo chmel z hodně velké dálky. Za chvilku nebude co pít. A co pak ?

Ray

Problém byl právě opraven: degradovaného :-D.

zdravím, zatím nejsem dostatečně paranoidní abych šifroval kompletně celé disky. ale zajímala by mě (hlavně do budoucna) jedna věc - všude se můžu dočíst, že i po přepsání dat na klasickém pevném disku lze tyto obnovit. ale nikde sem se už nedočetl jak je to se solid state disky. je možný z toho vyrazit přepsaná data? zabývá se tím někdo, provádí to nějaká firma? víte tady někdo o tom něco?

tak nic, jdu to hledat sám :#)

Těžko říct... V důsledku to je analogovej zápis. Takže proč ne :o) Ale bude to o několik řádů cenově jinde, protože na to, aby někdo četl z plotny, stačí relativně obyčený věci (plotna je velká). Hrabat se na úrovni buněk, to už je jiný kafe.

R.

Truecrypt je pekna vec, ale de-facto je to Win aplikace naroubovana do Linuxu. Dneska jsem trosku prochazel jeho zdrojaky a musim rici, ze mi prijde krajne nesystemove naprogramovany (ve smyslu ze v nem moc neni system a nejaka vize, jinak systemova aplikace, mysleno na nizke urovni, to urcite je).

V Linuxu je s TC zasadni problem v tom, ze bezi pres FUSE takovou pomerne podivnou cestou. to bych jeste prekousl, ale aktualni stav sifrovani systemoveho disku v podstate znemoznuje provozovani jakehokoliv dalsiho systemu mimo Windows na danem stroji, chcete-li pomoci TC sifrovat i dalsi disk/partition (napr. TC vam nedovoli zasifrovat cely disk kdyz mate extended partition). Dalsi veci je, ze TC pri sifrovani jedne partition ulozi hlavicku do prvniho cylindru disku (hned za svuj kod) a tato je pak pouzita pro desifrovani. V linuxu takovou vec samozrejme nepripojite ...

Ruznych "podivnosti" tam je spousta, prilis nechapu proc takova pekna vec, jakou TrueCrypt bezesporu je, nebyla uz ze zacatku programovana se *snadnou* prenositelnosti na jine platformy.

Jinak dle meho nazoru jde pomoci dm-cryptu pripojit truecryptovy volume, alespon pokud se napise tool, ktery misto LUKS hlavicky naparsuje tu truecryptovou a preda to pres prislusne ioctl kernelu.

AHoj!

nedavno jsem resil problem jak zasifrovat oddil na MMC/SD flash karte. Kdyz jsem pouzil muj oblibeny XFS (mkfs.xfs /dev/mapper/kryptkarta), po nekolika restartech systemu se XFS rozsypal, a ani xfs_repair nepomohlo, resp. vetsina FS se presunula do lost+found :(

Kryptkartu jsem preformatoval na EXT3, obnovil data ze zalohy a od te doby nemam problem.

Rozumite tomu nekdo? Je mozne, ze XFS je pro krypteni nevhodne? Snazil jsem se vyhledat informaci o vhodnosti jednotlivych FS na krypteni, ale nic jsem nenasel.

Diky!

-Loiz

XFS má problémy, pokud selže umount nebo pokud se data správně nesyncnou (což může zapříčinit třeba i ten md-crypt).

Na MMC, SD a jiné flash karty není dobré používat žurnálované souborové systémy, dokáže je velmi rychle zničit. Doporučuji jen ext2 nebo FAT.

Rekneme ze mam oddily sda1 sdb1 sdc1 a chci nad nema vytvorit sifrovane RAID5 pole a nad nim LVM. Mam tedy /dev/md0 ktere je kryptovane.

Co kdybych do toho pole chtel pridat dalsi oddil sdd1?

Bude stacit tohle, a disk se stane plnohodnotnou soucasti sifrovaneho pole?

dd if=/dev/urandom of=/dev/sdd1
mdadm --add /dev/md0 /dev/sdd1
mdadm --grow /dev/md0 --raid-devices=4
pvresize
lvresize
FS resize

Jo a diky za pekny clanek ;-)
M.

Pokud je RAID pole šifrované a nad ním vytváříte LVM, pak by měl váš postup zcela postačovat.

Není mi jasná jedna věc. Pokud chápu dobře princip CBC módu, tak by změna dat znamenala nutnost přešifrovat všechny následné bloky. To mi přijde pro šifrování pracovního disku poněkud nepraktické (zvláště pokud je hlavička FS na začátku), ale žádnou zmínku o tom jsem nenašel. Jak je toto řešeno?

Řeší se to tak, že se pomocí CBC šifrují jednotlivé sektory, a to odděleně. Cituji:

Since CBC encryption is a recursive algorithm, the encryption of the n-th block requires the encryption of all preceding blocks, 0 till n-1. Thus, if we would run the whole hard disk encryption in CBC mode, one would have to re-encrypt the whole hard disk, if the first computation step changed, this is, when the first plain text block changed. Of course, this is an undesired property, therefore the CBC chaining is cut every sector and restarted with a new initialisation vector (IV), so we can encrypt sectors individually. The choice of the sector as smallest unit matches with the smallest unit of hard disks, where a sector is also atomic in terms of access.

Zdroj: Clemens Fruhwirth, Linux hard disk encryption settings

Děkuji, tak si představuji odpověď na dotaz :)

Tím ale mizí ochrana proti nahrazení sektoru jako celku "starou" hodnotou, ne?

Dle mnou zmíněného zdroje, pokud ho správně chápu, proti podobným útokům by mohly poskytovat jistou formu ochrany šifrovací módy LRW a XTS. Ale v tomhle už vážně střílím od boku.