teljes merevlemez titkosítása meglévő rendszeren

Linux-haladó

Sziasztok!

Adott Lenovo T410-es gép i5-ös processzorral (nem Sandy). A gépen már hosszabb ideje használok Ubuntu Linuxot és szeretném titkosítani a teljes merevlemezt. Az ok rendkívül prózai: A gépen vannak olyan személyes és céges anyagok, amelyeknél nem szeretném, hogy ellopás vagy elvesztés esetén illetéktelen kezekbe kerüljenek.
Elvileg a processzor már hardveresen tudja kezelni a titkosítást, illetve a TPM is segít.

Az érdekelne, hogy ezt hogyan oldanátok meg meglévő rendszer esetén (live cd-ről boot, dd-vel teljes másolat, merevlemez titkosítása, dd-vel image vissza) illetve kb. milyen teljesítményromlásra számíthatok?

  • 4949 megtekintés

( Dacr (nem ellenőrzött) | 2011. 08. 14., v – 04:51 )

Ha már van hely lementeni dd-vel az egész lemez tartalmát, lehet, hogy egyszerűbb, ha lemented az adataidat simán, majd egy clean install, s ott választasz neki titkosítást. Szinte már mindegyik disztró telepítőjében lehetőség van erre, s akkor tuti, hogy nem vágod haza az adataidat. Nem beszélve arról, hogy ha a live cd-s dolog nem jön össze, így is úgy is tiszta telepítés lesz belőle (már ha továbbra is titkosítani akarsz). Szerintem egy Ubuntut titkosítással felhúzni semmivel sem hosszabb idő, mint a live cd-s verziót eljátszani (minden "rizikójával" együtt).

Hát az attól függ, milyen érzékeny adatok kerülnek rá. Ha az adott disk csak erre az ideiglenes másolatra van szánva, akkor wipe-olni is lehet. Ha kevésbé érzékeny, akkor format,de ez esetben meg ugye minek a titkosítás :D Szóval a wipe általában jó eredményt hozhat, ha körültekintően csinálja az ember.

szerk.: ha más is lakozik azon a winyón, amit nem kéne törölni, akkor lehet még "szelektív" wipe adott fájlokra, de ez utóbbiban tapasztalatom nincs, láttam már embert, aki olvasta a nessönelben, hogy valaki látott már ilyet... :)

Az érzékeny adatokat én első körben felülírnám az /dev/urandom-ból, majd törölném, az összes törlése után pedig a teljes szabad helyet csapnám mégegyszer felül ugyanonnan. Célszerűen az összes(!) szabad helyre ezt el kell játszani, amelyik partíción volt esélye érzékeny adatnak megfordulni. Ugyanígy a swap-területet is illendő felülcsapni random adatokkal - természetesen egy swapoff -a után.

+1, a dd itt pláne hülyeség - visszamásolni nem nagyon lehet, fölöslegesen visz minden sz@rt meg az üres helyet is (nem, az hosszabb ideje használt diszknél általában nem csupa nulla bájt, ergo tömörítésnél a többi állományhoz hasonlóan fog viselkedni).
Fájlszinten menteni a /etc-t, a /home-ot minimum, meg esetleg azokat a helyeket, ahol még saját adatok vannak/lehetnek, aztán gyalu, cryptodevice-ra telepítés, majd visszamásolni a mentéseket - a mentett /etc-t persze egy másik könyvtárba, és összediffelni a telepítés utánival, és amit kell, csak azt visszarakni.

Az újratelepítésben nem maga a telepítés a necces, hanem az utána való visszatöltés és beállítgatás. Pláne, ha ez egy produktív gép, akkor necces lehet az időbeni kiesés. Mindenesetre én is efelé hajlok, bár így megvárom már a 10.10-es verziót. Az Ubuntu az alternate telepítővel kényelmesen megoldja a titkosítást ilyenkor a dm-crypttel.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

Ha az etc és egyéb konfigjaid le vannak mentve, akkor már csak annyi a teendőd, hogy reinstall előtt nyomsz egy ilyet:


dpkg --get-selections > csomaglista.txt

Majd reinstall után:


apt-get install dselect #ha meg nem lenne fent
dpkg --set-selections < csomaglista.txt
dselect #feljon egy menu, nyomsz neki install-t

Ezzel máris telepítettél mindent, ami eddig fent volt.
Ezután jöhet az etc-k diffelése, stb (fent leírtak).
Nem egy hosszú idő, és simán vissza lehet állítani vele mindent.

Időbeni kiesés meg simán lehet disk hibából is, amire nem tudsz felkészülni. Ha titkosítani akarsz, akkor számolnod kell azzal, hogy 1-2 órát el fog venni az életedből, de ezt egy sima dist-upgrade is elveszi. Valamit valamiért.

Oké, teljesen igazad van, ez a téma amúgy sem ismeretlen a Debian Sid-es korszakomból.
Azt hiszem, fogok találni olyan hétvégét, amikor ez az időkiesés nem okoz problémát.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

( vl v | 2011. 08. 14., v – 05:18 )

t410, i5 2.4ghz, full enkriptált diszkkel használom.
eleve így telepítettem, igaz, gentoo van rajta, saját tákolású initrd scripttel.

nálam úgy néz ki a struktúra, hogy partíció, rajta luks device, rajta lvm, abban lv-k, azon ext4 (meg van egy swap is)

összesen három partíció van:
egy /boot ext3, ott lakik a grub, a kernel, és az initrd.gz
egy enkriptált lvm konténer, benne a gép rendes fájlrendszerei (/, /var, stb.)
egy másik enkriptált lvm konténer, benne a privát adatok fájlrendszerei

így kell egy jelszó a gép bebootolásához, plusz van egy másik a privát adatokhoz. ez utóbbiakat a már bebootolt gépen egy scripttel lehet elérhetővé tenni, ha akarom.

illetve kb. milyen teljesítményromlásra számíthatok?

ehhez hozzá tudok szólni: normál "asztali" felhasználásnál nem érzékelhető a teljesítményromlás. gyakorlatilag nem volt olyan szituáció, amikor észrevettem volna bármit, ugyanakkor a t7200-as előző gépemhez képest mindenben jóval gyorsabb.

a tpm a fentiekhez szerintem nem is kell, és nem is hasznos.

Az álmoskönyv szerint a merevlemez titkosítását transzparens módon meg tudja oldani a TPM is a BIOS-ból vezérelve, de teljesen még nem sikerült megbizonyosodnom róla.
A kódoláshoz AES-t használnék, mert azt hardveresen is tudja processzor, ha pedig TPM még valami hasznosan hozzá tud tenni ehhez, az csak jó. :)

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

TrueCrypt jó dolog, de tapasztalatom szerint használhatóságban a Linuxos változat mindig elmaradásban a Windows-oshoz képest. Továbbá nem vagyok biztos benne, de mintha nem lenne használható boot időben és nem tudná titkosítani a root fájlrendszert.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

( uid_2716 | 2011. 08. 14., v – 21:10 )

illetve kb. milyen teljesítményromlásra számíthatok

Ha van olyan alkalmazásod, amely szeret fsync()-et hívni, akkor az fsync idejére lényegében meg fog állni a géped. Én ezt mind ext2-n, mind ext4-en tapasztaltam.

Ez volt a szerkezet: legalul két partíció, egyik a /boot-nak, a másik LUKS-nak. A LUKS dev-ből lett LVM PV, amelyen belül LV-k vannak, amelyekre pedig a file-rendszerek kerültek.

Időnként fut a recollindex, ami szeret a frissítés végén egy jó nagyot fsync()-elni. Na ezalatt megáll a thunderbird, a firefox, az egér, minden. Megmértem strace-szel, az fsync() rendszerhívás futásideje (amely alatt minden állt, mint a szög) 6-13 másodperc volt.

Megpróbáltam az fsync()-elt adatbázist másik LV-re, másik fs-be rakni, de az sem segített. Ennek oka pedig az, hogy az IO scheduler, ami közvetlenül a diszken ül, a kcryptd felől érkező request stream-et már összefuttatva, egyetlen stream-ben látja. A kcryptd felett ülő két LV ill. két fs kettéválasztottsága nem jut el az IO ütemezőig. Ezért az fsync() feltart mindent, olyat is, amihez igazából nincs köze.

Erre találtam valami "bizonyítékot" is egy levlistán, de most nincs meg a link. Mindenesetre az adatbázis kiköltözött egy titkosított pendrive-ra (nem nagy, és a pendrive-on az fsync akármeddig is eltarthat, nem érdekel).

Valószínűleg jobban jártam volna, ha az sda2-ből közvetlenül PV-t teszek, és az LV-ket egyesével dugdosom LUKS-ba, és azokra teszem az fs-eket. Sajnos ebben sem vagyok teljesen biztos: ha az összes titkosítást fix N db kcryptd szál végzi, akárhány ilyen device van is, akkor bukta.

Ez egy webfejlesztői gép, szép nagy adatbázisokkal és PHP processzekkel. Természetesen mellette ez az általánosan használt gépem is, vagyis minden más megtalálható rajta, ami egy átlagos felhasználói gépen.
Ezt a teljesítmény-kiesést nem lehetne valahogy minimalizálni?

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

Két bug:

https://bugzilla.kernel.org/show_bug.cgi?id=17892
https://bugzilla.redhat.com/show_bug.cgi?id=451738

Az utóbbiból a 3-as komment alapján a legrosszabbnak az tűnik, amit én csináltam (egy db titkosított PV, több LV); esetleg próbáld meg a plaintext PV-t több LV-vel, LV-nkénti titkosítással, és az adatbázisokat tedd külön LV-re/fs-re.

( nevergone v | 2011. 08. 15., h – 10:57 )

A CPU által hardveresen támogatott AES kódolás milyen kulcsmérettel dolgozik?
Szerk: Ez alapján úgy tűnik, hogy szépen megy a 256 bites kulcshosszal, az pedig már elég biztonságos. :)
http://software.intel.com/en-us/articles/intel-advanced-encryption-stan…

Itt pedig jól látható a hardveresen támogatott AES titkosítás hatása: http://twitpic.com/66fryv

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)