BootHole: Bootolhatatlanná teszi a Grub2 frissítés (nem csak) a RHEL rendszereket

Egy frissen nyitott bug szerint az RHSA-2020:3216 biztonsági frissítés a Grub2-höz bootolhatatlanná teszi a RHEL rendszereket.

Hozzászólások

Ó, a picsába, ezek a majmok teljesen elrontják a játékomat, mert ezután majd minden Windows 10 gyalázó hozzászólásomnál tutira ezzel fognak visszavágni a hobbitkák, hogy dehát a linux is szar.

És a legrosszabb, hogy igazuk van, márpedig azt utálom. :-(

Nem fognak visszavágni. Álhír. Mindenki hazudik, monnnyonle, whatever. Volt nem is rég egy másik fórumon egy szagértő gyerek, jött nekem hőbörögni, hogy az Arch, amit használok, az nem jó szerverre, meg ilyen hobbista instabil rolling, bezzeg az RHEL, az micsoda vállalati, meg hosszútávú support meg kutyapöcse, böff. Közben meg Archon nem volt semmi gondom, bár az igazsághoz hozzátartozik, hogy GRUB-ot sem használok, systemd boot megy helyette, illetve nem systemd-s disztrón EFI stub boot, amikor mindjárt a kernel bootol. Tehát nem, nem ×4r a Linux, csak nem ilyen enterspájz bullshitet kell használni belőle. Hiszen az egész linuxozásnak az a lényege, hogy az ember dönti el, hogy mit akar, milyen bootolás/bootmanager, milyen initrendszer, milyen grafikus felület/protokoll, stb.. Nem muszáj használni sem ilyen vöröskalapot, se GRUB-ot, senki nem kényszerít rá, ezek nem egyenlőek a GNU+-/Linuxszal. Ez nem Windows, hogy egyféle megoldást kell használni mindenkinek, amit elé raknak, meg amit egy multi előírt nekik.

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

Ez is csak arra bizonyíték, hogy a Secure Boot jó nekünk.

Ez a biztonság irányába tett nagy lépés. Ha nem bootol a gép, feltörni sem nagyon tudják. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ja, '13ban elmúlta magát. Ami hasznos, a githubon kint van, a vas meg eladó /elvihető. Egy HP ProLiant D380 g3 vagy micsoda, rég volt... Nem volt hely a gépnek, de elvileg működik.

Azon a gépen volt a gentoo.inf.elte.hu is, a géppel ment...

Nem, a black pantherhez semmi közöm.

Csak már jó lenne, ha lenne megoldás is a hibára.

A laptopomon lévő CentOS 8-nál nyomtam egy dnf upgrade-et 3 napja, majd az első reboot-nál nem indult el a masina. Eleinte gyanútlanul csak néztem, aztán csak mentem befelé az erdőbe. Kellett egy idő, mire világossá vált, hogy az EFI körül kell keresgélni. Aztán izzadtam vagy 3 órát, mire visszahoztam a halálból. Többrétű feladat volt, USB CentOS8 telepítő -> rescue mód -> a merevlemezen lévő grub helyrekalapálása -> utána a gépről csak valami rescue módban indult és a telepített kerneleket is helyre kellett lökni.

Hatalmas szívás, nagyon kellett a 20 éves rutin, hogy ne legyen újratelepítés belőle.  Utólag is gratulálok a RedHat-es srácoknak. :-((

kb.

ha lecserelted a kernelt, le kellett futtatni a lilo parancsot, ami vegignezte a kernel blokkjai fizikailag hol vannak a disken, es letarolta az lba vagy chs cimeket a map fileba. amilyen egyszeru olyan nagyszeru, evtizedekig jol mukodott.

es igazabol az uefi miatt nem is kene az elilo/grub mar, meg lehetne ugy csinalni a kernel imaget hogy kozvetlen induljon efi-bol.

Ezzel az UEFI-vel ne is bosszants! Valamikor fordítottam kernelt forrásból, és azért nem tudtam beboot-olni, mert nem volt aláírva. Gyanítom, nem is írhattam volna alá, mert akkor bárki aláírhatná a rosszindulatú kódját. Egyáltalán kiknek van ehhez aláíró kulcsa, s ők hogyan szerezték?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

https://wiki.freebsd.org/SecureBoot

Secure Boot requires that all boot-time code be signed by a private key whose public counterpart is known to the boot firmware. Currently the only key that is guaranteed to be present in any given system is Microsoft's. Additionally, to be certified for the Windows 8 logo program, systems must be have Secure Boot enabled, although they must provide a way to disable it and they must allow the user to add keys to the system. Microsoft also provides a service where binaries can be forwarded to them for signing with their key.

Hogy kapjanak Windows 8 certet és árulhassák Windows-zal a gépeiket... (egyébként én még olyan géppel nem találkoztam, aminél ne lehetett volna letiltani az SB-t)

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

Youtube-videó szerint a szokásos "jajúristenkellasupervisorpassword" megoldás van (miután beállítottál egy jelszót, már engedi változtatni; az ölemben levő Acer TravelMate-n ugyanígy működik [és szokásos HP bashing: náluk láttam már olyat, hogy beállítod a jelszót, utána újraindítod a gépet (!), és akkor engedi csak letiltani... no komment]).

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

Ja, tehát ha csinálok erre az EFI felületre jelszót, akkor kikapcsolhatom. Eszembe nem jutott volna. Köszönöm.

Amúgy nem konkrétan okoz egyelőre problémát, mert a Fedora team aláírja valahogyan a kernelt - gondolom, az MS szolgáltatásával -, sokkal inkább az töltött el rémülettel, hogy az MS-nek piaci zsarolással sikerült a desktop hardware-eket magához láncolnia, ami így a desktop Linux és BSD végét jelenthette volna.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem a kernelt iratták alá az ms-sel, hanem a shimjüket, a SecureBoot ugyanis a bootloadereket tölti be (ha alá vannak írva). Az ms ugyanis közölte, hogy GPLv3-as license-ű bootloader nem kaphat ms certification-t, így a GRUB-ot is kizárták. (Ha valaki, hát én nem vagyok GPL faggot, de ez nettó pofátlanság volt.) Ezért a különféle projektek ezt úgy oldották meg, hogy van egy first stage loaderjük, ami nem GPLv3-as, így van aláírása és ez tölti be a GRUB-ot. Hogy a microsoft indoklása és ez az egész balfaszkodás a certification-ökkel mekkora bullcrap, azt tessék elolvasni a Pene által adott linken; a Rufus loader írója tökéletesen összefoglalta a dolgot. Az meg, hogy maga a SecureBoot mennyire nem jó semmire, az most pláne kiderült a BootHole kapcsán.

A jogi részhez én nem értek, azt meg nem vitatom, hogy a GPL egy rettenet, ami egy csomó kötelezettséget pakol arra, aki egy GPL-es cucchoz hozzányúl. Ugyanakkor, a Rufus fejlesztője leírta, hogy miért volt bullshit az ms indoklása:

Microsoft has decided it doesn't like the GPLv3 and, in a clear abuse of power created a signing process that forbids the submission of anything that is GPLv3. Of course, Microsoft tried to "justify" their stance with a half baked tirade about how the GPLv3 would ultimately require them to relinquish their private keys, but that reasoning can easily be demonstrated to be utter bullshit when you also know that Microsoft has no qualms signing Linux shims, which, clearly, it should not sign, since these should logically be subjected to the same "alleged" relinquishing of private keys that the GPLv3 is supposed to entitle its users to, and therefore, if Microsoft's reasons are to be believed, having said shims load GPLv3 bootloaders such as GRUB (which they do) can only result in someone eventually demanding that the shims' private signing keys are relinquished, therefore completely defeating Secure Boot...

A koncepció hatékonysága már a Golden Key pániknál látszott, de most pláne látszik, hogy az egész nem ér egy vödör vizet, hiszen a GRUB ugye nincs a GPL miatt aláírva és mégis sikerült rajta keresztül a bekapcsolt SecureBoot ellenére is a kódfuttatás.
Ami miatt nettó pofátlanság volt a GPLv3-as cuccok kizárása, az pont az, amit te leírtál, hogy az ms mindenképpen megkerülhetetlen szereplő, ha SecureBoot aláírást akarsz, egyszóval itt leginkább arról volt szó, hogy az ms bepróbálkozott azzal, hogy ők döntik el, hogy mi futhat egy PC-n. Na, ez a nettó pofátlanság. Mégis milyen alapon dönti el pár koszos jenki, hogy egy random user mit tölthet be bootloader gyanánt a saját gépén? Persze kikapcsolható...még. Anno a windows 8 idején a kritikák miatt az ms kötelezővé tette a kikapcsolhatóságot, de a windows 10 pl. már egyáltalán nem követeli meg, csak az OEM-eken múlik.

a secureboot egy elhibázott elképzelés, szerintem üzemeltetőmacik találták ki

igen, finoman szólva szerencsétlen az ms szál

igen, az egészben az a legjobb, hogy kikapcsolható

a gplv3 nem pofátlanság miatt van kizárva, hanem amiatt, hogy az egyik kitétele ellentétes az egész folyamat lényegével

> a secureboot egy elhibázott elképzelés, szerintem üzemeltetőmacik találták ki

ROFL. :D

> a gplv3 nem pofátlanság miatt van kizárva, hanem amiatt, hogy az egyik kitétele ellentétes az egész folyamat lényegével

Nem úgy értettem, hogy a GPLv3-at pofátlanság miatt zárták ki, hanem, hogy az egész, úgy ahogy van pofátlanság. A jogi részhez meg mondom nem értek...csak az nem tiszta, hogy a shimeket hogy tudják aláírni, ha azok GPLv3-as cuccokat is be tudnak tölteni? Vagy valahol baki van a Rufus fejlesztőjének levezetésében?

> grubnak kell osszekaparnia a raid tombot, lvm-et, fs-t, aztan toltheti a megadott kernel fajlt.

Ezt a sokmindent akár egy külön komponensbe is lehetne tenni (elválasztva az üzleti logikától), aminek a neve lehetne mondjuk 'nukleosz'. Vagy esetleg 'kernel'. Persze ilyenek vannak készen is, például a Minix vagy a Linux.

Szerk: Természetesen van olyan, hogy egy számítógép indítását egy másik (kisebb) számítógép végzi (pl. 'szervíz processzor' néven).