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.
"Je mráz, NEOLIZUJTE KOVOVÉ ZÁBRADLÍ!"
Zlate casy, ked BIOS bol BIOS a nie tie vymalovane picoviny jak dnes. Zlate casy, ked ziadne UEFI neexistovalo. Zlate casy, ked pri kupe softveru som dostal aj License Key.
:(
To není o vymalovaných píčovinách. Řada desek měla UEFI už dávno, akorát se to nevědělo, protože se o tom nikde nepsalo, UEFI specifické funkce (zejména boot) se nepoužívaly a nemělo to grafické, ale textové rozhraní.
A imho když se na UEFI desku nainstaluje Linux v legacy módu, tak ani tomu UEFI neublíží, protože se s ním deska přes UEFI vůbec nebude bavit.
Zlate casy, kdy se IRQ na kartach nastavovala pomoci jumperu a za slozeni pocitace si bylo mozno uctovat 5000 Kc, protoze to bezny uzivatel nedokazal..........
BIOS byl BIOS - a? Neprehledne, vsechno se muselo nastavovat rucne.
Licencni klic k software - na co? Kdyz jsi ztratil licencni klic k Windows, nikdo ti novy nedal. Klic v BIOSu pocitace ztratit nemuzes.
"Klic v BIOSu pocitace ztratit nemuzes."
Jasně vlku, věřím ti, Karkulka zůstane celá... :-D
Vyjma případu chyby desky (nedávno při nákupu 18 počítaču nám během prvních 3 měsíců odešly zcela MB v 5 z nich, btw. Gigabyte). Vyjma přemazání flash UEFI/BIOSu. Vyjma výměny desky za lepší/výkonnější model. Vyjma krádeže počítače...
Ale jinak o tu licenci opravdu nemůžeš přijít, k takové politováníhodné situaci dojde opravdu nejvýše 4x za rok...
zase, nie je to tak davno, co steam kvoli chybe v skripte mazal vsetky subory uzivatela, v pripade, ze by niekto spustil steam pod rootom, tak mu to moze zmazat vsetko. Preto je v linuxe podstatne vacsia sanca, ze sa nieco taketo stane omylom. Vo windowse musi byt ten kod na zmazanie eufi premennych napisany explicitne.
"niekto spustil steam pod rootom, tak mu to moze"
Jestli nekdo pousti steam pod rootem, tak je vymaz disku zcela drobny problem vuci tomu, ze ma vymazany mozek...
Až na to, že pokud se nic během posledního roku nezměnilo, tak má SteamOS root účet defaultně deaktivovaný.
To je krásný příklad toho jak funguje Open source komunita. Jo napsali jsme kód který to může celé jedním jednutím zmrvit ale to není náš problém, my jsme kingové a oni to mají blbě.
Proč je vůbec nutné do UEFI hrabat ze sysétmu? Dyť se počítá jeho kontrolní součet a porovnává se to s tím co je v TPM a když se neshodují tak se nebootuje (neříkalo se tomu Secure boot?)
Jak už bylo řečeno, tato chyba je i na Windows, takže se nejedná o chybu OS ale UEFI, nebo přesněji jeho implementace na dané desce. Vždy se musí předpokládat, že se sotware (včetně OS) bude chovat nekorektně (zásahem viru, skryté chyby nebo lidské blbosti) a takové stavy ošetřit.
Jak se tady už psalo, na Windows bys na to musel napsat program a spustit ho s vyššími právy.
a co ze vyzaduje vyssi prava? vzdyt rm --no-preserve-root -rf / vyzaduje pravo roota
Dobre mozna dodat, ze root je v Linuxu nejvyssim opravneni v systemu a nemel by se nikdy pouzivat pro bezne uzivani pocitace. Administrator nebo ucet s pravy administratora ve Windows ma urcita omezeni, root na bezne nastavenem Linuxu ne.
"Administrator nebo ucet s pravy administratora ve Windows ma urcita omezeni, root na bezne nastavenem Linuxu ne."
To bych rád věděl, jaká omezení má ten Admin na Widlích. Vyjma toho, že mi ten jejich bastard Powers Hell odmítá čas od času provést nějakou akci, protože jako Admin nemám právo mít plnou kontrolu nad svým systémem (velcí bráškové v Redmondu vědí líp, co potřebují a musí mě, malého, hloupého hlídat, abych JIM nerozbil SVŮJ počítač), můžu vesele pouštět, instalovat a kompilovat cokoli a odkudkoli. Ani není potřeba zalamovat se nastavováním nějakého spouštěcího práva u čerstvě vygenerovaného souboru jako na POSIX systémech.
Také bych rád viděl ten standardně nastavený Linux s rootem, vzhlem k tomu, že většina současných distribucí roota defaultně zakazuje a rootovské aktivity se provádí přes sudo z privilegovaných účtů majících přidělená konkrétní individuální privilegia...
Asi takove, ze ta parodie na OS porad respektuje prava vlastniku na NTFS. Jako windows administrator jste jen jiny user z pohledu systemu, ktery si muze dovolit vice pokud chce (menit vecem prava), ale by default je stejne omezeny a nikam se nedostanete a prd s tim udelate. Sere me to hlavne pri presouvani dat z celeho disku - nektere slozky jsou proste nedosazitelne/nesmazatelne bez explicitni zmeny vlastnika a pak kdyz to udelate, ztracite puvodni obsah. Je to cely naprd z tohoto pohledu.
Oproti tomu root na linuxu je user, ktery muze uplne vsechno a bez jakychkoliv kontrol (pokud tedy nejedete na SE, coz neni bezna soucast desktop instalaci). Takze si vesele presouvam cokoliv kamkoliv. Jako opravdovy administrator!
A účet(né doménový) Administrátor má jaká práva? Většina BFU má svůj účet s právy Administrátora a vypínají si ten "otravný" UAC - návodů je dost.
„na Windows bys na to musel napsat program a spustit ho s vyššími právy“
Totéž v Linuxu.
Je nutné mít něco, co ten adresář smaže, a spustit to s administrátorskými právy.
Specifikace UEFI zahrnuje spousty věcí - je to spíš takový rámec - a Secure Boot je jen jedna část, kterou je možno (ale není nutno) implementovat.
Do UEFI je vhodné hrabat ze systému z toho důvodu, když např. máme dual boot Linux/Windows a aktualizace Windows nastavení UEFI přepíše tak, že se v nabídce zobrazují jenom ony. Pak přijde vhod záchranná flashka s Linuxem, ze které se to nastaví do původního stavu.
Co kua maju vsetci s hackermi? Len minuly rok sme mali dva pripady, ked niekto vydal instalator s preklepom, co premazaval uplne nespravny adresar. Pri bugu takehoto kalibru buduci rok ani nebudeme vediet, co tie masiny odpalilo...
Když člověk používá takový software od takhle schopných "programátorů", tak dobře vám tak.
Kupujete běžně chleba od člověka, který nerozlišuje sůl a kyanid, vesele papáte a příležitostně se divíte, jaktože Pán Bůh neudělal vašeho kamaráda readonly na kyanid? :-P
Eh, čo? Samozrejme, že to nepoužívam...
Ono systemd je čosi ako windows linuxového sveta. Veľa lám ho dostane predinštalovaný, niektorí to s ním vzdajú, ale dobrovoľne si ho nikto príčetný na stroj nedá...
Na OSX už od 10.11 root k /bin, /sbin, atd. nemůže. jedině po rebootu s kernel parametrem.
Stejně tak nepřipojí debugger k systémovému procesu a nezavede nepodepsaný modul do kernelu.
Nedíval bych se na to jako na primárně ochranu proti hlouposti, ale především jako účinné bezpečnostní opatření.
Ale souhlasím, že tohle by neměl řešit systemd, ale o level jinde.
Tak na SELinuxu taky muzes mit ledacos zamcene. Ale BFU to nevnutis protoze pak blbe funguji Xka.
To možná, ale rozdíl je v tom, že kdyby SELinux byl by default všude, tak by se linuxová "komunita" vzbouřila a vrátila by se zpátky k MS-DOSu.
Kdybys rekl BSD, ale MS-DOS? Ani ve snu. A spravna odpoved je, ze kdyby byl jen default tak si ho normalne vypnou. Ani v souvislosti se systemd se nemluvi o navratu k DOSu, i kdyz o BSD obcas ano ...
V Solarisu šly zavádět moduly jenom před bootem jádra. Jestli je to super bezpečnostní featura nebo tuze otravná nedokonalost ať si každý rozhodne sám, ta hranice je velmi tenká. :-)
Svadi to na UEFI implementaci coz je mozna castecne pravda, ale to nevysvetluje proc montuji UEFI jako trvaly FS s pravy na mazani.
To je zase idiocie implementace uefi v linuxu. Uplne by melo stacit aby se pri bootu udelala kopie do lokalniho FS a zadne problemy by nebyly.
A pro smazani staci pouzit "rm -rf ." pokud se uzivatel nachazi v root FS a dostat se do "/" lze i omylem.
Jaka kopie do lokalniho FS sakra? Klidne to muze byt read only, nebo treba read only jen urcite soubory.
Ak sa nemýlim príkaz # rm -rf / nič nespraví už niekoľko rokov je tam poistka ak by sa to stalo museli by ste to spraviť príkazom # rm -rf --no-preserve-root / a to asi nespravíte omylom.
Jednou z výhod Linuxu oproti Win je to že tam máte pevne oddelené roota od užívateľa. A ak niekto robí pod rootom je to len jeho zodpovednosť ak niečo pos..e.
Problém je v tom, že root není osoba, která si může nebo nemusí dávat pozor, ale úroveň práv. Kterou může mít buď uvědomělý a zodpovědný člověk, totální magor, proces běžící s právy rooty nebo proces, který se k právům roota dostane exploitem. Proto má smysl, aby byl i root omezen překážkami, které je potřeba překonat.
Prave proto, ze root neni osoba ale uroven prav, nema smysl mu neco zakazovat. Ma smysl zarizovat, aby "normalni" veci sli delat i s mensimi pravy, ale omezit roota a zavest "superroota" ktery bude moct vsechno muze zabrat jenom na Windows uzivatele (kterym takhle omezili administratora). Specialne pokud se proces k pravum roota dostane exploitem, co vas vede k myslence, ze by se nedostal i k pravum superroota?
Bravo pane Ježku, dneska už posruhé užitečně a na výbornou, fakt jste mě mile překvapil :-O A jinak, s tím lidským faktorem, ten stojí vpodstatě za každou havarií PC a je úplně jedno jestli BFU přehazuje kabeláž "za letu" tak dlouho než ho to zevnitř ožehhne, mačká OK u CCleaneru tak dlouho, než system konečně upaží a je zralý na reinstall a nebo razí teorii "když mailem přijde odkaz, je třeba na něj kliknout" ... je to jedno, nemůže za to ani "špatný hardware", ani "blbej software", ani "internetový podvodník", vždycky je zatím lidský faktor na konci řetězce :-)
Úžasná chyba: správce systému (root) může změnit nastavení systému a tím ho vyřadit z provozu. Na to jako správce nemusím používat ani Linux, ani "rm -rf /" ani systemd.
Chyba systemd to není - kdyby zakázali změnit UEFI parametry pomocí filesystému, tak bude jiná cesta jak parametry změnit. Přece jenom systemd zpřístupňuje jen to, co je přes nějaké API již dostupné.
1) Buď tedy root nesmí mít přístup měnit UEFI parametry žádným způsobem (třeba jen po spuštění systému ve speciálním režimu)
2) nebo deska musí být schopna po nastavení neplatných hodnot být schopna se vrátit do výrobního/bezpečného nastavení.
Vidím rozdíl mezi tím zabít si příkazem systém a zabít příkazem určeným ke správě filesystému HW.
Mam pocit, ze dulezite promenne jsou read only, a ke zmene je zapotrebi klic, nebo tak neco. Z hlavy nevim, musel bych to hledat.
Já nikdy moc neuznával tu sématiku. rm -rf / aneb česky "odstraň tento počítač (včetně hardwaru)".
No je to logicky konzistentní, jenom nešikovné. Stejně jako rm na disku odstraní něco z FAT tabulky (a podobně), tak v UEFI odstraní nějaký parametr z tabulky parametrů.
Mě se spíš líbí u souborů typu device a jiných specializovaných (tzn. nedatových) sémantika, že buď smazat nejdou vůbec, případně jejich smazání pouze odstraní přístup k danému rozhraní. A skutečné smazání něčeho uvnitř by bylo něco jako cat "./cesta" > ./delete
"Správně" se to asi má dělat tak, že se přihlásím jako "root". Vytvořím si uživatele třeba "subroot" a dám mu přesně to minimum práv, které budu potřebovat, abych se takovýmto chybám vyvaroval. Přihlásím se jako subroot a udělám to co potřebuju. A zase toho uživatele smažu. Samozřejmě to asi nikdo zdravý z pochopitelných důvodů nepodstupuje.
Proc bys toho subroota mazal? Osobne nechapu, proc neni mozne normalnimi prostredky nastavit uzivatele, ktery by mel pouze cast capabilities ... vsechny capabilities funguji na proces a ne na uzivatele, ten zustava root.
Protože jsem se snažil nastínit absurditu "principu nejnižších privilegií" při použití v praxi. Ten uživatel bude mít tak specifická práva, že po splnění svého účelu nemá smysl ho zachovávat. Samozřejmě pokud je potřeba, tak bych ho nemazal.
No pak mezistupeň mezi touto paranoiou a děláním všeho jako root, je nějaké rozumné použití "skupin", ale to asi taky málokdo si s tím hraje, obzvláště pokud skupina kterou člověk zrovna potřebuje není už definovaná distribucí.
Oceňuji, že redakce dočetla bugreport až do konce :)
Ovšem "Aktuální problém linuxového světa..." to je trošku silná káva... :-D
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.