Kerüljétek a dm-crypt-et!

Linux-haladó

Sziasztok!

Ez a dm-crypt egy átok! Kétmagos géppel képtelenség dolgozni, ha a "háttérben" nagy mennyiségű adatot írok vagy olvasok dm-crypt lemezre/ről. Még az egérkattintásokat sem mindig veszi észre az X.
Használjatok loop-aes-t! Állítólag biztonságosabb is, kicsit gyorsabb , ha magában dolgozik, és alig terheli a procit, ha közben mást is csinálunk.
Hátránya: a népszerű disztrók kernelében nincs benne, kézzel kell beleforgatni.

  • 4898 megtekintés

( csearo | 2008. 07. 18., p – 17:47 )

Kulonos ez a dm-crypt.
Uhu Linux es Knoppix alatt hasonlokat tapasztaltam, egymagos gepen, teljesen hasznalhatatlan lesz tole a rendszer, ha sokat masolok a hatterben.

Erdekes modon gentoo (2.6.23) alatt tokeletesen mukodokepes marad a rendszer, esetenkent a tv-nezes akadozik alig eszrevehetoen.

( sibidiba | 2008. 07. 18., p – 17:56 )

Csak óvatosan az ilyen kijelentésekkel. Egyrészt nincs mindenkinek baja a dm-crypttel - pl. nekem se, Ubutnu 8.04 HH - másrészt partíció titkosítására az losetup kevésbé alkalmas, sőt, nekem olyas valami rémlik, hogy régebben kimondottan ellenjavallt volt teljes diszk/partíció titkosítására. Ha jól tudom, most is a device mapper az ajánlott út.

--
The Net is indeed vast and infinite...
http://gablog.eu

( uid_4672 | 2008. 07. 18., p – 18:41 )

hát aki a rendszerfileokat dmcryptes partícióra teszi az megérdemli
remélem a linuxban "haladó" kolléga nem kioktatni akarja az embereket, hogy mit használjanak...

remélem a linuxban "haladó" kolléga nem kioktatni akarja az embereket, hogy mit használjanak...

Nem kioktatni, hanem hasonló szívásoktól megkímélni. Ha te eddig dm-crypt-et használtál, akkor ideje megismerkedni a loop-aes-sel. Ha eddig semmit nem használtál, akkor a dm-crypt-hez ne is kezdj hozzá.
Természetesen csak haladóknak ajánlom, mert a kernelt-t és a util-linux-ot is foltozni kell hozzá. Atombiztos titkosításhoz még a gnupg-t is.

én dm-cryptet használok és kizárólag a munkáimat tartom ott és semmi bajom nem volt még vele.

hozzátenném, hogy az "egy átok", "kerüljétek", "egérkattintásokat sem veszi észre az X" kifejezések nem egy professzionális teszt konklúzióját sugallják.

1. a dm-crypt benne van a kernelben, nem kell patchelni, könnyebb belőni
2. hogy biztonságosabb lenne... ez lehet
3. dm-crypttel többféle ciphert használhatsz, afaik
4. több kulcsot hozzá lehet rendelni
5. a teljesítménye nem öli meg a laptopomat (aes-t használok vele): szerintem értelmetlen pl. a rendszerfileokat enkriptálva tárolni

p.s. én bárhogy is olvasom az eredeti fórumtémát a "hasonló szívásoktól megkímélés" helyett csak egy tanácsadásnak és megalapozottnak nem nevezhető "rendreutasítást" látok benne

Meddig tart egy pendrive-ról bootolva backdoort tenni a rendszerbe ha pl az /usr -t nem titkosítod? Első indulás után pedig már csemegézhet is a támadó az adataidból. (Mondjuk ez a probléma az initrd -nél is felmerül, azt is egy pillanat lecserélni olyanra, ami leloggolja a beírt jelszót a diszkre, bár az legalább 3 üléses támadás: egyszer le kell lopni, egyszer feltenni a moddoltat, majd ellopni a laptopot.)

Mondjuk ha a cél hogy egy laptoptolvaj ellen védd a disznó képeid arra valóban elég a /home titosítása.

( crypton | 2008. 07. 18., p – 20:22 )

Nálam a következőképpen néz ki, és eddig tökéletesen működik, csak ajánlani tudom:
--
sda1 -> /boot -> normál, _nem_ crypted
sda2 -> lvm_volume -> encrypted, dm-crypt-el,
az encrypted LVM partíción vannak a következők:
/lvm-root (/)
/lvm-swap swap
/lvm-home (/home)
mind ext3
--
Eddig semmi bajom nem volt vele, működik, 2.6.24.x és 2.6.25.x -es vanila kernelekkel használom, csak a szükséges dolgok belefordítva.
Vas: HP 6710B noti, DC2 proci, 2G ram, 160g ...
(Van rajta egy 15G-s file is a home-on egy KVM-es XP-nek, az is szépen teszi a dolgát). Van hogy 2-3 hétig be van kapcsolva a gép, telepakolva futó alkalmazásokkal.
Disztr: Ubuntu 8.04.1
--
Szerintem egy jó kis tool a dm-crypt, szinte kötelező notikon használni, adatok védelmére. Csak ajánlani tudom.

cryp
--
ps: most neztem meg, LUKS/cryptsetup -on keresztul tortent a dm-crypt hasznalata...

( padawan | 2008. 07. 18., p – 21:17 )

Worksforme. x86 es amd64-el is tokjo.

( Proci85 v | 2008. 07. 18., p – 21:28 )

A terhelés mértéke nagyban függ azért a felhasznált titkosítási algoritmustól is.
Desktop gépen titkositott sata vinyóra történő irás/olvasáskor ~40-50MByte/s sebességgel történt az adatmozgatás, és a rendszer nem szakadozott. 


~ $ uname -a
Linux Proci-Computer 2.6.21-gentoo-r4 #3 SMP Sat Apr 26 20:01:15 CEST 2008 i686 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ AuthenticAMD GNU/Linux

 # equery list crypt
[I--] [  ] dev-libs/libgcrypt-1.4.0-r1 (0)
[I--] [  ] dev-python/pycrypto-2.0.1-r6 (0)
[I--] [  ] sys-fs/cryptsetup-1.0.5-r1 (0)

A használt algoritmus, mellyel a particiókat létrehoztam: 

/bin/cryptsetup -c aes-cbc-essiv:sha256 luksFormat /dev/sda6 /mnt/key.sda6

( arpi_esp v | 2010. 10. 21., cs – 12:54 )

ez ugyben van vajon valami fejlodes?

mi eddig a kernelbeli cryptoloop-ot hasznaltuk (loop-aes utodja amennyire tudom)
de van vele 2 durva gond:
- 2 ilyen cryptoloopos disk kozti masolas hazavagja az egesz gepet, 20-40-es load, percekig nem reagalo processzek...
- a loopdev miatt nem veszi eszre a gep ha veletlen 2x akarom mountolni, es siman megcsinalja, aztan jonnek a filesystem corruptionok.
(felmountolja rendesen rw-re 2x, 2 kulonbozo loopdev hasznalataval, de ugyanarrol a fizikai device-rol)

kivancsi lennek a dmcrypt ezekhez hogy viszonyul, tapasztalata vkinek?

A'rpi

eleg nagy. es nem a cpu a szuk keresztmetszet, az alig van terhelve (max 10-20%).

nekem ugy tunik, hogy a disk alrendszer hulyul be a loopdevtol es egyszerre probal 10-20 szalon irni ugyanarra a diskre a cache-bol/bufferbol.

amig 2 pdflush kernel processz megy addig meg ok de amikor elkezd elszaporodni par per cutan akkor hal be az egesz vas. ujabb kernelekben (2.6.31 korultol) mar maskepp mukodik (device-onkent 1-1 kulon pdflush van), de a behalas megmaradt.

A'rpi

A loop-aes korlátozza a diszkek felé menő párhuzamos IO -k számát, ezt érzed. Van valami loop-aes modulparaméter amivel meg tudod emelni, de a maximum is kevés egy nagyobb raid -nek. A pdflush nem azon a szinten működik, nem tud segíteni rajta. A dm-crypt -ben nincs efféle üvegnyak.

mi eddig a kernelbeli cryptoloop-ot hasznaltuk (loop-aes utodja amennyire tudom)

Nem. A cryptoloop utódja a dm-crypt. Ha jól tudom, az utóbbit illik használni az előbbi helyett, mert az előbbi törhető.
Amit a teljesítmény-csökkenésről írsz, az a "dm-crypt"-nél is ugyanígy van. Ha van 2-300 MB szabad helyed, akkor pl. 3 db 100 MB-os fájlal és software raid-del kipróbálhatod a "dm-crypt"-et. A sw-raid az egyik, amivel meg lehet fektetni. És rögtön össze is hasonlíthatod a "loop-aes"-sel. Ubuntu-ban aptitude-del föl lehet tenni a "loop-aes"-t. Ha jól tudom, Feadora-ban kernelt kell fordítani hozzá.
Saját tapasztalataimat összefoglalva: pendrive, vagy adatok titkosítására tökéletes a dm-crypt. Ha még hordozni is kell azt a pendrive-ot, akkor jobb is, mint a loop-aes. /home titkosításra talán jó, talán nem. / (azaz root) titkosításra viszont semmiképp nem ajánlom.

hat nekunk nagy (ertsd 10tb nagysagrend) adatmennyiseg titkositasara kene, nem annyira a biztonsag inkabb a sebesseg es a megbizhatosag a fontos.

sajnos attol tartok a loop-aes eseten ugyanaozk a gondok elojonennek mint a cryptoloopnal, hogy a felsobb disk i/o layerek nem latjak a valodi devicet es a scheduler elkeveri a dolgokat es ugyanoda akar irni 10-20 szalon egyszerre amit meg a diskek nem birnak.

proci terheles nem izgat annyira, az most se problema, a tobbi (net, disk) sokkal szukebb kerestzmetszet...

A'rpi

Viszont jó eséllyel a dm-crypt mutat számodra leginkább a jövőbe, bár talán nagyobb a CPU overhead-je, viszont a DM rétegbe épp mostanában küldik be egyre több target-re a barrier támogatást, ami épp az általad panaszolt jelenségre jelenthet ellenszert.
Hogy a crypt target esetén ez hogy áll, azt hirtelen nem tudom, de utánanézhetek.

Vágom, de 10 tb-ot ha jól sejtem, dm-multipath-on is keresztülzavarjátok, legalábbis jó eséllyel FC diszk, vagy iSCSI, mindenesetre multipath.
Annak a barrier támogatása meg egyelőre szopó.

Simán dm-mpath-on keresztül dm-crypt nélkül jó, csak dm-crypt-tel együtt nem?

nem, sima 1-2tb-os sata diskek pcix-es sata vezerlon, meg raid sincs (se sw se hw).

siman a device-re rakott fs-el jo, de akar sima loopdev akar cryptoloop nem. dmcrypt egyelore jol turi, most megy egy nagyobb teszt... a load mar 15, de meg nem lassult be a gep, a masolas is megy de csak atlag 10-15mb/s-el :(

A'rpi

És látszik, mi viszi az időt?
Profiling nem mond valamit?
Ezek szerint van kb 8 db TB környéki diszked, 8 külön fájlrendszerrel, mind dm-crypt-en, és diszkenként tudsz 10-15 MB/s-t?
Nem azt mondom, hogy ez így rendben van, de azért sokkal-sokkal jobbra ne számíts. :)

Hány CPU-t toltatok ebbe a gépbe?

nem egyszerre neztem, hanem osszesen 2 disk megy, a tobbi idle. a 2 disken dmcrypt es egyikrol masolok a masikra, az megy 10-15-el. ez nem sok, nagyon nem, crypt nelkul 50-60-al megy. cryptoloop-al is annyival indul de egyre lassul es ahogy elindul fel a load lemegy par kb-ra es gyakorlatilag "beall" a gep, amig le nem lovom a copyt.
dmcryot legalabb stabil, csak kb 3-4-ed sebesseg egyelore.

core2 quad 3ghz van benne, de az nincs kiterhelve, meg 1 szalon se.

a "idot" az viszi, hogy a hulye kernel egyszerre tobb szalon probal irni ugyanarra a diskre, tehat ahelyett, hogy folyamatosan szekvencialisan irna a disket, random blokkokat irogat ra, legalabbis ezt tippelem. a regi kernelbe meg latszottak kulon a pdflush kernel processzek, es amig 2db futott addig minden fasza aztan amikor elszaporodott akkor lassult szet, a diskek meg kerregnek mint allat.
valamelyik kernelhez volt egy patch, amivel lehetett a pdflush-ok szamat maximalni, az megoldotta ezt a problemat, de aztan valami miatt frissitettunk es az ujabb verziokban meg mar nem pdflush van, a problema meg visszajott...

A'rpi

Azzal a procival ez elég gyenge. Most mértem egy régi P4 2GHz-es, hyperthread nélküli procin:
- "loop-aes"-ről "loop-aes"-re 11.7 MB/s, 100% CPU terhelés
- sima loop-ról "loop-aes"-re 13.8 MB/s, 100% CPU terhelés
- vinyóról "loop-aes"-re 18.7 MB/s, 100% CPU terhelés

Nyilvánvaló, hogy nálam a proci a korlátozó tényező. A te procid egyetlen magjától én minimum 36 MB/s-ot várnék.

Mostanában próbálják SMP baráttá tenni a crypto alrendszert, lehet, hogy a legújabb kernelekkel már a dm-crypt is megy a pcrypt alrendszerrel.
Bár mint írtad nem a CPU a szűk keresztmetszet.

https://patchwork.kernel.org/patch/103298/

A pcrypt-ről bővebben:

http://www.linuxtag.org/2010/fileadmin/www.linuxtag.org/slides/Steffen%…

Itt ugyan csak az IPSEC gyorsításáról van szó, de a pcrypt elvileg független ettől.

A txt-t át kell nevezni pdf-re mert el*ták.

Mindig meglep, hogy ezek a dolgok még mindig 1 szálon futnak.

Ha igazad lenne, akkor a mount --bind felesleges lenne.
A probléma ott lesz, hogy amikor csatolod a boot1 könyvtárba az eszközt, akkor annak létre jön egy cache. Amikor csatolod a boot2 könyvtárba is, akkor annak külön cache jön létre és a két cache nem tud egymásról, nem is kommunikálnak. Ez meg probléma:
- tolj egy ls parancsot mindkét könyvtárra - a könyvtár bekerül a cache-ba
- hozz létre egy könyvtárat a boot1 alatt - az első szabad bejegyzésbe beíródik a neve, lefoglalódik a hely az új alkönyvtárnak
- csináld meg ugyanezt a boot2 alatt, más néven - ez is az első általa szabadnak hitt helyre akar dolgozni - és ezzel szépen agyon is csapja a boot1-ben létrehozott bejegyzést...
- tolj ismét ls-t a két könyvtárra, mit látsz? A cache miatt még jónak fog tünni...
- csatold ki mindkét partíciót, majd csatold be újra...
Hogy "ki nyer", az azon dől el, hogy melyik cache ürül később. Ami biztos, hogy ez így nagyon nem nyerő...

igen, pont ez a gond.
amugy ha siman /dev/sd* devicet mountolsz ketszer akkor azt eszreveszi a kernel es kozos cache lesz, legalabbis nem okoz problemat. viszont ha mindezt loopdev-en kerestzul oldod meg, akkor mar nem ok, mert a mount 2 kulon loopdevet hoz letre...

de ez annyira nem problema, csak oda kell ra figyelni nagyon.

A'rpi

Ha igy mountolom http://hup.hu/node/58346#comment-1143931 akkor nem talaltam hibat.

$ ls /tmp/loop1/
lost+found
$ ls /tmp/loop2/
lost+found
$ mkdir /tmp/loop1/1
$ mkdir /tmp/loop2/2
$ ls /tmp/loop1/
1 2 lost+found
$ ls /tmp/loop2/
1 2 lost+found

$ umount /tmp/loop1
$ umount /tmp/loop2
$ mount /dev/loop0 /tmp/loop1
$ ls /tmp/loop1/
1 2 lost+found

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( fn26 | 2010. 10. 21., cs – 22:01 )

Nekem az a gondom a dm-script- tel, hogy kenytelen leszek hasznalni. Cryptoloop- ot hasznaltam titkositasra, es kb. 2 napja olvastam, hogy debianek dobtak a cryptoloop tamogatasat ... . Nem vagyok boldog. Azt se tudom, hogy vissza tudom- e allitani a rendszerem, de ez a hetvege projectje.