Hikari: Arch Linux nad LUKS nad LVM a pam_mount (diskuse)

[Shadow]

Moc pěkný návod. Zejména GRUB 2 je zajímavý, i když je škoda, že neumí bootovat ze zašifrovaných oddílů. Bylo by dobré, kdyby i /boot mohl být šifrovaný (ideálně by měl být šifrovaný i zavaděč, ale to už bychom se museli vrtat v BIOSu).

[Nicky726]

Díky, snad se to bude někomu hodit. Přinejhorším mě, až se něco pokazí nebo až budu konvertovat zbývající stroje. Ještě mi tedy zbývá zazálohovat hlavičky oddílů s klíči LUKSu.

GRUB 2 dal celkem zabrat, nedařilo se mi najít návod na tu verzi co je v Archu a na wiki nebyly kroky potřebné pro LVM. Nakonec jsem to splácal ještě z nějakých návodů na Ubuntu (kde zas mají novější verzi a generované konfiguráky). Jednu chvíli jsem si celkem nadával, že jsem nenechal ten /boot na normální partici.

[Shadow]

Díky, snad se to bude někomu hodit.

Určitě, takových návodů není nikdy dost.

Ještě mi tedy zbývá zazálohovat hlavičky oddílů s klíči LUKSu.

Doufám, že zálohovat budete nějakým způsobem i vlastní data, ne jenom LUKS hlavičky. Vlastní zálohy (dat) by pak měly být také šifrovány, nebo alespoň bezpečně uloženy. Tady mohu doporučit třeba projekt Duplicity, který umí šifrovat zálohy (a umožňuje i rozdílové zálohování).

GRUB 2 dal celkem zabrat, nedařilo se mi najít návod na tu verzi co je v Archu a na wiki nebyly kroky potřebné pro LVM. Nakonec jsem to splácal ještě z nějakých návodů na Ubuntu (kde zas mají novější verzi a generované konfiguráky). Jednu chvíli jsem si celkem nadával, že jsem nenechal ten /boot na normální partici.

On se /boot obvykle dává jako samostatný oddíl... ale tohle alespoň s GRUBem 2 jde. Horší by bylo, kdybyste LVM i s /boot postavil nad šifrovaným oddílem.

[Nicky726]

Tak data zálohuji už nějakou dobu. Je to ale poněkud krkolomné, protože nemám dostatek místa. Fotky jsou na starém notebooku a hlavní data na navíc i na flashce. Koncem léta plánuji pořídit notebook, takže bych pak měl plus mínus aktuální všechna data šifrovaně na dvou místech.

Na duplicity se ještě důkladně podívám, bylo by pak zřejmě možné využít k zálohování i nějaké veřejně dostupné služby, jestli dobře chápu, co jsem zatím zběžně pročetl. Zřejmě by šlo tento nástroj použít i na data na flashce, ale tady by asi bylo lepší použít true-crypt, který lze využít i ve windows, jen nevím, nakolik potřebuje admina, kterého ve škole nemám.

Co se týče převodu mé "pc infrastruktury" na šifrování, jsem stále ještě v začátcích.

[Shadow]

Duplicity umí ještě i komprimovat, na to jsem zapomněl. Výstupem je halda komprimovaných, šifrovaných souborů, které lze přenášet přes různé protokoly (typicky scp), takže to lze použít i pro _bezpečné_ vzdálené zálohování. Samozřejmě je možné zálohovat na localhost (protokol file://) a je možné šifrování vypnout (volba --no-encryption).

Podobným nástrojem je rdiff-backup, ale ten neumí šifrovat (AFAIK ani komprimovat). Funguje nicméně poměrně zajímavě - k aktuálním datům se dostanete přímo (ta jsou zrcadlena), rozdíly si zapisuje do vlastní adresářové struktury. K datům se tedy dostanete snadno přímo (tj. k aktuálním) a k dřívějším pomocí příslušného nástroje.

Tyto nástroje je vhodné použít pro zálohování. Pro šifrování dat, ke kterým častěji přistupujete, lze použít Truecrypt pokud chcete multiplatformní přístup (ještě by šel použít LUKS+FreeOTFE, ale ten u LUKS kontejnerů AFAIK neumí LRW/XTS, to byste musel kontejner šifrovat starším módem cbc-essiv), jinak lze uvažovat kromě LUKS o EncFS, šifrovacím souborovém systému (FUSE).

Jinak v souvislosti se šifrováním nemohu nepřipomenout Rubberhose cryptoanalysis (komiks).

[Nicky726]

Děkuji za tipy. Rdiff-backup jsem celkem spokojeně používal jako obdobu macovského Time machine. V ideálním případě by to však chtělo mít k dispozici externí disk (no snad jednou bude). Několikrát mě to zachránilo, když jsem omylem smazal to, co jsem neměl.

No je fakt, že kdyby to došlo tak moc do tuhýho, jak naznačuje ten komiks, byl by nejlepší asi v pravý čas odjištěný ruční granát.

[xkucf03]

Ad komix: to se bohužel v některých západních „vyspělých“ zemích můžeš stát, tam ti neuvěří, že jsi zapomněl heslo.

[Zdenek]

Nemusite se vrtat v BIOSu, staci kdyz PC ma TPM a tusim, ze existuji nejake patche pro GRUB.

[petr_p]

Máte někdo s TPM zkušenosti?

[xkucf03]

Špatný ohlas na WD Green Power v Linuxu?

BTW: já jsem to pojal trochu jinak – zašifroval jsem celý disk (kromě /boot) a až nad tím, jsem vytvořil LVM a logické svazky.

[Nicky726]

Tak vytvořit LVM až nad šifrovaným diskem na Hikari nemohu. PC využívá více uživatelů a já nemůžu zajistit, že všichni budou mít dostatečně silné heslo. Takto jsou jednotlivé oddíly chráněny různými hesly a pokud si jiný uživatel zvolí slabší heslo, neohrozí to má data v /home/nik, která chrání silnější heslo.

LVM nad šifrovaným diskem ale plánuju použít na budoucím notebooku, který budu používat jen já.

Jinak špatný ohlas WD Green Power v Linuxu se tu probíral v několika blozích před nějakým časem a na netu se dá najít dost různých zpráv. Rozhodl jsem se, že radši nebudu riskovat.

[Shadow]

Rozhodl jsem se, že radši nebudu riskovat

A dobře jste udělal (viz níže).

[Shadow]

Jo, WD Green jsem si koupil do RAIDu a jeho vrácení mě stálo 4 stovky. Problém je v tom, že používá tzv. inteligentní parkování, které je ovšem navrženo pouze pro Windows, který na disk zapisuje častěji (hlavičku disk parkuje ve výchozím stavu za 6 sekund nečinnosti).

V Linuxu to dopadá tak, že se šest sekund nic neděje, disk zaparkuje hlavičku, pak systém k disku přistoupí, hlavička se odparkuje, něco málo se přečte/zapíše, a tohle se opakuje, dokud za několik měsíců nedojde k překročení 300000 load/unload cyklů, které by tento disk měl oficiálně zvládat. Jinými slovy, inteligentní parkování v Linuxu funguje tak, že se disk uparkuje k smrti.

Ano, řekneš si, není problém, prostě mu přes hdparm -B 255 vypnu power management, a parkovat se nebude. Jenomže ono to nejde... jde to jedině nástrojem od výrobce, přičemž maximální nastavitelná doba nečinnosti je nějakých 25,5s nebo kolik.

WD na protesty reagoval tak, že podporuje jenom Windows, čímž přilil olej do ohně. Nakonec snad pod tlakem nějakých firem, co prodávaly linuxové NAS s WD Green disky, vydal nějaký nový firmware, který ovšem dle některých způsobuje jen to, že vypíná _počítání_ load/unload cyklů ve SMART, ale disk vesele zběsile parkuje dál.

Bohužel jsem na tohle přišel pozdě (protože jsem dlouho řešil defektní řadič), takže jsem disk vrátil se známkami používání, takže jsem platil 4 stovky, aby si ho ode mne vzali, a já si mohl koupit nějaký jiný. Tím jsem s WD na dost dlouhou dobu skončil.

[petr_p]

Narazil jsem na chybu, která se asi dlouho neprojevila, že když mám šifrovaný swap přes cryptoloop a zaberu fyzickou paměť přes mmap, tak v lepším případě mi jádro zabije daný proces, v horším případě upadne správa virtuální paměti a nezbývá než sysrq-boot. Není to ale stroprocentě reprodukovatelný, i když s vysokou pravděpodobností.

Nesetkal jste se s tím někdo? Nevíte, jestli to je vlastnost, nebo chyba cryptoloopu?

[Shadow]

Z čistě funkčního hlediska se mi to jeví jako bug. Já bych to zkusil naboznovat. Ale je otázkou, jestli dnes cryptoloop ještě někdo vyvíjí, když máme dm-crypt.

[Salamek]

jé uplně ten stejný šrot (HDD) proháním ve svém PC :-P

[Nicky726]

Tak doufám, že pevně drží...

Teď už je upgradovat ten můj šrot nad tím diskem.

[Salamek]

jj drží sestatečně , na ty mé uptajmy