Zaděláváme si na problémy, aneb šifrujeme root oddíl. (diskuse)

[Thunder.m]

Stále čekám až to bude v Ubuntu jednoduše klikacím způsobem možné nastavit, pak si to dám na notebooka :) Na normálním PC to nemá význam dávat.

[Käyttäjä 11133]

V openSUSE 10.2 je to klikací, ale jen pro některé oddíly. Bohužel

[Thunder.m]

Mě zajímá jen root oddíl, na notebooku ani jiné oddíly nemám, ten tam myslím nejde šifrovat, ne?

[Käyttäjä 11133]

ee, bez nějakých úprav (které popisuju zde v článku, případně v tom odkazovaném) to nejde.

[zde]

Předpokládám že když neprovozuju samostatný /boot oddíl, tak se s upravováním initrd a pokusy o šifrováním rootu ani nemusím namáhat.

[Käyttäjä 11133]

EE, leda ža by si už nechtěl nabootovat

[r]

jednoduche a skoro klikaci to uz je, viz muj link nize

s tim notebookem pozor - pokud pojedes nekde mimo cr, tak si over, jestli je to tam povolene, nektere (pochybne) zeme takoveto sifrovani zakazuji (a kontroluji notebooky na hranicich), ci aspon maji v zakonech povinnost to uradum na prani desifrovat (imo francie, ...) jinak se jde do vezeni :)

[Mrkva]

A proto echo "Zadejte heslo pro oddil \"/\"!" nahradime echo "Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,3) a na hranicich reknes, ze jsi asi misto cat /dev/urandom > /dev/hda3 napsal cat /dev/urandom > /dev/hda4 :)))

[Luk]

Blbost. Takové státy nestojí za to, aby tam člověk jezdil

[msk]

Prosim? To ako nejaky podolebilny colnik s nulovym technickym vzdelanim mi ( protipravne ) odoberie notebook, zapne ho ( a porusi tym dalsi milion medzinarodnych dohod a zakonov ) a bude rozumiet boot hlaskam linuxoveho kernelu? To sa mi nejak nezda. Koniec koncov, uz som sa nad tym ( zakazom sifrovania v niektorych fasistickych krajinach ) zamyslal a dospel som k zaveru, ze jediny sposob, ako ( na pripadnom sude ) dokazat, ze data su zasifrovane, je uspesne ich desifrovat. Inak je to proste binarny bordel, u ktoreho nikto nedokaze, ze je to zasifrovany realny obsah. Takze tak ako tak, je to len velke bububu technicky nevzdelanych poloblbov ( politikov ).

[mseed]

Ja bych resil zabespeceni vytvorenim partisny pro data ktere chci zasifrovat a pouzit truecrypt. + nebudu mit spomalen system (rezie pro sifrovani/desifrovani rootu) a data budou v bezpeci

[Käyttäjä 11133]

Ale ne všechna. Systémové logy, logy z IM komunikace, cokoli. Občas některá data třeba nepovažuješ za citlivá a ve skutečnosti citlivá být můžou a uvědomíš si to až je někdo zneužije.

[mseed]

To je sice pravda, ale kdyz ti nekdo ukradne notebook, tak uz asi logy moc resit nebudes a budes rad ze se ti nedostane do tvych fotek, zdrojaku, atd... A nebo zasifrovat /home + /var by mohlo stacit.

[Käyttäjä 11133]

A co tmp? nebo swap (vím, neřeším to ani v tomto článku, musím teprve nějaké šikovné řešení vymyslet) ?

[mseed]

tmp bych mazal pri kazdem vypnuti - jednoduchej scriptik, a swap bych asi neresil

[Käyttäjä 11133]

A 50x přepsal náhodnými daty, že? To se ti pak ale bude vypínat dlouho..

[Michal Kubeček]

"Jednoduchej skriptík" vám tak nanejvýš smaže soubory, ale data tam nechá. Pokud tedy nemyslíte přepsání celého zařízení nulami a znovuvytvoření filesystému, což je ale pomalé.

Pro /tmp a swap se někdy používá finta, že se používá náhodný klíč, který se vygeneruje vždy před použitím a který nikdo nezná. Samozřejmě je nutné pokaždé před přimountováním znovu vytvořit filesystém resp. provést mkswap.

[Käyttäjä 11133]

A tam nastává problém se suspend to disk :-/

[David Jaša]

Použij na /tmp tmpfs a pak budeš řešit jenom šifrovaný swap.

[xkesh]

Na T60 jsem nechal openSUSE 10.2 šifrovat /home na extra partici - bohužel to dělalo při startu potíže s distribučním jádrem (2.6.18.x), bootování se velmi často v nepravidelných intervalech prostě zaseklo. Jádro jsem aktualizoval na novější (2.6.22), což problém vyřešilo... a teď si zas můžu nechat zajít chuť na wifi (anebo si ručně dokompilovat ipw moduly)...

[onion]

Nevim co mas za wifi chipset, ale T60 by mohla mit s velkou pravdepodobnosti Intel 3945, ktery naprosto bez problemu na 2.6.22 funguje (jen je treba udelat par zmen oproti 2.6.18 - vypnout user-space daemona a modul ipw3945 neni treba, staci mac80211).

[xkesh]

Nevim co mas za wifi chipset, ale T60 by mohla mit s velkou pravdepodobnosti Intel 3945, ktery naprosto bez problemu na 2.6.22 funguje (jen je treba udelat par zmen oproti 2.6.18 - vypnout user-space daemona a modul ipw3945 neni treba, staci mac80211).

Ano, je to Intel3945 - jen netuším, o čem konkrétně je v případě "user-space daemona" řeč, a tím pádem tedy ani jako ho "vypnout" :( Nějaký další hint? Díky.

[onion]

Princip je v tom, ze drive to fungovalo tak, ze regulace vykonu a podobne veci byli obsazeny v closed-source userspace daemonovi a ovladac proto mohl byt open-source. Nyni se kod z closed-source daemona presunul do firmwaru (je treba updatovat firmware), ktery je samozrejme uzavreny (kvuli FCC -> cilem narizeni je, aby user nemohl menit napr. vysilaci vykon). Kod open-source ovladace je nyni soucasti mac80211. Tudiz daemon uz neni treba a specialni modul uz take ne. Jmeno daemona bych odhadnul treba na ipw3945d a modul ipw3945? Presne nazvy neznam.

[xkesh]

S dovolením bych pokračoval tady.

[Michal Kubeček]

Cryptoloop není příliš vhodná volba, protože je z kryptografického hlediska chybně navržen, doporučil bych spíš dm-crypt (v aktuálních verzích jádra a s vhodným nastavením) nebo loop-aes.

[Käyttäjä 11133]

Hmm jdu to překopat. :-/

[Cohen]

Pak dej prosím vědět, co všechno a jak bylo třeba změnit.

[Käyttäjä 11133]

Když řeknu všechno nebudu zrovna daleko od pravdy :-/

[r]

tak tak :)

treba nejak takhle

[Jiří Veselský]

nějaké audiovizuální díla vlastní tvorby, které byste neradi svěřili do cizích rukou

Tož řeknu rovnou "domácí porno", ne?

[Käyttäjä 11133]

[Jiří Veselský]

No teď jsem si přečetl tu tvou patičku a konečně chápu, proč bys ta "audiovizuální díla vlastní tvorby" nerad svěřil do cizích rukou...

Mimochodem, já bych také některá "audiovizuální díla vlastní tvorby" nerad dával z rukou - konkrétně nahrávky mého zpěvu by byly podle všech mezinárodních zákonů a úmluv považovány za zbraň hromadného ničení.

[otula]

No, pokud jde o patičku, tak by odkazovaná stránka mohla mít nějakou ochranu proti spamu v komentářích

[Käyttäjä 11133]

Proč by měla? Vždyť to je přesně to o čem ta stránka je... Spíš by měla mít ochranu proti hlavičce 301 HTTP protokolu, kterou zdárně používám

[otula]

Boha jeho, já si dnes sedím na vedení. Měl bych se zvednout a trochu nadýchat čerstvého vzduchu (po 3 týdnech dovolené je to v práci únavné )

[disorder]

301 nie je hracka, niektore browsery si ho dost tvrdohlavo drzia v pamati -- nehovoriac o proxy, na ktore uzivatel nema vplyv...

[Cohen]

Pěkný článek. Na něco podobného se už delší dobu chystám, nicméně lenost zatím vítězí na paranoiou. Zatím šifruju jen opravdu citlivá data a / nechávám svému osudu.

Už dřív mě napadla ještě jedna věc. Vzhledem k tomu, že nelze šifrovat /boot, tak hrozí, že vám někdo předhodí podvržené jádro a odchytí si tak zadávané heslo. Bylo by tedy asi vhodné nějak pořešit buď nošení obsahu /boot na USB klíčence, nebo doplnit skript (uložený až v šifrovaném oddílu, aby nebyla možná jeho modifikace/odstranění), který po startu zkontroluje kontrolní součty souborů na /boot a v případě nalezení rozporů upozorní uživatele. Krádeži hesla to sice nezabrání, ale pokud by to bylo uděláno ještě před startem sítě, tak to zabrání jeho odeslání a uživatel může situaci řešit.

[vencour]

Dík za inspiraci, i na tohle jsem se ještě nedostal. Možná nemám co skrývat, ale je to moje soukromí a tedy i moje právo.

[xm]

Z tohoto článku si prosím nikdo neberte příklad (byť je dobře napsaný)!

Cryptoloop je již hooodně dlouho obsolete (byl chybně navržen a má i další své problémy, podstatně lepší náhrada za něj v jádře je dm-crypt).

Autore, prosím uveď někde hned na začátku článku _tučně_ upozornění, že tento postup (a obecně cryptoloop) by nikdo neměl pužívat. Místo toho doporuč lidem dm-crypt (přímo v jádře) nebo TrueCrypt (ten sice přímo v jádře není, ale je také kvalitní).

Cryptoloop je mrtvý!

[jnc]

dm-crypt by som nedoporučoval - s defaultovými parametrami je rovnako deravý ako cryptoloop :)

buď LUKS s essiv, alebo (ešte lepšie) loop-AES

[xm]

Proč nedpoporučoval? Jen ho člověk musí umět správně nastavit, toť vše. Loop-AES je dnes bv době dm-cryptu a TrueCryptu IMHO zbytečná mrtvola...

[Käyttäjä 11133]

Když má pro x86 implementaci v ASM tak bych ho za mrtvolu nepovažoval.

[Ritchie]

Dmcrypt sám o sobě nezná žádné šifry, ale využívá crypto-api jádra. Jedna z implementací šifry Rijndael v jádře je napsána v x86_64 asembleru. Nějaký opravdový důvod, proč používat loop-aes?

[Michal Kubeček]

Technická poznámka: LUKS je jen nadstavba nad dm-crypt, která přidá možnost používat jeden master key a několik uživatelských. Takže LUKS není o nic bezpečnější než dm-crypt, který používá.

[onion]

Muzes konkretne specifikovat co mas na mysli? Diky ;) (dm-crypt totiz pouzivam a tudiz me to dost zajima :P )

[Michal Kubeček]

Je o tom zmínka v tom článku, na který jsem tu dával odkaz dopoledne. Ale jestli se použije LUKS nebo čistý dm-crypt, to na tom nic nemění.

[David Jaša]

A stejně: proč šifrovat / ? Osobně bych spíš šel cestou šifrované zvláštní partition, do které by byly nalinkované citlivé adresáře...

[hehe]

dmcrypt

[Jan Kurik]

Jeden takový nápad k vytvoření USB tokenu z autorova TODO listu:
Nebylo by jednodužší udělat bootovatelný USB klíč, s jádrem a ramdiskem ? Po nabootování jádra z USB a připojení šifrovaného / , na pevném disku, by se klíč mohl vytáhnout, neb by již nebyl potřeba.

[Jiří J.]

Velmi pěkné video jsem kdysi našel na ftp AVC Silicon Hill (už nějakou dobu tam ftp zřejmě nefunguje), nicméně jsem si dal práci jej vyhledat.. postaršího data, však osvětluje základní principy...

[Käyttäjä 11133]

Odkazuju na něj v blogpostu

Ještě bych si dovolil upozornit na trošku zaprášené video.

[Jiří J.]

Že já nečtu důkladně