A Linux kernelfejlesztők javítást küldtek be az efivarfs "rm -rf" brickelési problémára

Kernel

Ugyan "rm -rf /" parancsot általában csak idióták és lamer n00bok szoktak futtatni gépükön, de abban egyetérthetünk, hogy a parancs kiadásával nem kellene totálisan használhatatlanná, eltéglásított (bricked) állapotba kerülnie egyetlen számítógépnek sem. Pedig ha valaki önszántából, vagy "jóindulatú" tanácsra ezt teszi Linux alatt EFI-s gépén, akkor könnyen beleszaladhat egy hosszabb gép nélkül töltött pihenőbe.

A probléma a következő: EFI-s gépeken a /sys/firmware/efi/efivars könyvtáron keresztül speciális fájlrendszer érhető el, amely a számítógép UEFI firmware-ének konfigurációs változóit teszi elérhetővé a felhasználó számára. Ha ez a könyvtár rw-re van mount-olva, akkor a megfelelő privilégiummal rendelkező felhasználónak lehetősége van azt letörölni. Ha így tesz, akkor a rosszul megírt firmware-rel rendelkező gépek a következő újraindításkor megakadhatnak a boot folyamatban. A gép a POST folyamatnál tovább nem jut, azaz bricked állapotba kerül.

A probléma elsőként egy systemd bugreportban jött elő, így a "jóakarók" elkezdtek a systemd-re mutogatni. Matthew Garrett - aki egy ideiglenes kernelpatchet is összedobott hamarjában - azonban lehűtötte a a kedélyeket. A Twitter-en azt írta, hogy felesleges a systemd-t okolni a problémáért:

A kernelfejlesztők elkészítették a javítást (alapértelmezésben immutable flag-et kapnak az efivarfs bejegyzések), amit Molnár Ingo be is küldött az LKML-re beolvasztásra.

efi: Make efivarfs entries immutable by default

A javítással kapcsolatos dokumentáció ekképpen frissült:

diff --git a/Documentation/filesystems/efivarfs.txt b/Documentation/filesystems/efivarfs.txt
index c477af086e65..686a64bba775 100644
--- a/Documentation/filesystems/efivarfs.txt
+++ b/Documentation/filesystems/efivarfs.txt
@@ -14,3 +14,10 @@ filesystem.
efivarfs is typically mounted like this,

mount -t efivarfs none /sys/firmware/efi/efivars
+
+Due to the presence of numerous firmware bugs where removing non-standard
+UEFI variables causes the system firmware to fail to POST, efivarfs
+files that are not well-known standardized variables are created
+as immutable files. This doesn't prevent removal - "chattr -i" will work -
+but it does prevent this kind of failure from being accomplished
+accidentally.

( kroozo v | 2016. 02. 22., h – 09:05 )

"Ugyan "rm -rf" parancsot általában csak az idióták és a lamer n00bok szoktak futtatni gépükön"

Te hogy szoktál cliben törölni?

Max te nem találod az asszociációt benne :)

Arra akartam utalni, hogy az mc azért messze nem must have. Az említett fórumtárs meg állandóan azzal küzd, hogy mindenféle dolgokat próbál lefordítani kőkorszaki AIXokra, általában elég küzdelmesen, annó mcvel is küzdött ha jól emlékszem...

( zrubi v | 2016. 02. 22., h – 10:35 )

LOL

Hülyeség ellen egy patch sem véd. ;)

Disclaimer: I am not speaking on behalf of my employer, this is my personal opinion

--
zrubi.hu

( Zahy v | 2016. 02. 22., h – 11:16 )

Én személy szerint a "-o ro" paramétert gondoltam peccsként, de ez tényleg elegánsabb megoldás, alacsonyabb szintű védelem, ráadásul sokkal finomabban hangolható.

Ó B+

Nekik nem kellett megoldást találniuk. Más hülyeségét (szó szerint) kellett workarondolniuk. Ha a düddő firmware író nem szart csinálna, Pistike pedig nem törölgetne, semmi probléma sem lenne. Ezzel a lépéssel pörsenéses Pistikét eliminálták, mert életében nem hallott a chattr parancsról. A firmware író urakat pedig faszkorbáccsal kéne nyakon baszkodni (elnézést a szóhasználatárt, még a tegnap délutáni film hatása alatt vagyok).

--
trey @ gépház

Nem kell ezt túldramatizálni. Gamer Pistike simán be tud egy pipa kivétele után a gépén NVIDIA/AMD utility-vel olyan GPU / RAM órajelet beállítani, amivel tetszőlegesen lefagyaszthatja vagy akár rommá sütheti a motyóját. Mégse cimmogunk rajta. Ha ez így van, akkor miért tiltanád meg a root felhasználónak, hogy az low level szinten piszkáljon valamit?

--
trey @ gépház

És minő meglepetés, pont ez a kernel feladata. Hardverabsztrakciós réteget adni. Aminek része az is, hogy a hardver hülyeségeit elrejtjük a user elől. Teljesen mindegy, mennyire fos a firmware. Vagy választható még lehetőségként az, hogy ezen a firmwaren nem támogatott a kernel, el sem indul.

Az UEFI specifikációnak része, hogy mely UEFI elemek érhetők el és módosíthatók futásidőben (nézz utána az UEFI Runtime Servicesnek). Viszont semmi nem diktálja, hogy a kernelen kívül bárki más piszkálná, sőt, használná az UEFI-t futásidőben.
Az, hogy Linuxnéknál ezt egy shellből is el lehet érni filemanipulációval - bravó, szép munka!

Az EFI specifikációról eddig jót még nem, rosszat annál inkább hallottam. Meg arról is, hogy régen feltalálták, a redundáns firmware-t, már a gagyi, elavult BIOS idejében is. Vagyis ha a master megsérül, vagy frissítés közben tönkremegy, akkor a backup elindul. Sikerült úgy tűnik megint visszafelé lépni.

Lehet itt kenni a szart, hogy a hardver/firmware gyártó miért gyárt olyan fos rendszert, amit OS oldalról el lehet így baszni... Semmi gond nincs vele, mert magának csinált vele problémát. majd szépen addig garanciáztatják nála ezt a szart, amíg meg nem oldja az elmaradt házi feladatát.

--
trey @ gépház

Eleve ami implementációspecifikus (nem-standard) változó, ahhoz a kernelnek hozzá sem szabad nyúlnia egyáltalán. Pont azért implementációspecifikus, hiszen nem tudhatja, hogy a módosításnak milyen következménye van. De a Linux baromi okos, csakazértis hozzányúl, és kiengedi a user felé is. Mert az biztosan jó dolog.

Tehát kiderült, hogy a firmware bugos, a gyártó nem szabvány változókat vezetett be, amit ha letörölnek (megjegyzés: _root jog mellett_ úgy, ahogy értelmes ember azt sosem csinálja), az egész szara összeborul és még mindig a Linux a hülye... OK.

--
trey @ gépház

Ha van nem szabványos változó, akkor az nem ok nélkül van ott. Implementációs részlet. Amíg az UEFI a kernel felé a szabványos interfészt mutatja, addig nincs is baj. Csak éppen Linuxék megengedik az UEFI implementációspecifikus részeit is basztatni tetszőleges root jogú szoftver által. Gratulálok.
Olyan ez, mintha engednéd, hogy a GPU regisztereket módosítsad a GPU driveren kívül, majd csodálkoznál, hogy nincs kép.

A HAL az a kulombsegeket kellene elrejtse. Ha egy gyarto hozzaad valami HW-specifikusat, akkor azt miert ne engedne a kernel, hogy piszkaljuk?
Amugy is csak root-nak van joga a firmware-t piszkalni, es ahogy valamelyik disztro alatt kiirja, elso alkalommal, sikeres sudo utan: "With great power comes great responsability" :)

"... speciális fájlrendszer érhető el, amely a számítógép UEFI firmware-ének konfigurációs változóit teszi elérhetővé" Kicsit magyartalan, de érthető: nem a firmware érhető el, nem írható. Ha egy firmware egy hiányzó (mert pistike letörölte) konfig miatt eldobja magát, az legyen már a firmware hibája.

( lberes (nem ellenőrzött) | 2016. 02. 22., h – 11:47 )

Tudom, hogy maga a megtestesult gonosz, de miert nem lehet mondjuk Solarisos modon megoldani?:

rm of / is not allowed

--
L

( pepelopez | 2016. 02. 22., h – 12:17 )

"velem nem csesztek ki dd if=/dev/urandom of=/dev... " :))

( salaud v | 2016. 02. 22., h – 14:56 )

Megint a "védjük meg a hülyéket önmaguktól" amcsi gondolkodás. Annyira védünk már mindentől mindenkit, az emberiség meg elkorcsosul a hülyéktől. Aki hülye, ne használjon linuxot admin joggal. Aki meg mégis, az majd megtanulja. Ha meg nem, hát istenem, ezt hívják természetes szelekciónak.

---
A Linux nem ingyenes. Meg kell fizetni a tanulópénzt.
Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!!
Mindenki jó valamire. Ha másra nem, hát elrettentő példának.

Főleg, hogy a gyökérnek ki is írja, hogy amit el akar követni, az nem helyes:

# rm -rf /
rm: it is dangerous to operate recursively on '/'
rm: use --no-preserve-root to override this failsafe

Képen:

https://flic.kr/p/EkXVJw

Ennél többet mit lehetne?

Szerintem be kéne tiltani az rm parancsot! Faszt akar valaki törölni?

--
trey @ gépház

( Zs | 2016. 02. 22., h – 16:11 )

Hát, skacok, nekem még valamikor a 90-es évek nagyon elejéről van valahol egy szép, A4 méretű könyvem a számítógépről. Mottóként emígy nyitott: intelligens eszköz intelligens kezelőt kíván.

ahogy nézem egyedül neked derenghetett fel egyedül, hogy miért pont úgy írtam azt a szót (a többiek csak azt látták, hogy ott egy szó, hibásan). persze nem írtam idézőjelben, vagy *SIC* jellegű megjegyzéssel. :) sebaj, legalább pöröghettek valamin, aminek a tartalomhoz semmi köze. azt úgy sem biztos, hogy megértették.

--
xterm

te, mint hiba nélkül való nyilván értetted amit és ahogy írtam. csak az alteregód inkább rugózik egy olyan dolgon, aminek semmi köze a topikhoz ,) trollkodik, "imádom" (nem mellékesen nem magyarázat volt, hanem tény. még akkor is, ha népszerűbb hibát keresni bárkiben ,)

--
xterm

Azóta eltelt 25 év. A számítógép pedig a mindennapok része lett, és ahhoz, hogy r=1 userek is használhassák, úgy kellene működnie, mint egy mosógépnek, vagy mikrónak. Bedugod, bekapcsolod, elindul, használod, kész.
Vagy mint egy modern autó: feltankolod, beülsz, bekötöd magad, elindítod, oda megy, ahova akarod. És nem szarozol, ha valami gond van, elviszed szervizbe.
Az emberek használni, és nem üzemeltetni akarják a számítógépet. Nem te vagy a gépért, hanem a gép csak egy eszköz a munkád/szórakozásod számára.

Hát pont az autós példa járt a gondolataimban délután.Azt tudja mindenki,hogy dízelbe-gázolajat,benzinesbe-benzint.Valamilyen szinten a kettő összekeverésének a lehetősége védve van, de nem 100%-ban.Viszont azt is tudja minden autó tulajdonos,hogy a víz beöntése az üzemanyag tankba rövid időn belül a motor károsodását okozhatja.Viszont ettől a lépéstől a józan gondolkodáson kívűl semmi sem óvja meg a motort.Kívéve, ha van egy másik ember mellette aki normálisan gondolkodik és lebeszéli róla az idiótát.

A "Bedugod, bekapcsolod, elindul, használod, kész"-be az 

rm -rf /

nem tartozik bele.

A mosógép veszélyes üzem, gyapjú vagy csipkés cuccokat simán el lehet indítani 95 fokos programon, lehet egybemosni fehér és sötét színű ruhákat, és ha elfelejted beakasztani a kifolyó csövét, akkor jobb esetben csak a fürdőszobát áztatod el, rosszabb esetben a parkettázott közlekedőt is.
A mikró szintén, sokféle étel tud felrobbanni a benne fejlődő gőztől, és ha pont nem volt rajta fedő, akkor lehet takarítani, és esetleg még az ebéd is oda. Fém tárgyak, macskaszárítás... hagyjuk.
Az autó meg aztán főleg, meg lehet benne halni, és meg lehet vele ölni másokat.

Az igazi rendszergazda kezében elvileg bármikor benne van, hogy egy billentyűleütéssel agyonvághat egy rendszert, ha nem figyel. Mondjuk aki bohóckodik napi szinten storage-okkal, virtuális diszkekkel és hasonlókkal, az tudja, hogy egy álmos kézmozdulattal rövid idő alatt tetemes kárt tudna okozni.

Nyilván (jobb helyeken) a fizetésébe bele van kalkulálva, hogy extra felelősséggel kell a munkáját végezni.

--
trey @ gépház

Kedvenc (látott) hibáim egyike volt a rossz ablakban kiadott chmod 640 * , ahol is a hibabejelentés szerint a júzerek nem tudnak bjelentkezni egy felvillanó "No shell" hibaüzenettel. (Root be tud lépni.) És milyen szép volt a / tartalma a maga egységes sormintának tűnő jogosultsági beállításaival.

És ráadásul nem azért veszélyesek, mert egyszer csak nem indulnak el. Ez a kisebbik probléma. A nagyobbik az, hogy a hozzá nem értők (a felhasználók túlnyomó része) olyan adatokat tárol rajtuk különösebb óvintézkedések nélkül, aminek elvesztése vagy kompromittálódása nekik nagyon fájhat.

Igen, a számítógépek kezelése veszélyes üzem. Ha tetszik, ha nem. Odafigyelést igényel. De pl. abban is biztos vagyok, hogy anyósomék a linuxos számítógépükön sosem fogják kiadni az rm -rf / parancsot. Egyrészt, nincs rá jogik, másrészt azt sem tudják, hogy van ilyen.

Azoknak is van felelősségük, akik értenek a gépekhez és olyanok kezébe adják, akik nem. Ilyen esetben gondoskodni kell(ene) a megfelelő betanításról és/vagy a jogkörök megfelelő korlátozásáról.

Ha pedig a felhasználó ezekből nem kér && elbassza a gépét, akkor viselje a következményeit.

--
trey @ gépház