Aggályokat vet fel az OpenZFS Native Encryption használata

Fájlrendszer, NAS, storage

A múlt év végén megjelent az OpenZFS 2.2.2 egy ritka, de csúnya adatsérülési probléma kijavítására, de kiderült, hogy az OpenZFS fájlrendszer kódbázisában még más adatsérülési hibák is lapulnak.

Részletek itt.

( trey | 2024. 02. 13., k – 14:19 )

Úgy hangzik a ZFS funkciók bekapcsolása mintha az orosz rulettet játszanék az adatokkal.

trey @ gépház

A probléma elég idegesítő, de alapvetően nem egy adatsérüléssel járó eredmény, hanem a működést befolyásoló esemény. A snapshot marad ott üresen, amit a scrub kijavít, de amikor megtörténik a hiba a dataset-et olyan állapotba hozza, hogy azt csak a modul újratöltésével lehet megoldani. Szóval reboot, hossz scrub ami miatt prod környezetben egy elégé "nyehh" de ez alatt a 3 év alatt még én nem láttam "tényleges" adatsérülést (főleg a zfs voltának köszönhetően)

( gyuri23 | 2024. 02. 13., k – 14:42 )

Azért elég ritka csillagállás kell a hibához. Ha van egy natívan titkosított dataset amin vannak snapshot-ok és a dataset-re használod a send/recive-et akkor sérülhet snapshot.

Azért arról szó sincs, hogy megy a levesbe éles adat.

Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.

Én sem azt mondom, hogy ez dicsőség :)

Csak annyit, hogy ennél azért láttunk már sokkal durvább dolgokat is, amíg javítják együtt lehet (kell) vele élni.

Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.

Ezen nem fogunk összeveszni, de egy védett szerverszobában szvsz nem sok jelentősége van a titkosított fájlrendszenek. Ha gépet törik meg, akkor nincs szerepe, ellopni meg nemigen fogják a szervert.
Elég sok helyen megfordulok, de nem jellemző a használata. Érdekes lenne egy szavazás róla, hogy mennyien használják.

Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.

Ezen nem fogunk összeveszni, de egy védett szerverszobában szvsz nem sok jelentősége van a titkosított fájlrendszenek.

Légy szíves ne. Ezt a hozzáállást ne. Mi lesz ha a hardver tönkremegy? RMA, Kiselejtezés? Baleset, beázás bűncselekmény. Ne haragudj. Ezzel mindenhol kiröhögnek, ha ezt mondod.

Nem hogy a titkosítás kötelező, de az is kötelező sok helyen, hogy a titkosításhoz szükséges információ ne legyen elérhető az adott számítógépen, hogy illetéktelen akkor se tudjon hozzáférni, ha közvetlenül hozzáfér minden elemhez. SED (self-encryption drive, opal2) távoli kulcsmenedzsmenttel, vagy filerendszer natív, távoli kulcsmenedzsmettel. 

Köszi a szokásos személyeskedő primitív stílusod.

  Nem hogy a titkosítás kötelező...

Mármint szerinted. A NIST, vagy NIS2 mondjuk melyik szinten írja elő?

Mi lesz ha a hardver tönkremegy?

https://nmhh.hu/cikk/225140/Mar_elerheto_a_vegleges_adattorlo_alkalmazas

Baleset, beázás

:D ez ellen valóban a titkosítás a tuti védelem LOL

A szerverekhez nem szokás hozzáférni, mert álltában őrzött helyen vannak, ahol nem, ott jogos a titkosítás. A kliens oldal egész mást, de ott meg ZFS nincs.

Na ez esetleg kötelező: https://njt.hu/jogszabaly/2015-41-20-0A

Jelöld be amiről beszélsz.

De tudod mit, tegyél ki egy szavazást és meglátjuk.

Tudom, hogy a te világnézeted az egyetlen szent igaz út, allahu akbar.

Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.

Akkor nézzünk egy szavazást.

A biztonság egyik szabálya, hogy a védekezésnek arányban kell állnia a kockázattal. Egy banknál ez még jogos is lenne, ha tele lenne a sajtó azzal, hogy betörtek az xy bank szervertermébe (ami jó eséllyel cloud) ellopták a szerveket és az azokról szerzett dolgokkal hatalmasat kaszáltak.

Manapság online szokás betörni, ott meg nem segít az fs encrypt, csak az adatokat kell titkosítva tárolni, ott azt ami tényleg fontos.

A beázás ellen viszont én is titkosítást használok az ablak szigetelésére :D

Ahol viszont kritikus a cégvezetők laptopjain, akik a strandon bebaszva elhagyják azt (true story).

Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.

ha nem latod a titkositatlan diszk/storage rmi-jeben a kockazatot es nem latod be miert nem vagy-vagy kapcsolat van fizikai vedelem es titkositas kozott, nem vagy valo IT security teruletre.

bank szervertermébe (ami jó eséllyel cloud) > ezt konkretan a kisujjadbol szoptad. en pl. megfordultam mar penzintezet szervertermeben. te? :)

meg mindig igaz, hogy a human a leggyengebb lancszem, igen, fizikai szekuricsi eseten is, lasd altalad is emlegetett bebaszott cegvezeto, ugyanugy emberek dolgoznak a szervertemekben/korul is. ezt a sechole-t (is) veded a titkositassal. idealista elkepzeleseid vannak arrol, hogy mennyire nehez fizikailag hozzaferni dolgokhoz, vagy mennyire nehez benezni valamit, emberi felelotlensegbol/figyelmetlensegbol/"vanazapenz" alapon megkorrumpalva valakit ilyenbe belefutni.

Manapság online szokás betörni > napersze, pl. ilyenek miatt is fontos mindketto, de majd jol megszakerted

titkosítatlan fájlrendszer != titkosítatlan értékes adat

Kicsit jobban kéne figyelni. Ezen kívül nem csak a bankokról beszélünk. Léci mutass már egy cikket, ahol bármilyen nagy cégtől éles pruduction szervereket loptak (az már igazából rablás, mert van őrség, meg üzemeltetés) és felhasználták az adatokat. Lehetőleg ne ZS kategóriás hollivúdi produkció legen :D

És várom a NIS vonatkozó hivatkozását is.

Ja és képzeld voltam a pénzügynél jobban védett helyen is, ahol pl. az éles szerveren, egy kézzel futtatott sql query után volt 2-3 perced, mire megjelent a szobában fizikailag a security team :) Titkosított fájlrendszer a szerveren viszont nem volt...

Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.

te kotottel bele a bankokba :) ha nem tetszik, engedd el, mert kurvara mindegy, hogy bank-e. a hamisan velelmezett fizikai szekuricsi mindent megoldra hoztam neked peldat.

éles pruduction szervereket loptak > nem kell ellopni sem, keress ra a blamara, ahol az ipmi-n keresztul meg*tak az atomszekur vpn szolgaltatot (gy. k.: pont mintha odasetaltak volna), na, nekik pont jol jott volna a titkositott storage :)
balfaszok voltak, megbiztak a 3rdpartyban, hogy az majd nem enged oda senkit. igy jartak. :D

Ja és képzeld voltam a pénzügynél jobban védett helyen is, ahol pl. az éles szerveren, egy kézzel futtatott sql query után volt 2-3 perced, mire megjelent a szobában fizikailag a security team :) > szar hely lehet ahol csak ugy kezzel futtatgathatsz query-ket az eles DB-n... 3 perc alatt hany DB-t lehet eldropolni? :) ha utolag jon oda a szekuricsi, hogy nem volt jogod valamihez, akkor az nem szekuricsi, hanem tuzoltas.

ismetelten mondom, a fizikai security nem valtja a ki a titkositott storage-et es forditva. ha nem erted melyik miert fontos es miert nem bizhatsz meg az altalad velelmezett fizikai biztonsagban, milyen edge case-eket is szamitasba kell venni ilyenkor (aminek 0< az eselye, az be fog kovetkezni, minel ertekesebb az adatod, annal valoszinubb target ugyebar), miert kell a lehetseges human errort minel jobban kizarni a tortenetbol, be is fejezhetjuk a beszelgetest, fundamentalisan vannak hianyossagaid a kerdest illetoen.

Próbálom egyszerűbben, hogy megértsd, mert úgy látom a szövegértés nem megy.

A fájlrendszer titkosítás nem azonos az adat titkosítással. Én azt mondom, hogy a teljes fájlrendszer titkosítás az esetek nagy részében felesleges és erőforrás pazarló, mert elég csak a védendő adatokat titkosítani. Ezen kívül a fájlrendszer titkosítás az online fenyegetés ellen kb nem ér semmit, akkor már érdemes olyan megoldásokat keresni, ami mindkettő ellen jó valamennyire.

Tudod, a védekezés mértéke arányos legyen a fenyegetéssel. Kicsi tanulj még egy kicsit szekurcsit :D

Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.

nem is beszeltem neked onlany fenyegetesrol, mas ellen ved. fogd fel es tanulj meg egy kis szekuricsit.
bele lehet mindent eroszakolni titkositott DB-be, csak mi a fasznak, ha ott a native speed crypto a diszken/storage-en. :) minden masra ott az encrypted object storage.
mar maga a db structure/business logic is lehet szenzitiv adat, az ellen pedig nem ved, hogy mancika adoszama cryptelt-e a tablaban...
amugy meg b*hatod a kliens oldali kulcsodat, ha viszik a kliensrol, mikor mancika rakklikkel a malware-re.
elindulni _sem_ hagyjuk a DB-t, amig nincs feloldva a crypt. aztan, hogy a kedves szoftverfejleszto hogy kreten/nem kreten ezutan, az mar az o baja. egy masik szint.
ha azt vallalod, hogy az adat cryptelve van tarolva, akkor bizony a kedves ugyfel plaintext file-jait is cryptelve kell tarold. pont.

Én azt mondom, hogy a teljes fájlrendszer titkosítás az esetek nagy részében felesleges és erőforrás pazarló

Ehhez lesznek valami szamok meg meresi eredmenyek is?

Amugy teljesen hetkoznapi problema, hogy valami nem vart helyre kerul erzekeny adat, pl. egy crash-nel nem vedett helyre kerul ki dump, vagy valami rossz helyre general temp fajlt, logot, vagy akarmit. Ez a lehetoseg mindig nyitva lesz, akkor is, ha ti nagyon pengek vagytok, es veletek sosem tortenhet ilyesmi. Dehogynem.

Lehet vetiteni, hogy a gyorsreagalasu SWAT-team majd beront a terembe, es lelovi a betolakodokat, de az at-rest titkositas nem ez ellen ved.

Köszi a szokásos személyeskedő primitív stílusod.

Nem személyeskedtem. Az írásod minősítése nem személyeskedés.  Segítettem, hogy _ne sülj fel_ azzal a hülyeséggel amit ide írtál a jövőben ott ahol ez tényleg számít. Ha használod, akkor használod, ha nem nem.

"Baleset, beázás"

:D ez ellen valóban a titkosítás a tuti védelem LOL 

Amiket én láttam: vízszint alatt szerverterem beázott, elindult az oltási mechanizmus, hurrikán kis híján megnyitotta a helyet, vízben álltak a rackek, robbanás történt, elromlott hűtőtorony.  Havária esetén szart sem ér a "fizikai biztonság" mert le se szarják, nem garantálható, de ettől még nem megy tönkre minden, ergo jó lenne, hogy ha valaki megtalálta a HW-t akkor ne szivárogjon.

Nem személyeskedtem.

Ja persze. Önértékelés, ülj le elégtelen :)  Hát nem csodálom, hogy téged tartanak itt a leghülyébbnek :)

ergo jó lenne, hogy ha valaki megtalálta a HW-t akkor ne szivárogjon.

Anyám, ez a baromságot el is hiszed? Beégtél, ez van, lépj tovább :)

Kezdjük újra. Először is, a fájlrendszer nem titkosítás, nem zárja ki az adat titkosítást. Sokkal értelmesebb, mondjuk egy adatbázisban a kritikus adatokat titkosítva tárolni, sózni és a kliens oldalon visszafejteni, mert akkor az online támadástól is valamennyire védve van az adatbázis és az általad vizionált világvége beázás ellen is. De ez gondolom túl bonyi :)

Egyébként pedig, melyik audit szabvány szerint "kötelező", ahogy állítod, a fájlrendszer titkosítás? Léci mutasd meg. Én számtalan NIST800 és NIS2 auditon vagyok túl, de valamiért ezt nem követelték sosem.

Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.

Ez mar bullshit, ami ossze lett hordva a temaban.

FDE pro:

  • ved bizonyos kockazatok es tamadasi vektorok ellen
  • ved bizonyos emberi mulasztasok ellen (lasd fentebb, amit irtam)
  • egyszeru
  • olcso

FDE kontra:

  • ???

Ha nincs konkret okod nem hasznalni FDE-t (pl. hardver nem tamogatja), akkor hasznald nyugodtan, nem harap.

Engedd el. Ez az a nárcisztikus jegyekkel megszórt szint amivel nem tudsz mit kezdeni, észérvek nem hatnak, mindent személyesnek és támadásnak vesz, ha nem egyezik a véleményed. El kell az ilyet engedni, hadd mondja, ha ez neki jó, hogy úgy érzi "jólmegmondta" akkor win-win. 

Hát ennyit tudsz, személyeskedni. Szakmai válasz persze nincs.

Mi az, hogy kötelező a fájlrendszer titkosítás? Ki kötelez és hol?

Mennyire jó ötlet egy olyan technológiát "kötelezően" használni ami a fejlesztői szerint nem "pruduction redy"?

Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.

FDE kontra:   

  • nem production redy (mármint a ZFS amiről jelenleg beszélünk)...
  • sok esetben fölösleges, csak egy hibalehetőség
  • bonyolult kulcskezelés, bonyolult üzemeltetés
  • teljesítmény vesztés
  • visszaállítási nehézségeket okoz
  • hacker támadások ellen nem ér semmit
  • rossz költség kontra előny arány

Az egyszerű és olcsó amit írsz rá, az nem igaz. Nem tudom terveztél-e valaha összetett rendszer, vagy üzemeltetsz-e bármit, de szerintem nem. A kulcskezelés egy nagy rendszerben igen bonyolult és az üzemeltetést is nagyon nehezíti. Már egy frissítés utáni újraindítás is problémát okoz. Kell egy rakás szabályzat, hogy ki és hogy fér a kulcsokhoz, meg hogyan éri él a gépet ha szükséges.

A NIST-800 bullshit? Hát jó nagy security specialist vagy...

Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.

( bennyh | 2024. 02. 14., sze – 06:44 )

Bezzeg a Qnap hogy döngette a mellét, hogy ők olyan szarral, mint a btrfs, nem bajlódnak, csak a zfs az igazi, miközben lassan minden más konkurens btrfs-re állt át akkor.

Ebben azért még ilyen időnként felbukkanó hibák esetében is igazuk van.

A btrfs nem tudja kiváltani a zfs-t a mai napig. Vannak mindkettőben elérhető szolgáltatások, de pl. redundancia terén a btrfs megmarad a tükörnél, minden ennél bonyolultabb esetben alá kell tenni mondjuk md-t, és az md kötetre tenni btrfs-t. Ellenben a zfs megoldja az összes fajta redundáns kötet kezelését önállóan.

A btrfs-nek sokkal kisebb az erőforrás igénye, így pl. a Synology (meg a többi kisebb gyártó) nagyon gyenge hardveren is tudja futtatni. A QNAP-nál is csak az erősebb hardvereken érhető el a Hero, ami zfs alapú (azt nem is tudom, a kisebb NAS-okon lévő nem-Hero milyen fs-t használ).

Nem utolsó sorban több (jól fizetett) fejlesztő áll jelenleg a zfs mögött, mint a btrfs mögött, aminek az sem tett jót, hogy a Red Hat dobta a támogatását (így sok fizetett fejlesztőt kivett mögüle).

Szerintem jó a sokszínűség, nem kell csak zfs-hez vagy btrfs-hez ragaszkodni, feladathoz lehet és kell eszközt (fs-t) választani. De azt nem lehet (egyelőre) kijelenteni, hogy a btrfs le tudja váltani a zfs-t.

Én ezt értem, van helye a ZFS-nek (de pl biztos nem az otthoni két lemezes NAS-omon, ahol BTRFS bekapcsolt tömörítéssel jól elvan két éve), de azért nézd meg a videót, hogy sz@rozza a QNAP a többieket és a BTRFS-t, ahhoz képest nagyon is komikus.

https://www.youtube.com/watch?v=eQd4fmkJ4ns

https://www.qnap.com/solution/qnap-ext4/en-us/

Amúgy pont szemezgettem volna velük is, de ezért nem választottam őket. 

( Raynes | 2024. 02. 15., cs – 04:57 )

Szerintem a túl komplex kódbázis miatt debugolják nehezen. Ez az ára, hogy egy fájlrendszerre túl sok funkciót bíznak. Ezt a Unix-filozófia alapján szét kéne bontani, layerekre, egyik a mirror-ról, másik a titkosításról, stb. gondoskodjon.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

attol nem kesz kevesebb a kodbazis, hogy ezt helyett:

storagelayer:
  code1
  code2
  code3

ezt csinalod:

storagelayercode1:
storagelayercode2:
storagelayercode3:

cserebe vacakolhatsz eppen melyik reszet a summa kodbazisnak ki hogyan alakitja ugy at, hogy valami eltorjon, mehet az egymasra mutogatas, hogy a masik kodjaban van a hiba, aka: wontfix, allhatsz meg a sajat fejleszteseddel ha a masik kodja nem tamogat valamit, stb. :) openszorsznal (is) ezt lepten-nyomon latni.

a zfs kod nem azert sok, mert egyben kezel mindent, hanem mert olyan featuresetet nyujt, amit mas, osszehakkolt "modularis" stack sem nagyon tud adni jelenleg. free/opensource alapon plane.

A kódbázis nem lesz kisebb, de mivel el lesznek szeparálva a kódok, ezért könnyebb csak 1 rétegben debugolni, látni fogod hol a bibi, és csak annak a modulnak a kódrészét kell átnézni. Így jelenleg egy összehányt, hatalmas kódbázis, vakarja mindenki a fejét debugoláskor, nem is értik, hogy hol a bug.

Plusz ha szétbontod rétegekre, akkor egy-egy réteget használhat nem csak a ZFS, de más fájlrendszer is. Rugalmasabb megoldás lesz. Az értem, hogy a ZFS jelenleg mindent önerőből kell megoldjon, mivel kínál olyan feature-öket, amik más rétegből nem elérhetők, de sajnos ennek ára van, mint a hír is mutatja.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

nem konnyebb. attol, hogy tobb git pullbol jon a kod, a rendszered osszessegeben nem lesz egyszerubb, sot.
probalj mar meg tobb fejlesztocsapatot tobb kulon kodbazissal egy iranyba terelni, sok sikert hozza :D
Plusz ha szétbontod rétegekre > pont ezert jo a zfs, mert nem csak egy dologra jo, integralt, crossplatform. nem kell baszkodni meg legozni. csak betolod a pool lemezeit valahova es osszerakja, mukodik, orulsz.