![](/sites/default/files/tmp/carousel-63/images/bigstock-several-flowerpot-of-home-plan-238813102.jpg%3Fitok=uLe9zP7M "Uchování balkonových trvalek krok za krokem: Použijte listy, polystyren i "bublinky"")
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Zavaděč ve Fedoře 18 je Grub 2. Ten používají i ostatní distribuce. Tedy podepsaný Grub 2 by mohli rovněž použít i ostatní...nebo tomu něco brání?
Neni to jen o booloaderu, je potreba mit podepsanej vazne uplne celej kernel. Paradoxne je to s trochou podpory pro Linux skoro jednodussi nez pro Windows s milionem externich driveru od cert vi koho.
Presne tak. Secure boot nedovoli nacitat ziadny kerenl ani ovladac/device driver, ktory nie je podpisany...
Vis jak secure boot pozna kernel od aplikace? Nepozna, nechava to na tom koho pustil (pokud to vubec resi). Jakmile jeden clen retezu bezpecnost zanedba, tak muzes nahravat cokoliv.
Podla ringu v ktorom bezi
http://duartes.org/gustavo/blog/post/cpu-rings-privilege-and-protection
Windows donedavna boli naprogramovane, ze vedil bezat len v Ring-u 0. Ak ale vyuzivate virtualizaciu tak hypervizor bezi v Ring0
a OS musel bezat v Ring 1 a vyssie. A kedze v Ring 1 nemozete pouzivat vstetky instrukcie CPU (tie su dovolmne len, ked je CPU prepnute do Ring 0) tak sa to da zaistit...
Ring je záležitost kernelu. To už je dávno mimo UEFI.
Co se týka zabezpečení ovladačů, tak to je jiná fíčůrka - "UEFI Driver Signing".
UEFI nebude kontrolovat kernel, takže se bavíme jen o zavaděči zavaděče jádra (to malý co spustí Grub 2, a Grub 2 potom zavede jádro)....jak ostatně napsal David Ježek.
Co se týče nemožnosti Windows bežet v ring 1 a kvůli tomu nemožnosti provozovat tyhle Win jako virtual PC. Tak to jde...virtualizace emuluje všechny instrukce a OS si myslí že je v Ring 0. Zkuste si spustit Win 3.1 nebo DOS ve virtualu...ty určitě nejsou optimalizovaný pro běh ve virtuálu.
Zrovna bezet ve virtualu DOS je pomerne obtizne, protoze byl napsany velmi prasacky takze ten virtualizator ma dost prace ... samozrejme jde to, ale z casti proto, ze ten virtualizator je optimalizovany pro beh DOSu.
Windows NT (to znamena NT1-3.11,4,XP,Vista,7) vzdycky bezeli v 2 urovnich ring 0 /kernel/ a ring 3 /user/ .. nejake windows 95 a podobnej plevel, co neni OS si bezeli jenom v jedne urovni, ale to byli jenom nadstavby nad msdos.
1) windows bezi ve 2 rinzich, stejne jako linux ;-)
2) ve vsech rinzich jde vykonavat ty same instrukce, jen jaksi RING0 muze zapisovat do pameti instrukci v RING3, ale naopak to nelze.
3) Ring1 pro virtualizaci pouzival XEN, ted je to tak, ze spravce virtualu bezi v RING -1 a virtualizovany OS v RING0 ;-)))
4) OT: windows pouzivaji kernel messaging system, ktery neni zabezpecen a muze jej volat kdokoliv, proto se divim, ze tvurci viru tuto moznost nepouzivaji tak casto, jen obcas nejaky root_kit pres to napadne OS, pak uz ho nenajde ani antivir ;-)) ... tedy vlastne ano, kazdy uzivatel je schopen pres kernel api vykovanat instrukce v RING0 a tim uspesne kompromitovat OS, v linxuu to muze pouze root pres vlastni natazeny modul.
Mimochodem podepsane moduly uz jsou v linuxu davno, pro distribuci to nema smysl, tam ma ty klice kazdy, ale pokud mate klice na secure systemu, kde kompilujete ty kernely a pak na server nedate privatni klic, nikdo si root kit nezkompiluje ;-)))
Pokud tedy neumi editovat kmem ... ale to je uz moc slozite ... a jeste zde mame SELinux se svymy secure kontexty, kdo s kym muze sdilet pamet a mame vymalovano uplne ... to co M$ s vyrobci spackali ma uz linux davno na urovni SW, kdyby to ale bylo bez der (coz pochybuji, ze by tam CIA nemela diry, kdyz je ma i v CISCO a stihali kvuli jejich objeveno autory FreeSWAN ... ze o tehle implementaci IPsecu nevite ??? neni divu ;-))
Takze pokud tam nebudou diry, tak by bylo super, si tam dat svoje klice a mit svuj kernel ....
2) Nejen ze nektere instrukce je mozne (bez vyvolani vyjimky) volat pouze na ring0 (CLTS, HLT, LGDT, LIDT, LLDT, LMSW, LTR a MOV pokud je cilem nektery z registru CR*, TR* nebo DR*), ale v zavislosti na dalsich vlajkach muze byt privilegovanou instrukci i pristup na porty (instrukce IN, OUT).
3) Obecne se ring1 pouziva pro virtualizaci pokud hypervisor nebo CPU nema HW podporu virtualizace (tedy "ring -1").
5) Pristup do /dev/kmem a /proc/kcore (defaultne root) je povazovan za bezpecnostni riziko a nektere "zabezpecenejsi" (hardened) kernely to vypinaji.
6) Prave ze diky open source je pro CIA tezsi dostat "diry" do kernelu linuxu nez do CISCa: u CISCO staci, kdyz podmazne nebo vyhrozuje par lidem, u linuxu by musela podmaznout nebo vydesit kazdeho vcetne autoru FreeSWAN, jinak by na to driv nebo pozdeji nekdo prisel a byl by toho plny internet. Maximalne muzou byt diry nekde v kryptografickych funkcich, protoze tem malokdo rozumi a kdyz se to udela opatrne tezko se dokazuje, ze je to umyslna dira a ne chyba.
PS: Mozna to nevite, ale soucasna implementace IPsec v linuxu je zalozena na FreeSWAN (resp. na jeho forku).
koukám, že jsem to měl do článku explicitně zmínit: tohle není o podepsání grubu 2. oni si ve fedoře napsali "malinký vlastní bootloadeříček", který je podepsaný a teprve on následně provede spuštění grubu 2.
a to se z distribuce nedá vyndat ten bootloadříček? tipl bych si, že to někdo zkusí použít
Tohleto mě napadlo už při čtení článku, vzhledem k tomu co za lego linux je ;-))
Jestli nebude problém v tom, že podepsaná je výsledná binárka, nikoliv zdrojáky. Tzn. i kdyby to ostatní distribuce převzaly, nemají nejmenší šanci si to jakkoli ohnout podle svých potřeb.
Ohnout to nepujde, ale on ten grub2 z fedory umi i tak jak je nabootovat treba ubuntu ... nebo windows 95.
Opravdu to ohnout nelze, protože celý koncept je postavený na "řetězu" podepsaných binárek. Takže pokud si kdokoliv "vyloupne" Fedora bootloader, musel by podepsat vlastní jádro klíčem, který budem mít k dispozici jen Fedora/Red Hat. Jinak UEFI selže.
Jediné řešení je tedy získat klíče od Verisignu - za poplatek. Fedora/Red Hat klíče budou opravdu patrně určeny jen pro tyto distribuce. Případně pro vlastní (nepodepsané) jádro UEFI SB vypnout.
tak to teda nebude, oni daji samozrejme klice k dispozici ;-))
MS nás zase nutí vymýšlet kolo. Celé UEFI je krám a coreboot (i s podporou AMD) zatím jen pro minoritu se starším HW. Při instalaci na GPT instalačka Win7 na deskách gigabyte nastaví jako hlavní MBR a pak nejsou oddíly na disku vidět v gparted. Prostě další prasárna co bude ztrpčovat život ve chvíli nouze.
Nevím, jestli jsi coreboot někdy zkoušel, ale situace je špatná až tragická.
UEFI není špatná věc, ale stále nedotažená (zvláště si umím představit výborné využití možností uživatelských modulů, především k zabezpečení - v jako v podstatě neodstranitelná vrstva pro podporu šifrování/vyhledání/likvidace ukradeného stroje.
Optimum, co se týče těch podpisů bych viděl, aby bylo možná vlézt do nastavení např. na základě hw switche - prostě tak, aby nebylo technicky možná jakákoliv změna jen sw cestou.
Souhlas... je to totalni paskvil, prostrednictvim ktereho si MS zase prosazuje svou. Doufam, ze uz se pracuje na necem, co prislusny HW unlockne.
... dalsi co reaguje v diskusi aniz by si precetl clanek?
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.