Dotaz: Neví někdo důvody RedHatu, že zahodil podporu ecryptfs?

[petr]

Zdravím,

zkouším centos 7 a zjišťuji, že dodávaný kernel nemá zkompilovanou podporu ecryptfs. Google mi akorát řekl, že redhat zahodil pro RHEL 7 podporu a v jejich Administration guide je akorát, že se mám podívat do Security Guide, kde o tom není zmínka.

Velice by mě zajímali jejich věcné důvody: je v ecryptfs nějaká zranitelnost? Nemá dostatečnou podporu komunity nebo něco?

Jejich vysvětlení, že mám použí dm-crypt, dm-crypt je lepší...nebaví mě zadávat passphrase a pak ještě heslo pro přihlášení, ecryptfs je prostě pohodlnější a elegantnější, navíc ho můžu použít na jakémkoliv fs - používám zfs a to má raději, když má přístup na disk přímo, ne přes nějakou vrstvu.

Prostě ecryptfs není podřadný dm-crypt, z uživatelského hlediska funguje jinak - je to prostě funkcionalita, kterou redhat zahodil a fakt bych chtěl znát důvody...

[conspiracy?] Nebo snad je ecryptfs tak dobré, že NSA to redhatu nakázala? :-O [/conspiracy?]

Díky

Odpovědi

[pavlix]

Je nějaký důvod, proč by to nešlo zabalit do EPEL7?

[petr]

Podpora je v kernel-plus z centosplus repozitáře. Ale můj dotaz není, jak to zprovoznit, ale proč to redhat vyhodil. Když to měl v rhel 6 jako tech-preview, tak proč to v následující verzi zavrhl. Ty důvody by mě zajímali. Dm-crypt má své použití a ecryptfs zase jiné, nedělají to stejné, takže redhatí odpověd lidem v mailing listu, že mají použít dm-crypt je prostě špatná. Těm lidem dm-crypt nenahradí funkcionalitu ecryptfs.

[pavlix]

Pokud se firma rozhodne ve svém komerčním produktu něco nepodporovat, může to mít mnoho důvodů, ale pochybuju, že by zrovna k tomuhle bylo nějaké tiskové prohlášení. Klidně to mohli vyhodit jen proto, že to nikoho (zákazníky, management) nezajímalo.

[petr]

A nebo je to jak se slavným gnome3, něco si tam bastlí a až to pak vidí první zákazník, tak musí rychle přibalit pár extensions a udělat gnome-classic mode, aby to aspoň trochu připomínalo gnome2 a bylo trochu použitelné (RHEL 7 will be a KDE Desktop). Takže pochybuji, že svůj plán pro RHEL 7 dělali na základě reakcí zákazníků, ale tak je to jen moje spekulace samozřejmě. Mně stačí vidět, co si protlačili kolem systemd, abych si utvořil názor.

[pavlix]

Řekl bych, že gnome a systemd jsou projekty s poněkud zvláštním postavením.

[ohlol]

je tam jeden postaveny vedle druheho? nebo jak to bylo zamysleno?

ale zpet k puvodnimu dotazu... asi nekdo videl dalsi uzasny neprilis provereny zpusob jak potencialne ztratit data a jeste to podporovat, tak u te predstavy behem prvnich peti minut co ho to paralyzovalo zesedivel a pak si vytrhal vsechny vlasy a nakonec prisel na to, jak to vytrhnout z RHELu.

[Tom K]

Jeden z důvodů by mohla být ne zcela 100%ní stabilita na NFS a v podobných situacích. Sám jsem ecryptfs zkusil používat, ale v některých případech byly výsledkem rozbité soubory na NFS.

[petr]

Hm, tak je to možné, že se to na nfs rozbije, takhle by mě to asi nenapadlo použít. Pro běžné použití to ale funguje dobře, přešel jsem na tento způsob šifrování domovského adresáře na debianu a je mi to mnohem milejší než dmcrypt. Žádný problém jsem dosud neměl. Navíc to mám na raidovaném zfs a každý blok ve třech kopiích, takže se moc nebojím, že bych o vše přišel (zfs má checksumy a umí vadné bloky opravit).

[VK]

Cryptsetup + LUKS se dá také nastavit "pohodlnější", stačí si přečíst manuál. Ale pohodlí snad není tou nejdůležitější vlastností šifrovacího systému, a často bývá na úkor bezpečnosti. A označit cryptsetup za podřadný :-o

[petr]

Špatně jsi mě pochopil - já nenapsal, že dmcrypt je podřadný, ale že ecryptfs není podřadný (komu čemu).

Cryptsetup + LUKS se dá také nastavit "pohodlnější"

... takže se to dá nastavit tak, že zapnu pc, to nabootuje bez interakce, zobrazí se mi přihlašovací obrazovka, já se přihlásím a ono se to napozadí rozšifruje mým uživatelským heslem?

Cokoli jiného už odmítám, mám na nb zašifrovaný celý systém a prostě mě nebaví to zapnout, čekat až se objeví výzva cryptsetup, zadat frázi a znovu čekat než to nabootuje, abych se mohl zadat další heslo pro přihlášení a zlepšováky s připojenou flashkou prostě nejsou tak pohodlné...a ano bezpečnost může být pohodlná, proč zadávat dvě fráze, když k tomu stejnému účelu (zašifrovat domovský adresář) stačí jedna?

[Mac_CZ]

Tohle by měl řešit pam_mount.

[petr]

Abych ale měl zachované schéma [ fyzický disk | zfs | něco | rozšifrovaný domovský adresář ] tak bych musel pro dmcrypt pravděpodobně vytvořit nějaký loopback soubor, které by byl uložen na zfs. Nechci a není vhodné, aby zfs bylo až nad tím, protože to pak nepodchytí hw chyby disku, ale akorát se rozbije šifrovací balast pod tím a přijdu o všechna data.

Prostě dokud zfs nebude mít vlastní šifrovací mechanismus, což si myslím je na cestě, tak prostě ecryptfs je nejlepší varianta.

[Jendа]

Nechci a není vhodné, aby zfs bylo až nad tím, protože to pak nepodchytí hw chyby disku, ale akorát se rozbije šifrovací balast pod tím a přijdu o všechna data.

dm-crypt v XTS módu při chybě disku zničí jenom jeden blok, což je u AES 16 bajtů.

[petr]

Což pořád zamrzí ne? Pár takových děr a sbírka rodinných foto je znehodnocena... Se ZFS se současnou konfigurací nepřijdu o nic, pokud oba disky nebudou děravé jak řešeto.

[Jendа]

Myslíš, že se ten ZFSkový checksum vyrovná s otočením jednoho bitu, ale už ne s otočením 128 bitů, tj. jde ti jen o silent data corruption? Jinak HW failure disků se mi většinou projevoval neschopností přečíst celý blok, takže tam je nějakých 16 bajtů nevýznamných.

[petr]

Ano, jde mi o silent data corruption. Když po letech člověk zjistí, že v jeho sbírce mp3 jsou některé skladby "vylepšené" šuměním, prskáním a jinými "remixy", tak už svá data nesvěří žádnému zastaralému fs, které neumí něco tak zásadního, jako zajištění konzistence dat.

[dustin]

Jak se takový šum při změně pár bitů v MP3 do dekódovaného WAVu dostane? Máš nějaký příklad takového souboru? Praskání si dovedu představit, ale šum?

[petr]

To spíš nedostatek slovní zásoby na mé straně, nebo lenost to lépe popsat - ten soubor jsem už přepsal funkční verzí - konec skladby se přerušil hlasitým bzučením (to jsem nazval šum) a ten trval až do konce.

[Jendа]

Ano, jde mi o silent data corruption.

No ale já jsem se ptal, jestli algoritmus pro detekci/opravu chyb u ZFS pracuje po bitech a ne po nějakých větších blocích.

[JanM]

po blocích.

každý blok má kdesi checksum, ta checksum je v jiném bloku, který má vlastní checksum a tak stále až na úplně ten nejvyšší kontrolní součet ve "stromě". Takže je kontrola nejen konzistence bloku vůči kontrolnímu součtu, ale i kontrolního součtu samotného.

[marbu]

Pokud to chapu dobre, tak zfs i btrfs pocitaji pri zapisu checksum ke kazdemu bloku, ktery se pak pri cteni overuje. Takze je jedno, kolik bitu z toho bloku se otoci, fs to pozna (ignorujme ted moznost kolize checksumu) a bud hned ohlasi chybu a nebo muze zkusit platna data precist z dalsiho disku (podle typu pouziteho raid modu).

Takze mi prave neni uplne na prvni pohled jasne, co by se mohlo rozbit tim, ze zfs nebo btrfs dam na dm-crypt sifrovanou partition.

[Jendа]

On je to jenom error detection? To neumí error correction?

[marbu]

Ne, jsou to jenom ciste kontrolni soucty. Error correction se nekona (ono ony by ty opravne kody pak musely byt docela velke).

[pavlix]

Pokud kombinuješ kontrolní součty s duplikací dat mezi disky kvůli riziku výpadku disku, tak bys měl dostat error correction jako bonus. A z druhé strany k čemu je ti error correction, kdyby ti mohl odejít celý disk s jedinou kopií dat.

[marbu]

Jo, souhlasim - kontrolni soucty by tu nedavaly smysl. Jen jsem odpovidal na dotaz, aby bylo zrejme, ze tu jde pouze o checksum.

Ono muze byt matouci, ze jako checksum btrfs pouziva crc32c.

[lertimir]

Teoreticky by ECC mělo být k tomu, že to uživatel ví dříve, že je něco špatně i u jednoho disku a o data nepřijde.

Podle mne by to chtělo nějaké spolehlivější/rozsáhlejší informace o silent data corruption, které se budou týkat současných disků. Všechny současné záznamové systémy jak HDD tak SSD, což znamená, že není možné ze zařízení získat chybový blok s chybou v jednom či dvou bitech. Chyby v malém množství bitů jsou zachyceny ECC algoritmy v zařízení a opraveny. A pokud chyby jsou větší než ECC algoritmus dokáže korigovat, tak je zjištěn celý chybný blok. Pravděpodobně triger na relokaci bloků je právě založen na překročení nějaké hranice, kterou ECC je schopna vyřešit, ale je již natolik vysoká, že je blízko meze, po jejímž překročení ECC již vyřešit není možné. Jeden z hlavních důvodů pro zvýšení velikosti bloku z 512b na 4k bylo snížení velikosti redundantní informace pro CRC. Nemožnost málobitových chyb v blocích je za předpokladu, že vlastní řídící elektronika HDD/SSD je v pořádku. Pokud není elektronika v pořádku, tak je pak otázka s jakou pravděpodobností nastávají její poškození takové, že generuje bitové chyby a jinak se tváří OK.

[lertimir]

Insert: Všechny současné záznamové systémy jak HDD tak SSD mají ECC korekce,...

[VK]

OK, s tou podřadností jsem to možná nepochopil.

Tím pohodlnějším způsobem jsem myslel uložení dešifrovacího souboru na flashku, ale jak už bylo zmíněno výše, asi by šlo použít pam a dešifrovat pomocí přihlašovacího hesla (nezkoušel jsem).

Když jsem si asi před rokem vybíral způsob šifrování, přišel mi ecryptfs o dost pomalejší. A jak je to při změně hesla? Je to tak snadné a rychlé jako s Luksem, nebo se vše musí rozšifrovat a znovu zašifrovat?

[Jendа]

asi by šlo použít pam a dešifrovat pomocí přihlašovacího hesla (nezkoušel jsem)

Samozřejmě. Koneckonců existuje pam_exec, který umožňuje spustit vlastní skript - můžeš si tak zařídit odemykání jenda-cryptu nebo třeba dveří.

A jak je to při změně hesla? Je to tak snadné a rychlé jako s Luksem, nebo se vše musí rozšifrovat a znovu zašifrovat?

encfs používá stejný mechanismus jako LUKS, doufám, že ecryptfs taky.

[petr]

Jak jsem psal, fígl s flashkou znám a rozhodně za pohodlný nepovažuji. Mně na dm-cryptu prostě vadí to, že funguje pod fs a já chci mít naspodu zfs - co se týče rychlosti - vůbec to nepozoruji, nevidím žádný rozdíl mezi startem z nešifrovaného adresáře a z ecryptfs. Vůbec jsem ještě na ecryptfs čekat nemusel - je tedy pravda, že filmy mám mimo domovský adresář, tam by se to možná projevilo.

[Šangala]

Bo neznám ecryptfs (používám jen LUKS a encfs), tak přesně nechápu jak to myslíš, když to nastartuje bez interakce, tak to není zašifrovaný celý disk (nebo je, ale heslo si někde vezme) bo to ten disk už čte ne?

[trekker.dk]

Řekl bych, že šifrovaná mají být uživatelská data, tedy /home

[Šangala]

Jestli jen pro jednoho uživatele tak stačí jen jedno heslo a přihlásit automaticky a nemusí se nic řešit - je jedno heslo.

[Jendа]

Mně se nikdy display manager nepovedl nastavit tak, aby se sice automaticky přihlásil, ale když dojde k pádu X serveru, tak chtěl heslo (protože útočník s fyzickým přístupem mi shodí zamčená Xka).

[Šangala]

Nezkoušel jsem nevím, mně dvě hesla nevadí… a asi by mi tento problém nevadil, bo útočník s fyzickým přístupem, je stejně moc silný útočník…, to bych asi zkusil pam_mount

[Jendа]

a asi by mi tento problém nevadil, bo útočník s fyzickým přístupem, je stejně moc silný útočník

Mně se kolemjdoucí furt snaží nainstalovat backdoory, ale na coldboot si netroufnou.

[trekker.dk]

Hádám dobře, že to je myšleno jako ochrana proti útočníkovi, který shodil Xka, ale nechce si odnést disk nebo celý komp...?

[Jendа]

Disk ať si klidně odnese, k ničemu mu nebude.

Je to zamýšleno jako ochrana proti útočníkovi, který nemá koule nebo hardware na coldboot útok.

[Houvado]

A proc si nechavas moznost schodit Xka?

[Jendа]

Protože ještě nikdo nevymyslel implementaci X bez bugů.

[Houvado]

Hm. Znamena to tedy ze *getty nebo systemd nemaji bugy? Nebo ty umis shodit libovolna Xka?

[Jendа]

Znamena to tedy ze *getty nebo systemd nemaji bugy?

Neznamená a nechápu, jak jsi tuhle implikaci vyvodil.

Nebo ty umis shodit libovolna Xka?

Libovolná ne.

[petr]

Tak si to zkusit ještě jednou rychle přečíst - použití ecryptfs z uživatelského hlediska je úplně stejné, jako neřešit šifrování vůbec - zapne pc, nabootuje, objeví se přihlašovací obrazovka, přihlásí se a pam se postará o to, že se automaticky rozšifruje domovský adresář - ecryptfs funguje na úrovni fs, nikoli pod ním. Změnu hesla jsem zatím neřešil, takže to nevím, ale myslím, že to funguje jako luks, může být více frází apod.

[Šangala]

Jenže i opětovně mi tam falíruje:

Cokoli jiného už odmítám, mám na nb zašifrovaný celý systém a prostě mě nebaví to zapnout…

[petr]

Protože jsem mluvil o pc a zmínil nb - jinak řečeno mluvil jsem o dvou strojích, jedno používající cryptsetup a druhý ecryptfs

[ohlol]

mas mit gnome3, ktery te prihlasi bez zadani uzivatelskyho hesla pokud system splnuje hned nekolik podminek + nastaveni. zadas pak akorat heslo na desifrovani vseho(mimo boot initramfs to je jedina dira do systemu, kterou by melo hlidat TPM)

[Jendа]

Velice by mě zajímali jejich věcné důvody: je v ecryptfs nějaká zranitelnost?

Leakuje názvy souborů, časy přístupu, velikosti a další metadata.

Nemůžeš použít encfs?

[petr]

Aha, tak to jsem nevěděl, je někde nějaký chytrý dokument k tomu - např. proč nepoužívat ecryptfs?

Já našel akorát tento komentář, takže zatím zůstanu u ecryptfs: Nevertheless, I like the idea of using eCryptfs as it is supposedly faster and seemingly enjoys more widespread support. Additionally, if I've understood it correctly, the metadata is stored in the files themselves instead of EncFS's per-directory configuration file (.encfs6.xml). The files can therefore be decrypted as long as they exist, whereas EncFS files depend on an extra file that could be lost (unlikely with proper backups, but still possible).

[Jendа]

Aha, tak to jsem nevěděl, je někde nějaký chytrý dokument k tomu - např. proč nepoužívat ecryptfs?

Není, všechny důvody jsem popsal. Pokud tě zajímá attack vector, tak jsem ho popsal tady:

Sniffoval jsem u jednoho vládního objektu. Našli mi ten notebook, ale nepovedlo se jim dokázat, že je to fakt sniffovalo. Pak ale porovnali záznamy ze svého systému (logují si poslané SMS, komunikaci vysílačkama a čas otevření dveří RFIDama), respektive jejich timestampy, se souborama, které našli na disku, a ještě viděli, že dlouhá hlasová komunikace má megabajt, zatímco v čase, kdy procházely jen SMS, je tam spousta krátkých souborů. No a byl průser.

Já našel akorát tento komentář, takže zatím zůstanu u ecryptfs

To, že to leakuje metadata, si můžeš ověřit prostě tím, že na ten šifrovaný adresář pustíš ls -l.

[petr]

Trošku jsem zmaten, z toho vlákna tam píšeš to stejné o encfs, co jsi napsal zde o ecryptfs..a nebo který ten jenda jsi?

[Jendа]

ecryptfs je na tom ještě hůř (leakuje i názvy souborů), encfs leakuje „jenom“ adresářovou strukturu, velikosti a datum změny. EncFS jsem doporučoval proto, že není potřeba modul do kernelu ani support od RH, ale jede to přes FUSE.

[pavlix]

Tak v tom případě je to jasné. To jsem v diskuzi nějak nepostřehl, že tím hlavním zdůvodněním je potřeba podpory v kernelu.

[petr]

Vždyť jsem psal hned v první větě: dodávaný kernel nemá zkompilovanou podporu ecryptfs

Ta podpora byla přidána až na bugreport jiného uživatele centosu do balíčku kernel-plus v centosplus repozitáři, takže doteď to pravděpodobně v RHEL vůbec není bez vlastní rekompilace jádra.

[pavlix]

A jo, máš pravdu, ten kernel tam napsaný je. Ale je fakt, že zrovna na práci s jednotlivými soubory se mi kernelový modul taky moc nelíbí, i když jestli platí ten audit, tak to zas mluví spíše ve prospěch ecryptfs. No zatím to vypadá, že RH ve svým oficiálním jádře ecryptfs nepotřebuje, takže ano, je potřeba vzít buď centosí nebo vlastní build.

[petr]

S tím dokážu žít, jak jsem psal, jde mi hlavně o obsah souborů, adresářovou strukturu ať si cizinec třeba vytiskne. A pokud se encfs mountuje přes fuse tak to asi bude i znatelně pomalejší. RHEL instalovat/kupovat nehodlám, v centosu se to dá relativně nepracně rozchodit. Hlavně mě zajímali ty důvody, které redhat mohl mít, což jsi mi asi poskytl, i když oficiální zdůvodnění se asi nedozvím.

Do budoucna snad zfs bude mít zabudované šifrování a s pomocí pam se vyřeší rozšifrování s přihlášením.

A proč se tak vyhýbám dm-crypt pod zfs?: Rather than using dmcrypt and LUKS, which would bypass a lot of the features ZFS brings to the table

[petr]

Jinak ta leaknutá metadata mi nevadí, jde mi jen o to, aby si cizinec nesedl k mému pc, připojil sysrescd, nebo jinou živou distribuci a nemohl vesele vidět obsah souborů, pracovní dokumenty, maily atd. Na tom stroji nebude operovat příslušník anonymous, takže policejní návštěvy se neobávám.

[Houvado]

To zni jako povedena urban tale. Nabizi se totiz spousta zajimavych otazek. Napriklad jak mohli najit pasivni sniffer. Nebo jak dokazali, ze notebook je tvuj.

[Heron]

Poučení z té urban tale je ale jasné. Metadata matters.

[Jendа]

To zni jako povedena urban tale.

Ano, to se samozřejmě nikdy nestalo. Šifruju totiž celý blockdevice.

Napriklad jak mohli najit pasivni sniffer. Nebo jak dokazali, ze notebook je tvuj.

Ostraha objektu mě viděla, že chodím každý večer do parku naproti objektu do keře něco dělat a pak se tam šli podívat taky. Konkrétně měnit prázdnou baterku za plnou a plnou paměťovou kartu za prázdnou.

OT: Záznamy získané z Bravova [vrahova] iPhonu dokazují, že jeho majitel osudný den mezi časy 23:31 a půlnocí devětkrát použil funkci baterka.

[ohlol]

> Siri na to odpověděla otázkou „Jaké místo hledáte?“ a poté nabídla čtyři možnosti – bažinu, vodní nádrž, slévárnu kovů a skládku.

uz nekdo obvinil autory Siri ze spolupachatelstvi?

[marbu]

Pokud te to zajima, muzes si projit vysledky kratkeho auditu: EncFS a eCryptfs.

[petr]

Tak toto byl asi nejužitečnější komentář - děkuji. Ecryptfs má sice nedostatky, ale v porovnání s nabízeným encfs už nemám pochybnosti o správné volbě.

[marbu]

Jinak mel bych malou technickou poznamku, tady pisou:

eCryptfs is a stacked, cryptographic file system. It is transparent to the underlying file system and provides per-file granularity. eCryptfs is provided as a Technology Preview in Red Hat Enterprise Linux 6.

Kdyz je neco dodavane jako "technology preview", tak to znamena, ze si to muzes vyskouset a melo by to fungovat, ale neni obecne podporovane nebo doporucovane do produkce.

[petr]

Pro všechny fandy dmcryptu přikládám zajímavé čtení: Definitivně jsem skončil s šifrováním na úrovni blokového zařízení...

Nejsem znalec kryptografie, ale článek mě přesvědčil, že šifrování pod fs je prostě špatné.

[Jendа]

Bohužel na Linuxu neznám alternativu. Teda vlastně ne jen na Linuxu.

Článek rozebírá útoky, kdy útočník bude ciphertext na blockdevice měnit a bude koukat na výsledky. To v mém případě nehrozí. V mém případě si útočník může blockdevice přečíst právě jednou a pak o něj nejspíš fyzicky přijdu nebo ho minimálně celý přepíšu a začnu znova.

[Heron]

Nejsem znalec kryptografie, ale článek mě přesvědčil, že šifrování pod fs je prostě špatné.

Fajn a jakou jinou alternativu tedy budeš používat? Ani v článku není naznačená.

Resp. on doporučuje šifrovat zprávu (dřív, než se uloží do souboru), šifrovat data ještě před uložením do db apod. Tedy vesměs aplikace proudové šifry (pokud jsem to nesprávně pochopil, tak mě opravte).

Ale takhle se s daty nepracuje (resp. někdy vyjímečně ano a to pouze do určité velikosti). Se soubory se pracuje tak, že se mapují do paměti, kde se s nimi pracuje jako s jakýmkoliv jiným polem. Změním jeden byte na offsetu 64 GiB z celkem 200 GiB souboru (pokud by se vám tyto velikosti zdáli příliš malé tak si je vynásobte libovolnou bulharskou konstantou, na podstatě problému to nic nemění), systém souborů změní jeden příslušný blok a vyšle ATA příkaz do disku. Job done. Není vůbec možné při každé změně přešifrovávat celý soubor. Proto jsou nutné šifry na úrovni bloků diskového zařízení.

Na straně druhé jsou tady implementace nad úrovní systémů souborů, které zase pouští ven tuny metadat. Metadata jsou mnohdy důležitější, než data samotná.

A implementace ve FS samotném také nutně bude používat blokové šifry, protože se tak se soubory v operačním systému prostě zachází. (Každý soubor je současně i blokovým zařízením.)

[petr]

Napsat, že metadata jsou důležitější než data je snad jasná blbost. Že se dá z metadat hodně odvodit nepopírám, ale jaksi pro někoho, kdo jen nechce, aby mu cizinec ukradl NejlepšíLiterárníDíloSvěta.txt, mu ecryptfs poskytuje vše, co potřebuje. Šifrování nad fs je pro mě v současné době to nepoužitelnější - neomezuje mě to v práci, obsah mých souborů si nikdo nepřečte a jestliže zloděj uvidí SupertajnéMaily.msf, tak ať si to užije...

[Heron]

Napsat, že metadata jsou důležitější než data je snad jasná blbost.

... mnohdy ...

[pavlix]

If you’re an end-user looking for crypto advice: use Truecrypt, use Filevault, use dm-crypt. Also, use PGP, and Tarsnap. Read on only if you’re interested in crypto nerdery.

Ehm...

[petr]

Nevím, co je na tom ehm, prostě náhodného kolemjdoucího slušně odbyl a ostatní si mohli přečíst důvody, proč konkrétně dm-crypt apod. nepoužívat.

[marbu]

Tohle je ponekud odvazne tvrzeni. Primo tam stoji, ze pokud nerozumite kryptografii, nema cenu to dal cist :)

Btw ten eCryptfs take nesifruje soubor jako celek, ale po blocich - viz ecryptfs paper:

eCryptfs breaks the data into extents. These extents, by default, span the page size (as specified for each kernel build). Data is dealt with on a per-extent basis; any data read from the mid- dle of an extent causes that entire extent to be decrypted,

[pavlix]

Tohle je ponekud odvazne tvrzeni. Primo tam stoji, ze pokud nerozumite kryptografii, nema cenu to dal cist :)

+1

Btw ten eCryptfs take nesifruje soubor jako celek, ale po blocich - viz ecryptfs paper:

To by ale znamenalo, že ten stejný článek od ecryptfs odrazuje ještě více než od šifrování disků/oddílů.

[petr]

To je možné, ale toto vlákno se zvrhlo ke konfrontaci, co je lepší. A já tím jen ukázal, že dm-crypt není ultimátní řešení pro šifrování, ale jak sám autor napsal, je to až ta nejzažší možnost, protože je po všech stránkách (a jim podobné) nedokonalé. A k alternativě dm-crypt POD zfs a ecryptfs NAD zfs u mě vítězí ta druhá alternativa, o což šlo. Ve světle pro a proti je moje řešení pro mě a kdejakého obyčejného uživatele vhodnější, pokud uživateli sejde na bezpečí (uložení, konzistence) dat ručeným zfs a zároveň nechce, aby mu někdo viděl na choulostivý OBSAH souborů. Opravdu metadata v mém domovském adresáři pro mě mají hodnotu blízkou nule...a stejně tak by to bylo případné návštěvě policie - páč žádné ataky na vládní instituce neprovádím. A ti, kteří musejí ukrývat i metadata, jsou pravděpodobně jsou dost chytří na to, aby spoléhali jen na jednu technologii, protože samotná bude nedostatečná každá.

[pavlix]

To je možné, ale toto vlákno se zvrhlo ke konfrontaci, co je lepší.

Nikoliv.

Nejsem znalec kryptografie, ale článek mě přesvědčil, že šifrování pod fs je prostě špatné.

Diskuze je o tom, zda lze vůbec rozumně z článku dojít k výše uvedenému a to především právě bez znalosti kryptografie.

jak sám autor napsal, je to až ta nejzažší možnost

To je přinejmenším trochu vytržené z kontextu. Z pohledu kryptografie to sice autor hodnotí jako až tu nejzazší možnost, ale z pohledu uživatele, který potřebuje přistupovat k blokům souborů tomu tak ani podle článku není.

A k alternativě dm-crypt POD zfs a ecryptfs NAD zfs u mě vítězí ta druhá alternativa, o což šlo.

Pokud správně článek chápu a pokud věřím informaci od Martina, tak k takovému závěru článek ani v nejmenším nenabádá.

[petr]

Nesouhlasím s jedinou věcí, co jsi napsal:

To je možné, ale toto vlákno se zvrhlo ke konfrontaci, co je lepší. Nikoliv.

Zaprvé jsem měl na mysli celé vlákno poradny - důvody proč rh vyhodil ecryptfs. A pokud jsi to tu alespoň trochu četl, tak tu lidé psali, abych zvážil encfs místo ecryptfs, který z toho porovnání vyšel ještě hůř, nebo dm-crypt, který mi nevyhovuje použitím a dle autora článku ani filozofií - tak jak je současně implementováno blokové šifrování je nevhodné.

Diskuze je o tom, zda lze vůbec rozumně z článku dojít k výše uvedenému a to především právě bez znalosti kryptografie. jak sám autor napsal, je to až ta nejzažší možnost To je přinejmenším trochu vytržené z kontextu. Z pohledu kryptografie to sice autor hodnotí jako až tu nejzazší možnost, ale z pohledu uživatele, který potřebuje přistupovat k blokům souborů tomu tak ani podle článku není.

On napsal, že je to nejzažší možnost, protože to je nejzažší možnost. Jenom ti, co MUSÍ z nějakého důvodu použít šifrování na úrovni bloku/sektoru, tak ať jej použíjí. Všichni ostatní by měli použít alternativní technologii pro šifrování. To je tam jasně napsané, přečti si to znovu (ne jen tento snippet, ale raději celý článek..): But that’s the big problem: sector-level encryption sucks. It’s messy, provides fewer security guarantees than conventional message encryption, and makes tradeoffs tailored to the challenges of encrypting disk sectors. Sector-level crypto is last-resort crypto. That problem is significant enough to be dispositive. If you don’t have the sector-level problem, don’t use sector-level crypto.

A k alternativě dm-crypt POD zfs a ecryptfs NAD zfs u mě vítězí ta druhá alternativa, o což šlo. Pokud správně článek chápu a pokud věřím informaci od Martina, tak k takovému závěru článek ani v nejmenším nenabádá.

O tom vůbec ten článek nebyl, byl o xts módu a blokovém šifrování obecně...o co šlo bylo v kontextu tohoto celého vlákna, které odbočilo z úvodního dotazu o rh a ecryptfs na to, co používat za technologie. A s ohledem na to, že neustoupím s požadavkem mít zfs naspodu. A i když jsem článek četl s otevřenou myslí, že dm-crypt je jinak dobrý a kdy by mi nešlo o zfs a pohodlí, tak bych mu dal v šifrování přednost, tak po jeho přečtení jeho proti převažují.

Pravděpodobně jsi to četl stejně zkratkovitě jako tuhle poradnu, když jsi napsal, že jsi netušil, že ecryptfs musí mít podporu v kernelu.

[pavlix]

Zaprvé jsem měl na mysli celé vlákno poradny - důvody proč rh vyhodil ecryptfs.

Dejme tomu, ale pokud byl dotaz o důvodech RH, tak byl prostě položen na špatném místě, protože pochybuju, že tu běžně narazíš na člověka, který má přečtené všechny tiskové zprávy a sleduje všechna oficiální oznámení RH, to už je větší šance že to najdeš googlem než že tady dostaneš odpověď.

Ten dotaz byl od začátku odsouzený k nezodpovězení s vyvoláním diskuze o možných řešeních jako vedlejším efektem. Proto si netroufám to nazývat zvrhnutím, ale spíše jediným užitečným důsledkem dotazu.

Pravděpodobně jsi to četl stejně zkratkovitě jako tuhle poradnu, když jsi napsal, že jsi netušil, že ecryptfs musí mít podporu v kernelu.

Pardon, že nevěnuju čtení příspěvků na sociálních sítích 100% své pozornosti.

[pavlix]

Když tak nad tím přemýšlím, tak je možná celý dotaz (na důvody RH) offtopic, vzhledem k tomu, že je to linuxová poradna pro řešení problémů s linuxem, nikoliv diskuzní fórum o politice komerčních firem.

[petr]

Jak čtu všechny tvoje příspěvky, tak mi přijdeš, že jsi typ člověka, co má názor na všechno a hlavně o něm musí všude dát vědět. Nic proti, ale když na téma nemám co říct, tak nereaguji. Všechny tvoje odpovědi měli nulovou sémantickou hodnotu. Na dotaz: zná někdo důvody proč rh ... odpovíš zabal si to do epel. Prvně pochybuji, že v epel mohou být balíčky kernelu, možná ano nevím. Ale to bude tím, že jsi ani nečetl první větu, takže jsi nevěděl, že se to kernelu týká...

Pak napíšeš +1 k vyjádření, že nic nevím o kryptografii, vzhledem k tvým příspěvkům je jasné, že ty taky ne - proč se vyjadřuješ?

A k tomuto:

Když tak nad tím přemýšlím, tak je možná celý dotaz (na důvody RH) offtopic, vzhledem k tomu, že je to linuxová poradna pro řešení problémů s linuxem, nikoliv diskuzní fórum o politice komerčních firem.

Tohle je abclinuxu, tak proč jsou ve zprávičkách věci, které se linuxu vůbec nedotýkají, či okrajově a to se dá říct i o mém dotazu, který je o linuxové distribuci...

Ale hlavně, že jsi musel reagovat.

Pozitivum této poradny bylo to, že jsi registrovaný uživatel a já tak teď vím, že když něco napíše pavlix, tak to nemusím číst, natož reagovat.

[pavlix]

Na dotaz: zná někdo důvody proč rh ... odpovíš zabal si to do epel.

Udržuju několik balíků pro Gentoo, Fedoru a EPEL, některé z nich čistě pro svou vlastní potřebu a veřejně je držím jen kdyby se náhodou někomu hodily. Vytvoření vlastního balíku a začlěnění do veřejné infrastruktury distribuce, kde ho chci používat považuju za standardní postup pro komunitní distribuce, jakou CentOS je.

Dokonce se nakonec ukázalo, že CentOS již toto řeší prostřednictvím doplňkového repozitáře, tudíž žádný problém neexistuje. Pokud jde o stanovisko RH, nevšiml jsem si, že by někdo v diskuzi dodal odkaz.

Pak napíšeš +1 k vyjádření, že nic nevím o kryptografii

Nikoliv. To vyjádření, které jsem podpořil, o tobě vůbec nebylo. Pouze jsem vyjádřil souhlas s tím, že člověk bez dostatečné znalosti kryptografie (tedy ty i já) by přinejmenším neměl vyvozovat z článku závěry.

[Heron]

Dejme tomu, ale pokud byl dotaz o důvodech RH, tak byl prostě položen na špatném místě, protože pochybuju, že tu běžně narazíš na člověka, který má přečtené všechny tiskové zprávy a sleduje všechna oficiální oznámení RH, to už je větší šance že to najdeš googlem než že tady dostaneš odpověď.

Ehm? Asi tu nenarazí na člověka, co má přečtené všechny RH tiskovky, ale za to tady narazí na hned několik lidí, kteří v RH přímo pracují.

[michich]

Ti by ovšem takové informace neměli sdělovat.

[pavlix]

Ehm? Asi tu nenarazí na člověka, co má přečtené všechny RH tiskovky, ale za to tady narazí na hned několik lidí, kteří v RH přímo pracují.

Tedy tu narazí na lidi, kteří (a) taky nemají ponětí, proč se management rozhodl, jak se rozhodl, (b) myslí si, že vědí, ale jejich informace nejsou lepší než tip nebo (c) vědí, ale neměli by se vyjadřovat, pokud to nebylo oficiálně oznámeno.

Nebavíme se tu o vývojářském rozhodnutí v upstreamovém projektu, které by mělo být vždy nějak zdůvodněno, pokud si člověk nechce hrát na uzavřený vývoj, ale o rozhodnutí nezapnout (či vypnout, podle úhlu pohledu) vlastnost v komerční distribuci.

Pokud je nějaká cesta pro nezákazníka, jak zjistit pohled RH, tak to nejspíše bude najít již existující vyjádření nebo zadat podnět do bugzilly a počkat, co se z toho vyvrbí.

[Jendа]

Všichni ostatní by měli použít alternativní technologii pro šifrování.

Ano, ale ecryptfs není alternativní technologie. Funguje stejně, jako kdybys měl šifrování blockdevice a pro každý soubor měl „vlastní blockdevice“.

[pavlix]

+1

[petr]

Ano, že to šifruje jakési extenty, analogii sektorů, tu už někdo napsal. A alternativní není protože sdílejí 100% kódů, používají se zcela stejně a liší se jen názvem..? Už se tu jen slovíčkaří. A zbytečně přitákává..

[pavlix]

Hlavně tu někdo zbytečně šlape v hovnech. Někdy je mnohem jednodušší alespoň sám sobě přiznat, že jsem už na začátku vlákna napsal hovadinu a nerozmazávat to a nekopat kolem sebe.

[lertimir]

Když už tady hořekujete nad tím jak vám full disk encryption nevyhovuje a jak vám nevyhovuje, že ecryptfs vyhodili z RH a přitom používáte ZFS, tak proč nepoužíváte nativní ZFS crypto

[petr]

Protože pokud se nepletu, tak to bych musel koupit oraclí solaris - zfsonlinux je otevřená implementace verze zfs před akvizicí a než to oracle uzavřel, takže nemá nativní podporu šifrování.

[marbu]

A je mozne zfs pouzit nad dm-crypt/luks oddilem?

[Jendа]

Už jsem se ptal…