Názory k článku Šifrování v Ubuntu prolomeno, portace ovladačů Nvidia do FreeBSD

Tohle šifrování stylem "if(nějaká podmínka) then šifruj else odepři přístup" jsem nikdy nepochopil. Toto lze VŽDY obejít, někdy snadněji někdy složitěji. Před čím to chrání? Ochrání to data při ukradení počítače? Ne. Ochrání to data při ukradení disku? Možná. (bude chybět TPM) Mnohem lepší přístup je šifrovat data klíčem odvozeným z uživatelova hesla (klíčem zašifrovaným klíčem odvozeným z hesla, aby si uživatel mohl změnit heslo). Tam to nelze obejít, neznáš heslo - nerozšifruješ data. A žádná chyba softwaru pro zadávání hesla to nemůže obejít. Už jsme tu měli kočku, co chodila po klávesnici a opakovaně stiska backspace, teď tu máme opakované stisknutí enteru. Co bude příště? Buffer overflow v X11? Joystick/mouse input?

Nekompetentnost. V IT robia ludia ktori nerozumeju tomu co robia. Nahradili sme to smernicami, procesmi, testami, ... a tak sa tam dostali hlupaci ktori sice vedia splnit smernicu ale nerozumeju SW, su neskuseni. V bezpecnosti je to uplna katastrofa. Bezpecak firmy ktory ani nevie co je to oAuth. A to bolo v nie jednej firme.

Chrání to proti získání dat z disku, třeba při jeho rozbití, jeho prodeji či ztrátě. Nechrání to proti ukradení počítače, je to přeci jen bezobslužné dešifrování.

Je nesmysl vzít ochranu, která řeší X a kritizovat to za to, že to neřeší Y.

Částečně to ve většině případů ty data před kráděží možná ochrání - pokud ten útok není cílený, tak ten notebook většinou ukradne nějaká osoba nevalné inteligence, která to střelí ne o moc chytřejší osobě do zastavárny a tam odsud to koupí někdo podobný. Když se do toho nepřihlásí, nejspíš to přeinstalují; málo kdo z tohoto okruhu lidí z toho bude složitě lámat data.

Ale vtip použití TPM v korporátních sítích je kvůli něčemu jinému: kvůli ochraně před samotným uživatelem, co ten počítač používá. Dovoluje to totiž jednu krásnou věc, zašifrovat uživateli disk, aniž by od toho disku měl heslo/klíč. Potíž v tomhle nasazení je to, že uživatelé mají obvykle nějaký neprivilegovaný účet s hromadou omezení, který je štve, protože si tam nemůžou instalovat ptákoviny a tak podobně. Pokud ten disk není zašifrovaný, tak geniální uživatel na tom nabootuje nějaký admin recovery CDčko (které obvykle už rovnou bývá zavirované), které mu vytvoří admin účet s heslem, co zná. A může si tam pak dělat co chce... Pokud je to zašifrované s klíčem v TPM, tak bootovací CDčko si na disk nesáhne a tohle nefunguje.

... ehm ... v normalne fungujici firme by toto znamenalo okamzite ukonceni pracovniho pomeru s § do zapoctaku a trestni oznameni na uzivatele.

Chtel bych videt, jak to nekdo svepravny bude zkouset.

A mmochodem, sifrovani ti v tom rozhodne nijak nepomuze, protoze on ten uzivatel prekvapive heslo k tomu klici ma, a mit musi ze?

Trestní oznámení vám paralyzovanou firmu nezachrání... a občas nevycházím z údivu, čeho všeho jsou uživatele schopni...

Jinak ne, uživatel ten klíč nemá. Klíč je v TPM. TPM to snad vydá jenom tomu správnému systému a ne nabootovanému livku. Za standardních okolností teda OS nabootuje sám, aniž by uživatel cokoliv někam zadával. Takže náhradní klíč, který se datluje na klávesnici (což má třeba i bitlocker a generuje ho) uživatel v ruce mít nemusí.

Klic jako takovy je v TPM a odtam ho dostane ... kdokoli. Prave proto, ze to zadne heslo nechce.

A kdyby chtelo, tak to heslo musi byt zapsano nekde v efi odkud si ho kdokoli precte.

Ukol znel prece jasne ... sifrovat...

Vis ono kdyz mas nekam davat nejake heslo, tak tam to heslo musi nekdo zadat. To muzes doma. ale ne uz ve firme. Tam se vetsinou chce, aby veci fungovaly bez zasahu, a predevsim i v situaci, kdy admina prejede auto/ozere se do nemoty ;D.

A 100% vsech tech "onosetosamo" systemu je zavislych na tom, kdo ma nebo nema pristup. Nemusi to byt jen fyzicky pristup, protoze spousta podobnych kravovin se da delat i po siti.

Jinak nadpis clickbajt ... zadne sifrovani prolomeno nebylo, byl jen obejit system odemknuti klice.

"Šifrování v Ubuntu 20.04 prolomeno"

NEbylo prolomeno sifrovani, ale skripty pro 3rd nastroje ktere Ubuntu bezne NEpouziva...

slo o customizovane Ubuntu kde:
1. vytvoreni initramdisku nezajistoval vychozi mkinitramfs, ale byl pouzit dracut pouzivanej v RPM distrech
2. pro automaticke odemcenim LUKS klicem z TPM byl pouzit Clevis, kterej se by default v Ubuntu nepouziva

a to "prolomeni" spociva v tom ze pri je spatne osetrenej vstup pro zadani hesla(NE k LUKS), nasledne se detekuje problem a spusti systemd emergency s rootem a uzivatel rucne pusti Clevis kterej odemyka LUKS klicem z TPM (coz je jeho ucel)...

On je celkově problém i v tom, že v téhle konfiguraci je kernel/initrd na nešifrované partition a konfigurák zavaděče také. Takže ikdyž bude zavaděč nastavený tak, aby měl heslo, nefungovala na něm cmdline a podobně, tak stejně stačí ten disk vyndat, překonfigurovat to a do toho shellu se dostanu úplně stejně. Jenom je to o něco více práce...

Doufám, že o knihovně Greenie bude Root psát častěji než 2x za týden. ;-) Ne vážně, je to taková pecka, že to stojí za zmínku?

Mně přijde, že zrovna téma kupříkladu prolomení něčeho není přímo práce vhodná pro pana Sluku. Já vím, že občas píše o nějakých SW novinkách, ale bývá to v podstatě jen text zkopírovaný z homepage toho projektu, občas jsou v tom i blbosti.

Tento článek o "prolomení" považuji za hrubě nepodařený a přijde mi, že kvalitou prostě neodpovídá standardu tohoto webu.