qemu-kvm umí UEFI Secure Boot

qemu-kvm dostalo podporu UEFI Secure Boot. Díky tomuto budou moci hlavně vývojáři a daší zájemci zkoumat fungování této nepopulární funkčnosti, která má být automaticky zapnutá na všech budoucích PC.

28.6.2012 11:12 | Luboš Doležel (Doli) | Zajímavý software

Komentáře

[Conscript89]

No nevim, naposled kdyz jsem zkousel Tianocore, tak mi nefungoval graficky mod (Fedora, RHEL) a kdyz uz jsem delal vnc, tak to bylo hrozne pomaly, ale zkusim to zase.

[Vantomas]

Jakože ta virtualizace byla pomalá? A byl zavedený modul kvm? A má hardware podporu virtualizace? A byla povolena v BIOSu? Protože s rychlostí virtualizace skrze KVM vesměs nejsou žádné problémy.

[Conscript89]

Jojo, virtualizace byla pomala. Ano mel, ac to byl tehda Core 2 duo (ano, opravdu mel). Ani ted nevim, jestli OVMF fungovalo nejak hur s KVM nez bez nej, ale neni to moc ani na testovani. Ted kdyz to zkousim, tak akorat nefunguje tty0 a grafika frci, takze console=ttyS0 na command line to resi :)

[Conscript89]

Akorat hrozne dlouho nacita ramdisk :/ Zkousim ted grub-efi (legacy grub).

[...]

to ze mas core 2 duo jeste neznamena, ze ma podporu vsech ficur urychlujicich virtualizaci. u intelu jsou na tohle experti jak prodat mainstream procesory aniz by z nich sla postavit pouzitelna serverova farma za zlomek ceny proti jejich enterprise cpu.

[Conscript89]

Tak jo, uz vim cim to bylo. Pri kvm system nahodne zamrzava (pise na consoli neco o lock-up nebo tak neco) a bez kvm je to nehorazne pomaly. Host Fedora-17 core i5 sandy bridge.

[Vantomas]

Hm, tak to nevím čím by to mohlo být. Prakticky mám v Debianu spuštěný KVM hosty, ty mají klidně uptime 100 dní a v kernel logu žádny lock-upy nemám. Je možné, že je to distro-specifické nebo špatná verze qemu-kvm proti jádru, ale to zase u distribučních balíků nehrozí.

Jak to spouštíš? Přímo spouštěný proces qemu-kvm nebo přes nějaký virt-manager?

[Conscript89]

Spoustim to takto:
qemu-kvm -serial stdio -L bios/ -m 1024 -drive if=virtio,file=foo.img -cdrom ~/isos/dvd.iso
Probelm je prave v OVMF ktere mam v bios adresari, jinak mi to se seabios krasne frci.

[Vantomas]

Áha, tak to bude asi celý problém.

[little.owl]

.... zkoumat fungování této nepopulární funkčnosti

Technologie kolem UEFI Secure Boot je fajn a spise bych ji videl pozitivne, ted jen zalezi jak se s tim nalozi a zdali si budem moci pridavat sve klice.

[Jendа]

Upřímně mi to přijde jako taková vlastnost, která v praxi bezpečnost moc nezvýší…

[little.owl]

Mno, klic ktery je ulozen v chipu na motherboardu a bez nehoz nenabootuje je IMHO hodne bezpecne reseni a pokud to bude v pripade ARMu plne integrovane SoC reseni vectne uziti TrustZone, je to temer neprustrelne.

[Lol Phirae]

Erm... myslím, že po zkušenostech s TPM bych byl již hodně skeptický.

[little.owl]

Denne uspesne hackujete TPM? BTW, UEFI secure boot protocol nepotrebuje TPM.

[Lol Phirae]

Ne, nehackuju. Nicméně to hacknout jde, prakticky vyzkoušeno na dvou serverech, jeden Fujitsu, druhý tuším HP. Po dvouhodinovém výletu, když správce flashnul vzdáleně BIOS a počítač samozřejmě již nenabootoval, byl ten nesmysl vypnut a nikdy to nikomu nescházelo.

[little.owl]

dyž správce flashnul vzdáleně BIOS a počítač samozřejmě již nenabootoval,

A to ma byt dukaz ceho v kontextu uziti TPM?

[petr_p]

To je důkaz, že TPM funguje :) Na tohle přesně je TPM. Nebrání uživateli ve zničení systému. Pouze zaručuje, že se pozná, že se v něm někdo vrtal.

[little.owl]

Presne to me napadlo a proto jsem nechapal.

[Lol Phirae]

No, že to je dobré akorát pro zlost.

[little.owl]

Stejne jako ta protivna hesla!

[Lol Phirae]

No, já nevím jak bych vám ještě víc polopatě vysvětlil, že věc, která nepočítá s tím, že by snad někdo mohl potřebovat vzdáleně aktualizovat BIOS, je poněkud nedomyšlená?!?!

[little.owl]

A pouzil jste nastroje v tpm-tools? BIOS a TPM tvori "Root of Trust" a tak neautorizovany update BIOSu nemusi byt povolen, pak to byva dokumentovano.

[Lol Phirae]

No, dokumentováno to nebylo, i když by to člověk tak nějak u firmy jako je Fujitsu předpokládal.

[Jendа]

TrustZone je zajímavá myšlenka, neznal jsem, ale se Secure Boot nesouvisí.

Proti čemu má SB chránit? Podle mě je největším rizikem děravý prohlížeč nebo jiný program, který běží s právy uživatele - a uživatel chce mít možnost spouštět svůj kód, tedy může spustit i ten malware.

[little.owl]

TrustZone je zajímavá myšlenka, neznal jsem, ale se Secure Boot nesouvisí.

Zvazuje se uzka integrace, napriklad ochrana updatu Secure Boot klice. ARM ma tyhle veci opravdu hodne vymakane/odladene, vcetne HW.

Podle mě je největším rizikem děravý prohlížeč nebo jiný program, který běží s právy uživatele

Jiste, ale to jsme trochu jinde, tohle neni adresovano Secure Bootem.

[Jendа]

Jiste, ale to jsme trochu jinde, tohle neni adresovano Secure Bootem.

Tak čemu se chceš vyhnout? Fyzickému tamperingu útočníkem? Když má přístup na patchnutí jádra/bootloaderu, může škodit i mnoha dalšími způsoby.

Osobně mě trápí:

• Coldboot
• Code injection
• Násilné vymáhání

Ani jednomu SB nezabrání. První lze řešit technicky (ochrana RAMky), třetí z části taky (TPM s autodestrukcí), druhé snad jen oddělením všech aplikací pomocí brutálního SELinuxu/kontejnerů/ještě lépe virtualizace.

[little.owl]

U ARMu s coldbootem pohorite, pouzita pamet je casto integrovana na cipu a po resetu uklizena. Nasilne vymahani? To jako myslite, ze vam nekdo analyzuje obsah flasky jeji demontazi nebo zmlati kladivem? To druhe je levnejsi a jistejsi.

[Jendа]

U ARMu s coldbootem pohorite, pouzita pamet je casto integrovana na cipu a po resetu uklizena.

Jak kdy. Někdo má JTAG, někdo má U-Boot promt při bootu, který umožňuje dumpnout paměť (používá se na debug padajícího jádra).

Ano, tím myslím, že mě někdo bude mlátit kladivem. TPM s falešným heslem, které způsobí destrukci, by se mohl hodit.

[little.owl]

Jak kdy. Někdo má JTAG, někdo má U-Boot promt při bootu, který umožňuje dumpnout paměť

JTAG jen jiny port/protokol a umozni vam jen to co je mu dovoleno, a cela security cast muze byt nepristupna. Verifikace muze byt udelana v TrustZone nebo na kompletne izolanem security processoru. Jak vam pomuze uboot, kdyz v dobe, kdy ma sanci bezet je vnitrni pamet uzita pro klice je jiz davno uklizena?

Ano, tím myslím, že mě někdo bude mlátit kladivem. TPM s falešným heslem, které způsobí destrukci, by se mohl hodit.

A pro jaka data byste se nechal [u]mlatit kladivem?

[Jendа]

Jak vam pomuze uboot, kdyz v dobe, kdy ma sanci bezet je vnitrni pamet uzita pro klice je jiz davno uklizena?

Seš si jistý, že se RAMka smaže? Já jsem na nějaké přednášce o U-Bootu matně slyšel, že se to debuguje tak, že se to resetne a vyčte se to.

A pro jaka data byste se nechal [u]mlatit kladivem?

Já pro žádná, ale jsou lidi…

[little.owl]

Seš si jistý, že se RAMka smaže?

SoC postavene ARM jsou stavebnice slozene z jader a periferii, vcetne pameti a existuji stovky systemu sitych na miru pro ruzne aplikace, proto je slozite generalizovat.

V systemech na kterych jsem pracoval a ktere meli Security Processor, byla integrovana pamet uzivana timto procesorem po resetu (a nekterych vyjimek) vymazana. U dalsiho systemu mazana nebyla, ale byla tam zabezpena flash pro bootloader, ze ktereho bylo mozne obsah pameti smazat. Integrovana pamet je mrnava, rozhodne to neni nahrada za externi DDR a casto je rychlejsi, s vlastnim DMA a mapovanim do pameti ci cachovaci strategii.

že se to debuguje tak, že se to resetne a vyčte se to.

To je normalni trik zaozeny na predpokladu, ze data preziji reset.

[pc2005]

Jo přece samotnej linux má na to 64/128/256/...kB buffer pro printk výpisy.

[...]

amater co si mysli: "TPM s falešným heslem, které způsobí destrukci, by se mohl hodit"

tohle je samozrejme blbost. sebedestrukce kopie pouze snizi pocet moznosti pokud ma nekdo luks formatovany disk, tak timhle vlastne vyradi jeden slot z nutnosti lamat ho.

[pavlix]

Mohl by prosím anonym přeložit svůj příspěvek do češtiny?

[Jendа]

Amatér jsem, LUKS používám, ale mohl bys mi to prosím přeložit?

[xkucf03]

Neprůstřelné proti jakému útoku?

Problém je v tom, že cenná data jsou v domácím adresáři (může k nim neprivilegovaný uživatel) a zároveň uživatel chce, aby mu „šel internet“. Tzn. jsou dostupná data, která lze ukrást/smazat/upravit a je tu komunikační kanál k útočníkovi. Většinou je nejslabším článkem uživatel/BFU a tomu žádný Secure Boot nepomůže. A pokud jde o nějaký cílený a vážně míněný útok na konkrétního člověka, tak tomu zase můžou vyměnit čip/desku/počítač… a je to. V podstatě jediná ochrana je nedávat ten počítač z ruky a nespouštět na něm nedůvěryhodný kód (a pokud možno ho ani nepřipojovat k žádné síti, ale to už je trochu extrém).

[Jendа]

nespouštět na něm nedůvěryhodný kód

Existuje důvěryhodný kód? :)

a pokud možno ho ani nepřipojovat k žádné síti, ale to už je trochu extrém

Problém nastane, pokud máš důležitá data a potřebuješ s nimi něco dělat se sítí (podepisovat, šifrovaně vyměňovat s jinými počítači atd.). Pak to prostě připojené být musí.

[little.owl]

Nemuzete uplatnovat pristup, "Secure Boot neni reseni na vsechny problemy a tudiz ho nebudem pouzivat".

[xkucf03]

Ale můžu uplatňovat přístup: na levé straně lodi je metrová díra a brzy se potopíme → nebudeme řešit malou prasklinu na pravé straně trupu.

[little.owl]

Bezpecnost je retez, ktery nesmi byt porusen uz na zacatku a zabezpeceny boot je dobry start.

[pavlix]

To je takové hezké klišé, které když bys vzal do důsledků (tedy ne jako pouhé klišé), tak dojdeš k úplně jiným závěrům, než dosud.

[xkucf03]

+1

Aby ten řetěz skutečně fungoval, tak potřebujeme mít kompletní (a auditované) zdrojáky od „BIOSu“ a dalších firmwarů, od všech ovladačů… (operační systém a aplikace jsou samozřejmost). Taky je potřeba zkontrolovat i všechny procesory/koprocesory a generátory náhodných čísel, že dělají, co mají – jinak bychom mohli mít pocit, jak krásně si šifrujeme, ale přitom by např. ta „náhodná“ čísla a klíče byly předvídatelné výrobcem/útočníkem.

[little.owl]

Firefox je deravy, kaslem na Secure Boot!

[Martin Mareš]

Ano, protože z dnešních reálných bezpečnostních rizik by Secure Boot nezabránil téměř žádnému.

Pořizovat si pancéřované vchodové dveře nemá smysl, když mám zatím trvale otevřené okno do zahrady.

[pc2005]

potřeba zkontrolovat i všechny procesory/koprocesory

Jj viz(pro neodebíratele) Čína.

[pc2005]

Aby ten řetěz skutečně fungoval, tak potřebujeme...

...mít uživatele na řetězu.

[little.owl]

...mít uživatele na řetězu.

Na retezu budou az si koupi Windows 8 s UEFI Secure Boot.

[pavlix]

A to i kdybys byl takovýhle idealista, tak bys ještě potřeboval auditovat nejenom zdrojáky, ale i zda binární kód těm zdrojákům vůbec odpovídá. Plus ten zmíněný hardware.

Dnešní bezpečnost je založena na důvěře nedůvěryhodným a hlavně neznámým subjektům a lidem.

[xkucf03]

Sice jsem to tam explicitně nenapsal, ale myslel jsem to tak, že po tom auditu si z těch zdrojáků přeložíš vlastní binárky – jinak by to nedávalo smysl.

[Jendа]

Nezapomeň ještě auditovat kompilátor, kompilátor, kterým jsi zkompiloval kompilátor, a kompilátor, kterým jsi zkompiloval nástroje, které používáš při auditu, a nástroje pro audit samotné.

A auditovat cokoli složitého je šílené.

[pc2005]

dík

[pavlix]

Bohužel tyhle věci nejde jen implicitně myslet.

[xkucf03]

Sorry, ale pracně auditovat zdrojáky určité verze a pak používat binárky „téhož“ programu získané bůhví odkud je tak padlé na hlavu, že to v tomto kontextu není potřeba uvádět.

[pavlix]

Mýlíš se.

[xkucf03]

Tohle taky občas někomu napíšu, ale diskuse pak obvykle nepokračuje. Asi je to tak správně

[pavlix]

Asi jo. Bohužel je to zkušenost podložená praxí a diskuzemi s lidmi. Předpokládat, že tohle lidi budou brát jako samozřejmost mi připadá strašně naivní a podle mě tě tyhle představy časem přejdou. Ale momentálně nemám možnost předložit přesvědčivé důkazy :).

[little.owl]

tak dojdeš k úplně jiným závěrům, než dosud.

Tak to by stalo za rozvedeni.

[pavlix]

Mimojiné to, co psal Franta.

[Jendа]

Tak mi řekni, před čím mě to jako uživatele takového ARMového netbooku ochrání. Jediné, na co jsem přišel, je, že mi nějaký hekerko nemůže vyměnit jádro za vlastní, získá-li k počítači fyzický přístup.

[little.owl]

To je snad jasne. Zabezpeci vam to bootloader, kernel a drivery, nic vic, nic min.

[Jendа]

Dobře, a proti jakému konkrétně útoku mě to teda má ochránit? Popiš třeba nějaký scénář, který díky SB selže.

[little.owl]

Ma to znemoznit nabootovani nepodepsaneho/neautorizovaneho systemu a mit tuto moznost je IMHO dobra vec, nebot ja jako uzivatel mam jistotu, ze system ktery nabootoval neni [jakkoliv] kompromitovan.

Vy a ostatni se snazite prokazat neco takoveho je k nicemu, a ze takova moznost by nemela/nemusela/nema/? byt implementovana ci je nesmyslna. Proc?

Zamykate si byt/dum? Pokud prenesu vasi argumentaci (a nekolika lidi zde), pak to v podstate nema smysl. Nemate jistotu, ze zamek, klic a dvere byly dobre navrzeny, spolehlive vyrobeny a i kdyby, zlodeji se tam dostanou okny ci nebo probouraji zdi ci strechou.

Secure Boot je jen jedna kostka ve stavebnici zvysujici bezpecnost systemu.

[Jendа]

Ma to znemoznit nabootovani nepodepsaneho/neautorizovaneho systemu a mit tuto moznost je IMHO dobra vec, nebot ja jako uzivatel mam jistotu, ze system ktery nabootoval neni [jakkoliv] kompromitovan.

Ne, takovou jistotu nemáš. Máš možná tak jistotu, že není kompromitováno jádro, ale userspace může být prostřílený jako cedník.

Vy a ostatni se snazite prokazat neco takoveho je k nicemu, a ze takova moznost by nemela/nemusela/nema/? byt implementovana ci je nesmyslna. Proc?

Nemusela, protože z dnešních reálných bezpečnostních rizik by Secure Boot nezabránil téměř žádnému. (#51) Je to podobné, jako zakazování přihlašování roota na SSH - bezpečnostní benefit je naprosto minimální, jen to všechny otravuje.

Zamykate si byt/dum? Pokud prenesu vasi argumentaci (a nekolika lidi zde), pak to v podstate nema smysl. Nemate jistotu, ze zamek, klic a dvere byly dobre navrzeny, spolehlive vyrobeny a i kdyby, zlodeji se tam dostanou okny ci nebo probouraji zdi ci strechou.

Tohle je spíš o zamykání dveří (jádra), když je vedle otevřené okno (userspace).

[David Jaša]

A: Je to podmínka nutná, proto je dobře že se to dělá

B: není to podmínka postačující, proto to nemá smysl dělat

Kolik iterací ^^^ ještě proběhne, než se pochopíte?

[little.owl]

+1

[pavlix]

Kolik iterací ^^^ ještě proběhne, než se pochopíte?

Dokud nepochopíš, že takhle ta otázka nestojí?

[Lol Phirae]

Co to? Jašovi nestojí?

[pavlix]

Jdi si hrát na píseček a nepleť se mezi dospělé :).

[little.owl]

Ne, takovou jistotu nemáš. Máš možná tak jistotu, že není kompromitováno jádro, ale userspace může být prostřílený jako cedník.

Lepsi neco nezli nic a jadro hraje v bezpecnosti systemu nesrovnatelne vetsi roli, ze user space aplikace.

Nemusela, protože z dnešních reálných bezpečnostních rizik by Secure Boot nezabránil téměř žádnému.

Secure Boot zabrani nabootovani nepodepsaneho systemu, nic vice a nemuze adresovat chyby programatoru. To ze ocekavate vice je vas problem.

Tohle je spíš o zamykání dveří (jádra), když je vedle otevřené okno (userspace).

Srovnavat neumyslne chyby v aplikaci s umyslne otevrenym oknem je v nasi analogii pritazene za vlasy.

[pavlix]

Lepsi neco nezli nic

Rozšířenost tohoto názoru je IMO důvodem tak špatného zabezpečení, jaké dneska všude vidíš.

[little.owl]

Jinak: Lepsi maly krok vpred, nezli zadny

Rozšířenost tohoto názoru je IMO důvodem tak špatného zabezpečení, jaké dneska všude vidíš.

Muzete to rozvest?

[pc2005]

Jinak: Lepsi maly krok vpred, nezli zadny

Ne pokud bude ten krok sice malý, ale znemožní další kroky (například zesložití použití amatérských OS).

[trekker.dk]

Zamykate si byt/dum? Pokud prenesu vasi argumentaci (a nekolika lidi zde), pak to v podstate nema smysl. Nemate jistotu, ze zamek, klic a dvere byly dobre navrzeny, spolehlive vyrobeny a i kdyby, zlodeji se tam dostanou okny ci nebo probouraji zdi ci strechou.

Z hlediska pravděpodobností je ochrana pomocí Secure Boot ekvivalentní tomu, když si do střechy dáš pancéřové bloky, aby se skrz ní do domu zloději nemohli probourat. Bude to stát spoustu peněz, spoustu práce, způsobovat problémy a to všecho za situace, kdy jsou dveře toho domu udělané z papíru.

Secure Boot je jen jedna kostka ve stavebnici zvysujici bezpecnost systemu.

Jenže ostatní kostky neexistují a vznik téhle kostky odčerpává prostředky, které by se k jejich vytvoření daly použít. Není to nic jiného než drahé bezpečnostní divadlo, které se skutečným zabezpečením nemá moc společného. Výsledkem bude nálepka a výkřiky "podívejte se, jste v bezpečí"

[xkucf03]

+1 a hlavně hrozí, že ti ty pancéřové bloky spadnou na hlavu a dům se stane neobyvatelným.

[little.owl]

Bude to stát spoustu peněz, spoustu práce, způsobovat problémy a to všecho za situace, kdy jsou dveře toho domu udělané z papíru.

Nikoliv.

Jenže ostatní kostky neexistují a vznik téhle kostky odčerpává prostředky, které by se k jejich vytvoření daly použít.

Jake prostredky? Jakousi obdobu zabezpeceneho bootu pouzivame a jeji implemantace je z hlediska nakladu s ohledem na pocet clovekodni ci radku kodu minimalni.

Znova, jediny problem je zdali budeme moci pridavat a menit klice a zdali to budem moci vypnout, nic jineho.

[Martin Mareš]

Jakousi obdobu zabezpeceneho bootu pouzivame a jeji implemantace je z hlediska nakladu s ohledem na pocet clovekodni ci radku kodu minimalni.

Prvotní implementace je obvykle naprosto zanedbatelný náklad. Daleko významnějším nákladem pseudobezpečnostních opatření je jejich působení na celkovou komplikovanost systémů, která pak činí složitějšími úpravy, které opravdu mají smysl.

Znovu: chybí jakýkoliv konkrétní příklad reálných bezpečnostních hrozeb, které by zabezpečený boot spolehlivě zastavil nebo alespoň výrazně zkomplikoval. Do té doby je zcela fair považovat ho pouze za bezpečnostní divadlo.

[little.owl]

Prvotní implementace je obvykle naprosto zanedbatelný náklad.

Mame podobny system zabezpeceni v produkcnim modu jiz asi pet s vyrobou asi 300 000 jednotek rocne asi ve dvaceti variacich; dost na to, abych s tim mel zkusenosti.

chybí jakýkoliv konkrétní příklad reálných bezpečnostních hrozeb

To jsme jiz zde probrali nekolikrat.

[trekker.dk]

chybí jakýkoliv konkrétní příklad reálných bezpečnostních hrozeb

To jsme jiz zde probrali nekolikrat.

To bude tím, že to zarputile odmítáš vzít na vědomí.

[trekker.dk]

Jake prostredky?

Např. čas (a tedy peníze) lidí, kteří vymýšlejí, jak to udělat, aby na tom krámu mohl Linux fungovat. Když řeší tohle, nemůžou řešit něco, co by skutečně (čti nezanedbatelně) zvýšilo bezpečnost systému.

[little.owl]

Co na tom chcete konkretne resit? Bud je image podepsana, pak to nabootoje nebo neni a pak to nenabootuje, loaderu je jedno jestli je natahuje Windows, Linux ci BSD. Na urovni kernelu jsou zmeny v podstate zadne, vetsina Androidich telefonu jiz takto roky bootuje. Praci prinesl UEFI bios, nikoliv Secure Boot a to je soucast normalni technicke inovace.

[trekker.dk]

Já na tom konkrétně nechci řešit nic. Ale vývojáři jádra a distribucí tráví hodiny času řešením toho, jak to udělat, aby průměrná linuxová distribuce na stroji, kde je tahle hovadina zapnutá, nabootovala. A jak to udělat, aby si člověk mohl taky nabootovat svoje vlastní jádro.

[little.owl]

Prevaznou cast UEFI implementovali placeni vyvojari velkych firem jako je Dell ci Intel a je jejich svobodnou volbou do ceho chteji investovat svoje penize a nam do toho v podstate nic neni. Take it or leave it.

[trekker.dk]

To je sice hezké, ale nemá to nic společného s tím, co jsem napsal.

Máš problém s tím sledovat celou diskuzi a reagovat víc než na jeden příspěvek dozadu? Abych ti to usnadnil - je úplně jedno, kdo UEFI implementoval a za čí peníze. Podstatné je, že teď se s tou kravinou musí vývojáři Linuxu a distribucí nějak vyrovnat a to bude stát peníze a čas, který by se dal použít na vytvoření skutečného zabezpečení (tj. něčeho, co skutečně vylepší bezpečnost systému)

A ano, velké firmy mají svobodnou volbu, do čeho investují svoje peníze, ale v tomhle případě je investují do ptákoviny, u které navíc nemůžu použít to tvoje "leave it" (plus i tady platí, že ti vývojáři mohli za dané peníze dělat něco viz výše)

[little.owl]

Podstatné je, že teď se s tou kravinou musí vývojáři Linuxu a distribucí nějak vyrovnat a to bude stát peníze a čas, který by se dal použít na vytvoření skutečného zabezpečení (tj. něčeho, co skutečně vylepší bezpečnost systému)

Za prve, znovu, podstatnou cast kodu venovali firmy, ktere maji zajem na podpore UEFI v Linuxu a vam neni v podstate vubec nic do toho jak jimi placeni vyvojari travi svuj cas, to je zalezitost jejich obchodnich strategii. Za druhe, Secure Boot sam o sobe neprinasi temer zadne vyrazne zmeny, bootloaderu je jedno co naloaduje pokud sedi podpis a jeho obdoba je jiz davno pouzivana bez problemu s kernely androidich telefonu.

Pokud budete chtit provozovat Linux na HW designovanem pro Windows, nezbyva vam nic jineho nez se prizpusobit standardum Windows a tim je UEFI, a nebo nepouzivat HW designovany pro Windows.

[xkucf03]

Aha, takže tu máme HW pro Windows a pak HW pro Mac OS. Ale já (a spousta dalších lidí) chci standardní hardware pro obecné použití – PC.

[little.owl]

Ale já (a spousta dalších lidí) chci standardní hardware pro obecné použití

Tak chtit to muzem - ja jsem plne pro - v tom mezi nami neni zadny rozdil. Nicmene vetsina vyrobcu vyrabi a testuje HW pouze pro Windows a my muzem tak akorat brblat a podporovat minoritu vyrobcu beroucich Linux v potaz (mluvim zde o desktopu).

[trekker.dk]

Za prve, znovu, podstatnou cast kodu venovali firmy, ktere maji zajem na podpore UEFI v Linuxu a vam neni v podstate vubec nic do toho jak jimi placeni vyvojari travi svuj cas, to je zalezitost jejich obchodnich strategii.

Ještě jednou a pomalu, protože ti zjevně uniká to podstatné. Je úplně jedno, kdo to zaplatil. Podstatné je, že místo toho mohl zaplatit vývoj skutečného zabezpečení, což teď neudělá, protože prostředky jsou omezené. A do toho mi teda něco je, protože místo skutečného zabezpečení dostávám jenom bezpečeností divadlo.

A druhá věc je, že ty firmy to dělají z donucení, ne protože by chtěly.

Secure Boot sam o sobe neprinasi temer zadne vyrazne zmeny, bootloaderu je jedno co naloaduje pokud sedi podpis

...takže jádro, které si vytvořím sám, nenabootuje, protože nebude podepsané. To je podle mě hodně výrazná změna.

Pokud budete chtit provozovat Linux na HW designovanem pro Windows, nezbyva vam nic jineho nez se prizpusobit standardum Windows

Jinak řečeno Secure Boot neslouží k zabezpečení, ale k tomu, aby škodil konkurenci.

[little.owl]

A druhá věc je, že ty firmy to dělají z donucení, ne protože by chtěly.

Sorry, ale zvanite, fakta hovori proti vam.

Za prve, HP vyrabi EFI servery jiz mnoho let, bez toho ani by to to bylo vyzadovano Windows. Kdo je tedy nuti? Prvni server s EFI jsem videl v roce 2005 a byl na tom Linux. Totez Dell ci IBM a tyto firmy aktivne pracovaly na vytvoreni UEFI standardu. Za druhe, obdoba secure bootu je implementovana na vetsine telefonu, embedded jednotkach ci hernich konzolich - opet kdo ty firmy nuti? Pridani Secure Boot do biosu je trivialni zalezitost.

takže jádro, které si vytvořím sám, nenabootuje, protože nebude podepsané. To je podle mě hodně výrazná změna.

Pokud to budete chtit provozovat na HW designovanem pouze pro Windows, pak ano.

Podstatné je, že místo toho mohl zaplatit vývoj skutečného zabezpečení, což teď neudělá, protože prostředky jsou omezené.

Vy stale mate tendenci hodnotit traveni ciziho casu a prostredku svymi kriterii. Ja jsem stravil s UEFI dost casu, vcetne naprogramovani diagnostiky pro muj HW. Pro vas ztrata casu a plytvani prostredku, pro me nikoliv a podstatne je, ze vam do toho vubec nic neni. Muj cas a me prostredky a plati to i prostredcich a casu ostatnich.

[trekker.dk]

Sorry, ale zvanite, fakta hovori proti vam.

Sorry, ale ještě pořád ještě jste nepochopil, o čem mluvím.

Za prve, HP vyrabi EFI servery jiz mnoho let, bez toho ani by to to bylo vyzadovano Windows. Kdo je tedy nuti?

Nevím, jak to napsat ještě pomaleji, protože tady už se začínáme pohybovat na úrovni obrázků a slabikáře: já nemluvím o náročnosti a vůli k implementaci EFI a Secure Bootu a o tom, že by k tomu někdo nutil firmy jako HP a Dell (Výrobce "biosů")

Mluvím o tom, že se Secure Boot se následně musí vyrovnat distributoři mj. Linuxu, tj. firmy jako Red Hat a Canonical, a ti jsou k tomu nuceni. Jsem na 100% přesvědčen, že by svůj čas raději věnovali něčemu jinému

Vy stale mate tendenci hodnotit traveni ciziho casu a prostredku svymi kriterii.

Jenže moje (a nejenom moje, jak je vidět v téhle diskuzi) kritérium je mj. "přinese Secure Boot nějaké skutečné zabezpeční?" "jsou prostředky, které je nutné vynaložit na to, aby se s tím Linux vyrovnal, dobře vynaložené?"

Já vím, jsou to otázky, které si zastánci úřednických řešení (např. Vy) pokládají velmi neradi.

[little.owl]

Jenže moje (a nejenom moje, jak je vidět v téhle diskuzi) kritérium je mj. "přinese Secure Boot nějaké skutečné zabezpeční?" "jsou prostředky, které je nutné vynaložit na to, aby se s tím Linux vyrovnal, dobře vynaložené?"

To je porad dokola. Je to dusledek toho, ze se snazite provozovat Linux na HW designovanem [pouze] pro Windows, uzivatelum Windows UEFI ani Secure Boot neprinese zadne problemy, spise naopak. HW designovany pro Linux - prevazne servery a serverove komponenty nebudou mit take problemy, tim jsem si jist.

[little.owl]

Za to "zvanite" se dodatecne omlouvam.

[trekker.dk]

Dobrý start by to byl, kdyby to skutečně zabránilo nějakému významnému procentu realizovaných útoků.

Jenže většina útoků se realizuje přes děravý prohlížeč, pomocí přílohy v nějakém spamu či podobně - prostě útok, který úspěje kvůli neznalosti uživatele a který zpravidla zpřístupní data v počítači, udělá z něj spamovacího bota a podobně. Tomu žádný secure boot nezabrání.

Na druhou stranu je secure boot technologie, kterou lze snadno zneužít v konkurenčním boji. Ke čemuž už vlastně došlo, zapnutý secure boot představuje problém pro uživatele open-source operačních systémů, kdežto věčně děravé Windows (tak kdepak je ta bezpečnost?) podepsané budou.

Secure boot je jenom další ukázka "úřednického" postupu: (1) Je problém? Je potřeba vytvořit řešení. (2) Vytvořili jsme řešení, hurá. (3) Krok, ve kterém ověřujeme účinnost řešení, přeskakujeme.

[little.owl]

secure boot technologie, kterou lze snadno zneužít v konkurenčním boji.

Ano, to je nejsilenejsi argument, ktery zde zaznel a se kterym se ztotoznuji, nicmene nevhodne uziti technologie neni argumentem proti technologii same.

[Jendа]

Jenže většina útoků se realizuje přes děravý prohlížeč, pomocí přílohy v nějakém spamu či podobně - prostě útok, který úspěje kvůli neznalosti uživatele a který zpravidla zpřístupní data v počítači, udělá z něj spamovacího bota a podobně.

Je neznalost uživatele, když sem někdo pomocí XSS javascriptový exploit pro nejnovější Firefox a uživatel je po zadání www.abclinuxu.cz okamžitě kompromitován? (ano, takové exploity byly a byly pomocí bezpečnostních děr vloženy do důvěryhodných stránek)

[trekker.dk]

(ano, takové exploity byly a byly pomocí bezpečnostních děr vloženy do důvěryhodných stránek)

... a že jich v porovnání s "klikněte sem a vyberte si výhru" bylo...

[Martin Mareš]

Řetěz je tak silný, jako jeho nejslabší článek. Takže má smysl především zabývat se nejslabšími články, ne bootováním, které je jedním z těch poměrně silných.

[little.owl]

Takže má smysl především zabývat se nejslabšími články

Ma smysl se zabyvat vsemi clanky a Secure Boot lze technicky implementovat relativne jednodzse.

ne bootováním, které je jedním z těch poměrně silných.

Neni, prenesene, ten "clanek" zde v podstate chyby.

[Jendа]

Tak ještě jednou, napiš mi typ útoku, který díky SB selže. Já jsem přišel jenom na jediný: když se můj notebook dostane někomu do ruky, nemůže vyšroubovat disk, připojit /boot na svém počítači, vyměnit mi jádro za své a zase tam ten disk vrátit. Pravděpodobnost provedení takového útoku považuji za tak minimální, že nemá cenu se jí zabývat; pokud už někdo získá možnost nepozorovaně mi rozšroubovat notebook a hrát si s diskem, může dělat i spoustu jiných nepěkných věcí.

[little.owl]

když se můj notebook dostane někomu do ruky, nemůže vyšroubovat disk, připojit /boot na svém počítači, vyměnit mi jádro za své a zase tam ten disk vrátit.

To je jeden ze scenaru, stejne jako modifikace jadra a ci driveru pres exploit.

[pavlix]

To je docela významný a nepříliš náročný útok. Problém je v tom, že samotný secure boot nebrání mírně modifikovaným útokům na současné linuxové systémy. Chybí hned další článek řetězu.

[Martin Mareš]

To je docela významný a nepříliš náročný útok.

Který Secure Boot nijak nezastaví, mají-li Tvá data cenu větší než $100 (cena za podepsání Microsoftem).

[little.owl]

Coz souvisi s moznosti kontrolovat pouzite klice.

[pavlix]

A to navíc.

[pavlix]

Ma smysl se zabyvat vsemi clanky

Implementace secure boot rozhodně není zabýváním se všemi články :). Jinak rozumný pohled (v citaci) přetransformováváš do podoby bezpečnosti formou úlitby bohům.

[Martin Mareš]

Ma smysl se zabyvat vsemi clanky

Kdybychom měli neomezené zdroje, tak jistě. Ale ty jaksi nemáme, proto je rozumný přístup řešit ty problémy, které jsou podstatné, a ne u domu, kterému chybí polovina oken, půl roku leštit kliku.

Navíc naprostá většina bezpečnostních opatření uživatele otravuje (v tomto případě komplikacemi při instalaci a upgradu OS) a ochota uživatelů nechat se otravovat je konečná. Takže je rozumné zvolit co nejúčinnější opatření, která jsou ještě přijatelně otravná.

Secure Boot lze technicky implementovat relativne jednodzse.

Právě že ne – například naprosto chybí rozumný key management (jako ostatně u většiny dnešních použití kryptografie).

[little.owl]

Kdyz zakaznik chce zabezpeceny system, jeden scenar je pouzit procesor s integrovanou flash, kam se umisti pre-bootloader s integrovanym public klicem. Flash je po prvnim naprogramovani uzamcena a jiz ji nelze behem zivota HW zmenit. Pokud se updatuje aplikace v hlavni flash, verifikuje se podpis u nove image a pokud nesedi, update se nekona; nekdy se verifikuje i vlastni aplikace pri loadovani do DDR. Scenaru je vice, ale vsechny maji vetsinou spolecne jedno - zabezpeceny boot. Co delame spatne, rad se poucim.

Právě že ne – například naprosto chybí rozumný key management (jako ostatně u většiny dnešních použití kryptografie).

Resitelne to je, muzete pouzit i TPM. Pokud mate pocit, ze easy to break, tak proc ten krik?

[Martin Mareš]

Kdyz zakaznik chce zabezpeceny system, jeden scenar je [...]

To je dobrý scénář pro embedded systém, ale ne pro víceúčelový počítač. U těch jsem ostatně nijak nepostřehl, že by zákazník chtěl

Resitelne to je, [...]

Jistě, je. Jen bohužel ne řešené.

Pokud mate pocit, ze easy to break, tak proc ten krik?

Protože je to další věc, která komplikuje život, a přitom ke skutečné bezpečnosti přispívá pramálo.

[little.owl]

To je dobrý scénář pro embedded systém, ale ne pro víceúčelový počítač.

Zabezpeceny boot neni otazka viceucelovosti a to ze muzete nabootovat jen podepsany operacni system s tim nesouvisi. Cely problem je jen v jedne veci - zdali si budeme moci pridavat/odebirat klice a zdali to pujde vypnout.

[Martin Mareš]

Pokud by se počítače prodávali s prázdnou množinou klíčů a každý by si při instalaci OS pohodlně přidal, jaký klíč chce, bylo by to samozřejmě OK. Jenže kdo ví, jak to bude doopravdy vypadat (při všeobecné zabugovanosti dnešních BIOSů není moc pravděpodobné, že by zrovna tohle fungovalo solidně).

[xkucf03]

jj, tohle by byl dobrý scénář:

• Při první instalaci OS se nahraje certifikát daného OS.
• Tlačítkem na desce půjde vymazat certifikáty a obnovit původní stav.
• Uživatel si může volitelně nastavit heslo, aby nešlo certifikáty tak snadno vymazat.
• Šlo by nastavit, zda soukromým klíčem nainstalovaného certifikátu půjde podepsat nové certifikáty (např. pro případ přidání nového OS do dualbootu).

SecureBoot by se dal udělat dobře a užitečně, jenže jde o to, zda je cílem bezpečnost pro uživatele, nebo posílení monopolního postavení určité firmy…

[David Jaša]

Ještě nějak odlišit režim instalace, kdy bude vlastní sekjůrbůt vypnutý a z OS půjde nahrát klíče do traststóru od normálního režimu, kdy bude úložiště klíčů ro a neschválené filmy budou vyfakovány...

[pc2005]

To by šlo klíčem navíc pro instalačku, kterej by se pak invalidoval.

[xkucf03]

Podobnou funkci měly už některé staré BIOSy – antivirová ochrana, která blokovala zápisy na disk, které měnily zavaděč – když chtěl člověk přeinstalovat OS, musel o tom BIOSu nejdřív říct. A samozřejmě tahle funkce šla i úplně vypnout a neotravovala.

[little.owl]

Jen poznamka, nove se bootuje se podle partition UUID, UEFI pouziva GPT.

[:::]

Technologie kolem UEFI Secure Boot je fajn a spise bych ji videl pozitivne, ted jen zalezi jak se s tim nalozi a zdali si budem moci pridavat sve klice

ta technologie sama o sobe by byla dobra. Sice bysme se mohli dohadovat kolika realnym utokum to zabrani, ale asi bysme se shodli minimalne ze bezpecnosti neubere.

Duvod proc je nepopularni je to co jsi sam napsal. Lidi se obavaji ze korporace / governmenty to pouziji k omezeni nasich svobod...

[little.owl]

Mezi nami neni zadny rozpor.

Duvod proc je nepopularni je to co jsi sam napsal.

Ja si to uvedomuji a proto jsem to psal.