Jelenlegi helyzet a BIOS-szal
UEFI Secure boot
A Red Hat alkalmazásában álló Matthew Garrett több alkalommal is írt már az UEFI Secure Boot-ról és arról, hogy annak alkalmazása milyen megoldandó problémákat okoz pl. a Linux disztribútorok számára:
A Microsoft is kifejtette saját álláspontját a témában korábban:
Garrett szerint az év vége felé a megvásárolható új gépek nagy része Windows 8 certified lesz, és ha azokon a Windows 8 előtelepítve lesz, akkor be lesz rajtuk kapcsolva a Secure Boot. Elvileg ezek a gépek gyári állapotukban, bekapcsolt "Secure Boot" ellenőrzés mellett csak a Microsoft által aláírt OS loader-t indítanák el, így más operációs rendszer - Linux, *BSD stb. - futtatása felhasználói beavatkozás, előzetes konfiguráció nélkül lehetetlen lenne rajtuk.
Ugyan a Microsoft szerint a "Secure Boot" opció minden x86 gépen kikapcsolható lesz, Garrett-ék szerint nem minden Fedora felhasználó fogja élből tudni, hogy az mi és hogy hol lehet kikapcsolni.
Éppen ezért a Fedora arra jutott, hogy nem elég a felhasználókra bízni a "Secure Boot"-tal kapcsolatos döntést. Megvizsgálva a lehetőségeket, arra jutottak, hogy nem jó megoldás az, ha készítenek egy Fedora kulcsot és ráveszik a hardvergyártókat arra, hogy azt is építsék be a hardvereikbe. Az sem tűnt életképes megoldásnak, hogy létrehoznak egy globális Linux kulcsot és azt építtetik be a gyártókkal. Ezek az opciók bonyolultak és/vagy költségesek lettek volna.
Ehelyett a Fedora arra jutott, hogy létrehoz egy saját, egyszerű, ritkán változó, első lépésben elinduló bootloader-t - a neve "shim" - és azt aláíratják a Microsoft-tal. Ez a loader nem csinál majd mást, mint elindítja a GRUB2-t, amelyet át kell dolgozni annak érdekében, hogy a biztonságos boot folyamat fenntartható legyen (runtime modulbetöltés lehetőségének letiltása). A Fedora 18 a jelenlegi tervek szerint már ily módon támogat(hat)ná a Secure Boot-ot.
Természetesen nem csak a boot loader problémát kell megoldania a Fedora fejlesztőknek, ha a Secure Boot-ot támogatni kívánják. Hátra van még pl. a kernelmodulok aláírásának kérdése, kiváltképp az, hogy a Linux kernelfán kívül karbantartott driverekkel mi lesz.
Garrett itt írja le a Fedora Secure Boot támogatási elképzelését, ami - mint az olvasható - nincs kőbe vésve és könnyen változhat még a jövőben.
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Nem igazán értem, miért kell egy új betöltő programot írni és azt aláíratatni a microsoft-tal. A grub-al nem lehet ezt megcsinálni?
- A hozzászóláshoz be kell jelentkezni
Az a gond, hogy minden alkalommal amikor kijön egy új verzió akkor alá kellene íratni. Nem az a lényeg, hogy az MS írja alá, hanem hogy egy rendes tanúsítvánnyal legyen aláírva, amit a gyártók a "BIOS" firmware-jébe fel is töltenek. Egy ilyen aláírás pedig, bizony pénzbe kerül. Te magad is le tudod fordítani odahaza a forráskód alapján a Grub-ot, aláírni már nem tudod, így használni sem, hiszen a betöltési folyamat elhasal az ellenőrzésnél. Ez egy lépés lenne az OpenSource halála felé. Ez a gond, szerintem.
- A hozzászóláshoz be kell jelentkezni
Pedig minden szukseges informacio benne van a cikkben.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Ahhh....
- A hozzászóláshoz be kell jelentkezni
A Microsoft most örül, hogy van mire fognia az opensource cs*szegetését...
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Vajon nem lenne-e egyszerűbb egy biztonsági okokból sikertelen boot esetén kiírni a felhasználónak a képernyőre egy üzenetet, hogy "ha szándékosan akarsz aláíratlan programot indítani, akkor az xy gomb lenyomása után a z menüben a zs opciót leszel szíves átbillenteni a értékből b értékbe?" Csak kérdezem... Mert szerintem az opensource világban minden programot, kernelmodult, és ezeknek minden verzióját úgysem lesz senkinek türelme aláirkálni. Viszont ha bármelyik szinten van egy nem aláírt szoftver, akkor meg már úgyis mindegy...
- A hozzászóláshoz be kell jelentkezni
Hasonlo jutott eszembe nekem is, tul azon, hogy az alairast az ms valoszinuleg penzert fogja megtenni, illetve ha vki egy sajat loadert akar fejleszteni gonoszkodasbol, akkor ezt fogja hasznalni.
Masreszrol, nagysagrendileg mennyo boot loader cseres gep van? Megeri foglalkozni veluk, hogy a legelterjedtebb oprendszer csak ugy, es csak akkor hajlando bootolni?
- A hozzászóláshoz be kell jelentkezni
nem, mert a felhasználók hülyék hogy megértsék hogy ez mit jelent, bla...
- A hozzászóláshoz be kell jelentkezni
De mi lesz az egész lényegével, a biztonsággal, ha az MS aláírja a loadert, ami akármilyen hackelt grubot betölt?
Nem pont az lenne a cél, hogy amit aláírnak, annál felelősséget vállalnak arra, hogy az nem tölt be semmilyen rosszindulatú kódot?
- A hozzászóláshoz be kell jelentkezni
Eppenseggel de. :)
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
A lényeg, hogy a grub2 -t (pontosabban annak egy Fedora által karbantartott változatát, tehát nem akármilyent) _engedje_ betölteni, ami egyértelműen nem boot-time malware, hanem a Fedory xyz -t hivatott betölteni.
- A hozzászóláshoz be kell jelentkezni
Akkor nem értetted meg az UEFI Secure Boot lényegét.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
And the point is?
- A hozzászóláshoz be kell jelentkezni
A Microsoftnak sikerült egy világméretű problémát megoldania, ami már-már összeroppantotta az informatikát, hisz mindenki tudja, hogy több milliárd gépet támadnak manapság a BIOS-on keresztül. Épp ideje megmenteni a világot.
- A hozzászóláshoz be kell jelentkezni
+1
Mesterségesen generált probléma, de szerencsére készült is rá megoldás. :(
- A hozzászóláshoz be kell jelentkezni
Á, közben rájöttem, hogy az MS ezzel a lépéssel nem a biztonságra törekszik, hanem ezzel ideologizálja meg azt, hogy az OEM Windows-t megvédje valamennyire a wareztől MS módra.
- A hozzászóláshoz be kell jelentkezni
szerintem meg most hagyd abba, mielott nagyobb hulyeseget beszelsz. a secure boot nem MS talalmany, sok ember, komoly kutatasi temanak talalja (lasd remote attestation es tarsai, alap feltetel, hogy a teljes merheto lancod hitelesitett legyen).
- A hozzászóláshoz be kell jelentkezni
Nem érek én rá neked elmagyarázni, hogy ilyesmiket nem mondtam, nincs nekem arra több hetem.
- A hozzászóláshoz be kell jelentkezni
nem tehetek rola, hogy ennyire analfabeta vagy. talan olvasd el, miket irtal, aztan rajossz.
- A hozzászóláshoz be kell jelentkezni
:DDDD
- A hozzászóláshoz be kell jelentkezni
Valamelyest kapcsolódik:
Try to buy systems that don't rely on UEFI. In the next few years,
prepare to buy systems and find out they require UEFI, and then demand
a refund. Prepare for it to get even worse than that.If you buy a UEFI-capable system today, you are giving power to the
people who will (in the future) make UEFI-only systems which are
incapable of running OpenBSD.UEFI arrived with all sorts of promises of making machines better, but
is being turned into something completely nefarious.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Jópofa. :)
>>: sys-admin.hu :<<
- A hozzászóláshoz be kell jelentkezni
Én azon gondolkodom, hogy nem állna-e meg a Microsoft ellen egy antitröszt kereset.
1. A Microsoft felhasználva piaci, marketing és egyéb túlsúlyát nem kényszeríti-e rá a gyártókat arra, hogy "Windows 8 Ready" gépeket, eszközöket gyártsanak a versenyben maradásuk érdekében?
2. Ugyan a definíció szerint az UEFI SETUP-jában kikapcsolható a Secure BOOT, de vajon kötelező-e beépíteni a kikapcsolhatóságot, vagy esetleg a "költséghatékonyság érdekében" kihagyható lesz belőle? Mert ez esetben a Microsoft tenni fog róla, hogy olcsóbb legyen az ilyen gép, vagy alkatrész.
3. Mi garantálja, hogy nem fog-e a jövőben a Microsoft nyomására eltűnni az UEFI-ből a kikapcsolhatóság?
4. Csak az x86 alapú rendszereknél emlegetik, hogy kikapcsolható a védelem, márpedig az ARM egyre nagyobb piaci szereplő lesz. Tudom egyelőre a Microsoft itt még nem mondható túl fajsúlyos szereplőnek, de jobb félni tőle, mint megijedni.
5. Ki dönti el, hogy mi lesz aláírt és mi nem? Vajon bízhat a piac többi szereplője a pártatlan elbírálásban?
6. A Windows 8 el fog-e indulni kikapcsolt védelemnél esetleg más bootmanagerből? (Úgy tudom, hogy nem.)
7. Ha a felhasználó kénytelen kikapcsolni ezt a funkciót, akkor ezzel nem sugallja-e azt ez a megfogalmazás, hogy ettől a pillanattól nem biztonságos a számítógépe, hovatovább operációs rendszere?
Na elsőre ezek merültek fel bennem.
- A hozzászóláshoz be kell jelentkezni
6. A Windows 8 el fog-e indulni kikapcsolt védelemnél esetleg más bootmanagerből? (Úgy tudom, hogy nem.)
A Secure Boot egy feature. Ha nincs UEFI(vagy ki van kapcsolva), akkor nincs secure boot, de ettol meg elindul a rendszer(akar 'normal' bios-al is).
- A hozzászóláshoz be kell jelentkezni
Wikipédiáztam kicsit, ennek alapján:
1: de, szerintem nagyon is. Sőt: "OS loaders are a class of UEFI applications. As such, they are stored as files on a file system that can be accessed by the firmware. Supported file systems include FAT32, FAT16 and FAT12." Ezekért tudomásom szerint az ms pénzt kér...
2/4: x86-on kötelező, arm-en tilos (!) (viszont kérdéses, hogy az arm-es windowsnak kell-e uefi)
5: a fent linkelt cikk szerint pl a verisign
6: nem fog, de ez szerintem elég nehezen megvalósítható. BIOS-szal nyilván elindul. Secure boot-os UEFI-vel szintén. De mi a helyzet a korai UEFI-s gépekkel, ahol ez még nem volt szempont?
7: Ha egy felhasználó belép a setup-ba babrálni, akkor már valószínűleg ért valamennyire hozzá. Ez az átlaguser nem tudja kikapcsolni, hogy linugzot rakjon rá szerintem nem akkora probléma. Sokkal nagyobb probléma, hogy valószínűleg lehetetlen lesz a dualboot.
- A hozzászóláshoz be kell jelentkezni
Vagy kapcsolgatod folyton a bios-paramétert. DE van egy gyanúm, hogy lesz rá törés.
------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.
- A hozzászóláshoz be kell jelentkezni
"hogy valószínűleg lehetetlen lesz a dualboot"
Ez benem is felmerult. Nehany kerdes mellett.
1. Ha a fent emlitett trusted Fedora bootloader ra hiv , Windows 8 trustot kovetelo bootloaderere akkor az meni fog -e ? Es a Windows 9 -el ?
2. Egy nem trusted bootloader be tud -e bootloni egy Windows 8 -at ? Es a Windows 9 -et ?
3. Egy trusted bootloader, kerheti -e az UEFI -t egy masik bootloader betoltesere ?
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
2/4:Arm-es windowssnak is kell uefi.Lásd xda hd2 windows RT8
- A hozzászóláshoz be kell jelentkezni
Amennyit biztos el lehetne szerintem egy ilyen ugyben "pattogassal" erni, hogy nem a Microsoft, hanem egy fuggetlen testulet irja ala az UEFI-s bootloadereket.
(subscribe)
- A hozzászóláshoz be kell jelentkezni
A fent hivatkozott cikkből:
"Microsoft will be offering signing services through their sysdev portal. It's not entirely free (there's a one-off $99 fee to gain access edit: The $99 goes to Verisign, not Microsoft - further edit: once paid you can sign as many binaries as you want), but it's cheaper than any realistic alternative would have been."
- A hozzászóláshoz be kell jelentkezni
Szerintem pedig érdemes példát venni a Fedora team-ről. Ahelyett, hogy a Microsoftot cseszegetnék, inkább megoldást kerestek egy valós problémára. Valószínűleg belátták, hogy egyrészt egy per (még ha a kimenetele számukra kedvező is), sok időt és pénzt emészt fel, annyit meg nem ér az egész. Másrészt a secure bootot nem tartják feleslegesnek, ez látszik abból, hogy alapvetően olyan megoldást kerestek, amivel nem kell kikapcsolni a secure bootot.
Páran már kifejtették, hogy szerintük a secure boot felesleges, mert ma a támadók nem használják ki, hogy a bios bármilyen boot loadert hajlandó betölteni. Csakhogy a Microsoftnak nem 1-2, hanem 10 éves távlatokban kell terveznie, és ezalatt változhat a helyzet. A támadók mindig a legegyszerűbb utat keresik, ha pedig a jövőben megnehezítik a dolgukat a jelenlegi támadási eljárásokkal, újakat fognak keresni, és ha a boot folyamat sebezhető, akkor azt is számításba fogják venni. Utólag pedig ilyen technológiákat sokkal nehezebb lefejleszteni, mint előre, amikor még a megelőzésen van a hangsúly.
- A hozzászóláshoz be kell jelentkezni
Sajnos az a helyzet, hogy technológiailag mindenképpen kiszolgáltatott marad a közösség. A cikkben is szerepel, hogy nem lesz elég az aláírt bootmanager betöltő, annak is aláírtnak kell lennie, meg a kernelnek, meg a moduloknak, meg mindennek. (Lásd: "Természetesen nem csak a boot loader problémát kell megoldania a Fedora fejlesztőknek, ha a Secure Boot-ot támogatni kívánják. Hátra van még pl. a kernelmodulok aláírásának kérdése, kiváltképp az, hogy a Linux kernelfán kívül karbantartott driverekkel mi lesz. ")
Lehet, hogy egy SLED, Red Hat Linux, Oracle vagy akár még egy Ubuntu esetében nem lesz gond, mert meg tudják venni az aláírást, de mi lesz mondjuk egy Debian-nal, Slackware-rel, vagy egy Linux from Scratch-el?
Hogyan tud egy kezdő operációs rendszert tanulmányozni és írni? Vagy ez csak néhány kiválasztott privilégiuma lesz majd? Vajon ki választja majd ki a kiválasztottakat? Vajon Linus hogyan készítette volna el a Linuxot, ha a 386-osa csak aláírt rendszert tudott volna futtatni?
Mi lesz akkor, ha valaki akar egy önálló modult írni? Hogyan fordítasz magadnak Kernelt? Hogyan patch-eled meg? A GCC hogyan írja alá a modulokat?
Szóval szerintem nem elegendő pusztán technikai jellegű tűzoltásba kezdeni, mindenképpen figyelni és figyelmeztetni kellene és szükség esetén lépni. De nem csak a Microsoft esetében. Nagyon félek attól, hogy itt súlyos háttéralkuk vannak a kereskedelmi Linux disztribútorok, a Google, a Microsoft a nagy harware gyártók között annak érdekében, hogy megakadályozzák új piaci szereplők létrejöttét.
- A hozzászóláshoz be kell jelentkezni
Mulatságos látni ahogy egy egy szál belelovalódik egy egy véletlen ötletbe. Egyelőre ott tartunk, hogy a BIOS kiírja hogy: nem jó az OS-ed tanúsítványa, ha folytatod nyomj entert. Nincs senki megakadályozva saját program futtatásában. A vállalati rendszereket szállítóknak meg lesz saját tanúsítványuk, már ha amiatt aggódnánk hogy az ms így versenyelőnyre tesz szert.
Természetesen a linux elterjedésének nem tesz jót ha a windows biztonságosabb lesz mint saját elődje, a linux meg egy helyben toporog, de ez mindenképpen a Ms érdeme, és ha a sulis vagy kisboltos szerveren windows szerver lesz debian helyett mert biztonságosabb, az _jobb_ lesz, mint a jelenlegi helyzet. Szerintem ez csak egy jól meglátott piaci rés, és valóban, ha egy vállalat teljesen egyedül birtokolja egy biztonsági lánc egyik elemét, az versenyelőny, ám még mindig jobb, mintha nem lenne ott semmi. ( mármint windows fronton jobb, a desktop linux oldalt ez jellegénél fogva nem érinti, ott ez úgyis kivitelezhetetlen )
- A hozzászóláshoz be kell jelentkezni
Hát ez szerintem sem a Linux, sem a Windows rendszereken nem a legkihasználtabb biztonsági lyuk. Ez szerintem tipikusan olyan dolog, hogy a bűnözők röhögve ki fogják játszani, a többieknek meg csak nyűg. Az a rendszergazda meg aki akár Debian, akár Win szerverre ilyet beenged, annak úgy kell. Az UEFI meg nem fogja felajánlani az folytatás lehetőségét, hanem bekapcsolt secure boot mellett egyszerűen nem tölti be az aláíratlan binárist.
Amit meg piaci résként értelmezel az olyan, mintha a csúcshiperszuper XY a legnagyobb mosószergyártó előállítana egy mosóport, ami mondjuk jól mos, de csak olyan mosógépeken működik, melyek ezen bizonyos cég által szabadalmaztatott fémötvözetből készülnek. Ennek a fémötvözetnek viszont az lenne tulajdonsága, hogy azonnal korrodálódna, ha másik mosóport használnak vele. A mosógépgyártóknak, akik az ő technológiáját használnák megengedné, hogy úgy reklámozzák a gépet, hogy ez egy csúcshiperszuper XY erejével mosó mosógép. Ezek után a reklámokban azt látnák az emberek, hogy a csúcshiperszuper XY tudja csak kimosni a ruhákat, az összes többi pedig még a színeket is kilúgozza a ruhákból mert egyedül ez a mosópor tartalmaz neoprimitív molekulákat.
Ezek után a mosógépgyártók nem akarnának lemaradni a versenyben (ugyebár a legnagyobb mosószergyártó terméke) és elárasztanák a piacot az ilyen mosógépekkel. A beetetett emberek ezeket a gépeket keresnék. A koppanás akkor jön, amikor kiderül, hogy ez a mosópor bár jó, de rettenetesen drága és a vele mosott ruhák enyhe allergiás reakciókat váltanak ki sok embernél. Ráadásul egyeseknek az illata sem tetszene és csak a mosóporgyártó által szabadalmaztatott technológiával készült adalékanyaggal lehetne azt megváltoztatni, különben tönkremennek a fűtőszálak a mosógépben.
- A hozzászóláshoz be kell jelentkezni
Érzek egy enyhe félreértést néhány hozzászólásban. Az előnye az lenne értelmezésem szerint a TC-nek, hogy a legelső boot folyamattól kezdve lenne végig védve a működési folyamat azzal, hogy az előző lépésben ellenőrizve lenne a bináris a következő lépéshez, és így tovább. Tehát minden bináris ellenőrizve lenne a betöltődése és futtatása előtt, nem pedig kizárólag egy boot vírus ellen készült, annál több.
Szerintem ez nagyon jó dolog lehetne, ha nem basszák el és nem kerülnek ki privát kulcsok, meg nem próbálják kisajátítani vele a piacot.
Ami még homályos, hogy egy működő rendszer esetében ez mennyire jelenthetne biztonságosabb rendszert? Mert a betöltési folyamat ok, ott egyértelmű. De ha böngészőn keresztül egy sebezhetőséget kihasználva elindítanak egy idegen kódot a már futó rendszeren, esetleg az még privilégium szint ugrást is végre tud hajtani, akkor attól kezdve már gond van. Tehát értelmezésem szerint a TC arra jó, hogy biztos lehetsz benne, hogy reboot után tiszta rendszer indul el - többre nem. Jól értem?
- A hozzászóláshoz be kell jelentkezni
Hmmm... Én most csak az UEFI Secure Boot-ra reflektálok. Amennyire én tudom ez csak a boot folyamatért és a kernelszintű dolgokért felel, a userspace dolgokért nem.
A Trusted Computing? Igen mindenképpen van létjogosultsága, ahogyan minden biztonságot jelentő dolognak, de ez nem szabad, hogy elvezessen oda, hogy lehetetlenné tesszük mások szereplését akár technológiai akár piaci szempontból. Egyébként itt is meg kellene határozni szinteket, mert lehet, hogy ami megbízhatóvá tesz egy céges rendszert az használhatatlanul megkötötté tenne egy személyes használatú gépet, ugyanakkor elégtelen lenne egy katonai rendszerben.
Egyébként inkább morális kérdéseket próbálok feszegetni.
- A hozzászóláshoz be kell jelentkezni
,,Az UEFI meg nem fogja felajánlani az folytatás lehetőségét, hanem bekapcsolt secure boot mellett egyszerűen nem tölti be az aláíratlan binárist."
Szerintem fogadhatunk. Az alaplapgyártók és BIOS írók nem hülyék. Állítom, hogy a desktop linuxot desktop linux léténél fogva nem fogja érinteni, mindenki másnak - desktop windows, szerver és magasabb szintű rendszerek - meg jobb lesz.
- A hozzászóláshoz be kell jelentkezni
Ezt most hogy érted? Netán úgy, hogy Linuxot minden UEFI-s rendszer macera nélkül betölt, vagy, hogy a (desktop) Linux annyira nem tényező, hogy nem számít, hogy betölti-e vagy sem?
- A hozzászóláshoz be kell jelentkezni
"Hát ez szerintem sem a Linux, sem a Windows rendszereken nem a legkihasználtabb biztonsági lyuk."
Mit mond neked az a fogalom, hogy rootkit?
--
"You're NOT paranoid, we really are out to get you!"
- A hozzászóláshoz be kell jelentkezni
Te windowst arulsz ?
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Aki nem mainstream rendszert akar használni, az egyszerűen kikapcsolja a Secure Bootot, mert tudja, hogy mit csinál.
- A hozzászóláshoz be kell jelentkezni
x86-on igen és ARM-on?
- A hozzászóláshoz be kell jelentkezni
Szerintem én az a feléhasználó leszek, aki inkább kikapcsolja ezt a marhaságot, minthogy 20-szorosan láncolt botloadert használjak, de azt nem értem, hogy ez miben lesz jobb, majd betölti a malvaret, a feltört, és alárt kúlccsal rendelkező os. Szerintem ez a világ legritkább támadási módja. Még életemben nem hallottam (ill hallotamm, de még látni nem láttam) ilyen jellegű támadást bármi ellen. Azon felül, ha ez nem lesz kikapcsolható, akkor az ugyancsak korlátoz a személyes szabadságomban, hisz kizárt pl hogy linuxot, vagy bsd-t.... használhassak.... Szóval ez ugyancsak támadható dolog.
------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
https://isc.sans.edu/diary.html?storyid=13366 [boldi ezt nem tudta?]
- A hozzászóláshoz be kell jelentkezni
Itt a lényeg! Mostantól a trusted computing azt fogja jelenteni, hogy az MS IT infrastruktúrájában kell bíznunk :)
- A hozzászóláshoz be kell jelentkezni
http://www.youtube.com/watch?v=mLoIcdIu_Kk
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Köszi, ez nagyon találó ide.
- A hozzászóláshoz be kell jelentkezni
De ez nem csak a boot lenne, hanem a komplett pc-ben minden titkosítva menne. Ez tényleg nem szólna másról, mint a monopólium megőrzésről. Ha ez bejön én elkezdem felvásásrolni a régi gépeket, és aból építek inkább pc-t, a még normális vasakból. Maximum elektronmikroszkóppal kel majd hardvert törni. Remélem ez az idő soha nem következik be.
------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Jó én is részben iróniának szántam, de szerintem nem lenne lehetetlen. Megveszel 50-100 hardvert. abból felépíthető a belső kapcsolást, (szoktak így kémkedni, hogy elektronmikroszkóppal megnézik a felépítést), abból pl kiszedhető, hogy hol található beépített memória, már csak egy olvasó áramkör kell..... A kulcsokat ellopni, pedig még egyszerűbb. Biztosan van egy két alulfizetett ember.
------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.
- A hozzászóláshoz be kell jelentkezni
"A kulcsokat ellopni, pedig még egyszerűbb."
Szerintem ott csak publikus kulcs párok lesznek.
- A hozzászóláshoz be kell jelentkezni
Akkor nincs több ötletem. Bízzunk a kihasználható hardverhibában.
------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.
- A hozzászóláshoz be kell jelentkezni
Lehet én értelmezek valamit rosszul, de nekem az jön le, hogy a legelső binárisnak kell aláírva lennie. Az meg attól kezdve azt csinál amit akar.
Tehát ha a nagy Linux diszribútorok leimplmenetálnák a saját aláíró rendszerüket minden kernel, kernel modul és egyéb binárishoz (akár a szállított userspace bin-ekhez is) és létrehoznák rá az infrastruktúrát, akkor igazából jó is lehetne a dolog.
Mivel akkor elég lenne azt a nyamvadt grub-ot aláíratni több platformon, és szállíthatná azt a többi disztribútor is. Az meg tartalmazná a disztribútor kulcsát, ezzel ellenőrizne egy elő töltött binárist, amely ezzel a kulccsal tovább ellenőrizhetné a betöltés előtt a kernel bin-t meg a többit.
A disztribútor (pl. RedHat Fedora supporter-ként) meg aláírná más disztribútorok kulcsát. Ezt sem kellene minden új verziónál eljátszani, ezért kivitelezhetőnek tűnik.
- A hozzászóláshoz be kell jelentkezni
Nincs benne a cikkben, de nekem valami olyasmi is rémlik, hogy gpl (vagy gplv3) licencű programoknál nem csak a forrás, de az aláíráshoz használt privát kulcs átadása is kötelező, ami eleve hülyeség mert akkor minek aláírni. Mindenesetre ez eléggé kivitelezhetetlen, ha egy 3. személy a saját privát kulcsával ír alá, amit érthető okokból nem ad ki.
- A hozzászóláshoz be kell jelentkezni
Fu bazze , ez nem semmi :)
http://en.wikipedia.org/wiki/Tivoization -gyanus eset ?
Akkor irni kell, egy other boot loadert nem GPLv3+ alatt, ami betolt egy bonyolultabb boot loadert pl. a grub2 -t:)
Amig ki lehet kapcsolni a secure bootot ,addig nem Tivoization.
Amig senki nem ad tovabb alairt grub2 -vel elattot rendszert amin nem lehet kikapcsolni secure bootot addig senki sem szegi meg.
Az egesz egy vicc.
99$ dollarert barki alairhat boot loadert, aztan az a boot loader betolti a virust es a windozert es az egesznek semmi ertelme.
Aki meg alairatta majd annyit mond: "sorry".
Vajon mennyiert irat ala egy hajlektalan egy boot loadert ?
Majd mindig BIOSt/UEFI kellene frissitenem, hogy tudhasson a gep a viszavont alairasokrol?
Mi, lenne ha a user egyszeruen beallithatna milyen alairasokban bizok meg ? Bios menuben explicit import keres a halon jelen levo DHCP option alapjan, vagy betoltes USB mass-sotrage-rol, vagy begepeles, vagy hagyomanyos/USB soros eszkozrol ...
Ha valoban, secure bootot akarnek, csak az altalam hitelesitett binarist fogadhatna el a gep, semmi MS vagy CIA vagy jotment 99$ -os csoves kodjat.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Ha ez bejön én elkezdem felvásásrolni a régi gépeket, és aból építek inkább pc-t
Kezdd el már most!
Cyrix 6x86 processzor és hozzá való alaplap eladó!
- A hozzászóláshoz be kell jelentkezni
:) Neked még van olyanod? Igazi rettenet volt.
------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.
- A hozzászóláshoz be kell jelentkezni
Hmm...
"Ha ők nem bíznak benned, neked miért kellene bíznod bennük?"
Talált.
- A hozzászóláshoz be kell jelentkezni
na, ez megint szar megoldas egy nem letezo problemara. ameddig uj firefoxot kell kiadni, ha kajmanisztanban valaki meghekkel egy CA-t, addig baromira ne jojjon nekem senki tanusitvannyal vedett boottal.
- A hozzászóláshoz be kell jelentkezni
Tanúsítvánnyal védett bot lesz az.
:)
- A hozzászóláshoz be kell jelentkezni
Egyetertek.
Egy nemletezo problemara nyujt rossz megoldast az egesz. Es gyanitom az ms celja nem is valamely problema megoldasa, hanem egy szabvany moge rejtett vendor lock-in terjesztese.
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Jelenleg a Windows 7 védelmét a bootloaderen keresztül játsszák ki, igaz?
...mert arra megoldás lehet ez az egész trusted mizéria.
Persze ettől még találhatnak rá más megoldást, ilyen értelemben a Fedora-féle loader egy lyuk a pajzson...
- A hozzászóláshoz be kell jelentkezni
pont emiatt vagy sose valosul meg, vagy turot sem er a trusted boot
- A hozzászóláshoz be kell jelentkezni
++;
Ha már mindenképp kell, akkor miért nem lehetne az UEFI-t tanuló módba állítani, ahol eltárolja a betöltött binárisok hash-ét. Ha megváltozik a hash, akkor az igényeknek megfelelő policy-t lehetne definiálni.
- A hozzászóláshoz be kell jelentkezni
Ez tetszik.
Problem solved :)
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Sztem mintha éppen az lenne a lényeg, hogy a BIOS bele van égetve az alaplapodba, és attól kezdve végig megbízható modulokat használsz. Ha a BIOS dinamikus, akkor az ugyanúgy sebezhető - nem megyünk vele semmire.
- A hozzászóláshoz be kell jelentkezni
Már mindenhol flash chipeket használnak, a "beégetős" korszaknak már vagy 10 éve vége.
- A hozzászóláshoz be kell jelentkezni
De ha egyszer ki lehet kapcsolni, akkor nem dinamikus? :)
- A hozzászóláshoz be kell jelentkezni
Nem qurvára mindegy, hogy a boot folyamat melyik szakaszában töltöm be a vírust??????? Ez nem jó másra csak az 1.0-s userek ellehetetlenítésérére, hogy azon túl amit kapnak ne tudjanak mást használni...
-------------------------------------------------------------------------------------------
Mit használok? Na, na, na? Hát blackPanther OS v11.1-et * www.blackpanther.hu
- A hozzászóláshoz be kell jelentkezni
"Nem qurvára mindegy, hogy a boot folyamat melyik szakaszában töltöm be a vírust???????"
Es te meg mindig disztrot fejlesztesz?
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
omfg. kerlek, mondd, hogy nem IT-vel foglalkozol!
- A hozzászóláshoz be kell jelentkezni
Tfh adott egy termeked, teszem azt egy appliance. Felteszem garantalni akarod a box serthetetlenseget, mert a szolgaltatast veszik toled es a boxra csak ugy jar garancia, ha Gizike nem nyul bele. Ezekre mar most is van megoldas, bar ezek kicsit hack jelleguek, es pont az ilyen hack jellegu megoldasok helyett lenne egy egyseges megoldas == TC.
Vegfelhasznalo szempontbol lehet fujogni, de mint gyarto es mint szolgaltato szukdeg van ra, hogy garantalni tudd azt, amit elvarnak toled, ugy ha belepiszkalnak, akkor tudd azt mondani, hogy nem a termekben van a hiba, hanem abban, amit mas elganyolt benne.
___
info | Tresorium
- A hozzászóláshoz be kell jelentkezni
aztan majd a shimmel toltik a rootkiteket a haxorok? kemeny 100 usd-t azert ossze tudnanak guberalni
--
NetBSD - Simplicity is prerequisite for reliability
- A hozzászóláshoz be kell jelentkezni