Dotaz: Parchantí nám Linux (přepsání spuštěné binárky)?

[Petr Tomášek]

Zdravím!

Po updatu na Fedoru 14 mě linux totálně šokoval, když "cp -f" odmítlo přepsat právě spuštěnou binárku. Co se to k***a děje, to se všichni zbláznili?

Měl jsem za to, že na tomto se vždy poznal ten Pravý Operační Systém™ oproti těm zk*****m Windows, že má něco jako koncept inodů, takže starý program ještě zůstane v pohodě spuštěný, anžto přistupoval ke starému inode, kdežto nový se spouští u z nového...

Jde nějak tu ****** vypnout bez patchování jádra?

Díky!

---

---

Odpovědi

[ojel]

co na to říkají na http://forum.fedora.cz/?

Nedělá to SElinux?

Osobně mi tyto "moderní trendy" taky silně vadí (grub2, plymouth, nový init, gnemeshell... - hlavně, aby to uživatel nemohl administrovat z příkazové řádky a aby to nemělo normální konfiguráky. Logy a nastavení cpát rovnou do databáze - firefox - aby uživatel neměl šanci ani zjistit, co mu vlastně nalezlo třeba do cookies. Místo vimu musí použít nějaké grafické udělátko, u něhož vůbec netuší co vlastně a jak dělá. Proč, xakru, nejdou "mladí a nadějní" vývojáři raději vyvíjet k Microsoftu a neprzní nám unix věcmi obšlehlými s Windows 7)

[podlesh]

Nejspíš to bude SELinux. Pokud to dělá u všech binárek a nejen u těch spuštěných, tak by se jen mohlo jednat o ochranu proti zápisu (ano, soubory lze chránit i proti zápisu rootem, pomocí chattr - i když zatím jsem to v praxi viděl jen u rootkitu).

No a jinak klid, tyto věci nejsou z Windows N, ale spíše z komerčních unixů (což samozřejmě neznamená že by se nejednalo o prznění)

[l4m4]

SELinux bych sice také podezříval, ale v home mohu přepisovat spuštěné binárky (s výchozí policy), jak se mi zlíbí. Text file busy dokážu dostat pouze u systémových binárek system_u binárek a bez -f. Jak vypadá stat -Z na tu binárku?

[Michal Kubeček]

v home mohu přepisovat spuštěné binárky (s výchozí policy)

Určitě? Já si tedy nevzpomínám, že by to někdy šlo, a to ani na systémech bez SELinuxu nebo čehokoli podobného.

Text file busy dokážu dostat pouze u systémových binárek system_u binárek a bez -f.

Přepínač -f způsobí právě to, že nejde-li soubor přepsat (jako třeba u spuštěného programu), smaže se a vytvoří se nový.

[pavlix]

Grub2 má normální konfiguráky, plymouth budu muset nastudovat, nový init má své výhody... ale mám za to, že se dá výběrem distribuce tomu všemu vyhnout.

[michich]

V první řadě se uklidni.

Potom napiš, jak to můžeme zreprodukovat.

[pht]

Když přepíšete spuštěnou binárku tak ten spuštěný proces nejspíš spadne. Normálně se to dělá tak, že se nejdřív smaže a pak se zapíše nová.

[aaaaaa]

Ale dovolit by mu to system mal nie? s niecim podobnym (odmietnutie prepisania binarky) som sa stretol na workstatione so SuSE so zapnutym AppArmorom...

[pht]

Ale dovolit by mu to system mal nie?

Pokud má dost oprávnění, tak může přepsat příslušné místo na disku, nebo cokoliv jiného. Systém mu to dovolí.

s niecim podobnym (odmietnutie prepisania binarky) som sa stretol na workstatione so SuSE so zapnutym AppArmorom...

Je to dokumentovaná věc syscallu open, i bez apparmoru.

[Andrej]

Proč by spadl? To tedy ani omylem.

Spuštěná binárka se mapuje do paměti tak, aby se v ní případné změny provedené někým jiným nemohly nijak projevit. Tedy zafunguje CoW a běžící program přepsání souborů s původní binárkou a knihovnami neuvidí. Kdyby tohle nějaký operační systém neuměl, byl by téměř nepoužitelný.

[Sten]

To se pletete. CoW funguje jenom na paměť, pokud však část mapovaného souboru není v paměti a někdo ji přepíše na disku, tak se potom namapuje už změněná verze. Proto tohle všechny normální balíčkovací systémy řeší pomocí rm $NAME + mv $NAME.new $NAME.

[pht]

Proč by spadl? To tedy ani omylem.

Zkuste si to.

yes >/sbin/init

Tedy zafunguje CoW a běžící program přepsání souborů s původní binárkou a knihovnami neuvidí.

Funkci copy on write na běžných souborových systémech nenajdete.

Kdyby tohle nějaký operační systém neuměl, byl by téměř nepoužitelný.

Ano ano jistě...

[pavlix]

Když přepíšete spuštěnou binárku tak ten spuštěný proces nejspíš spadne.

Důvod?

[pht]

Protože se tím přepíše jeho kód. Viz #52.

[pavlix]

Jojo, dík, už jsem měl diskuzi pročtenou celou :).

[Lol Phirae]

Třeba někdo oprášil tuhle magořinu. Jako první bych nicméně zkusil vypnout SELinux.

[Sten]

Mám zkušenost, že tohle to dělá i v Debianu a Ubuntu, kde mám SELinux vypnutý.

[pht]

Jako první bych nicméně zkusil vypnout SELinux.

A pak nezapomeňte jedním dechem odsoudit windowsáky za to, že všechno pouští s administrátorskými právy...

[Ash]

Ti to ale asi nedělají proto, aby se přesvědčili, že je problém oprávněních a pak to nerevertují zpět a nehledají systémové řešení, že :) Ti to dělají proto, aby to takto nainstalovali a mohli používat.

[pht]

Ti to ale asi nedělají proto, aby se přesvědčili, že je problém oprávněních a pak to nerevertují zpět a nehledají systémové řešení, že :)

Kdyby se chtěl jenom přesvědčit a rozuměl by tomu tak by věděl že SELinux poskytuje tunu nástrojů jak to udělat efektivněji než to vypnout. Takže ne, na mě to působí stejně.

[Atom321]

Jde ta spuštěná binárka smazat (rm -f) nebo přejmenovat? Dělá to jen u spuštěných, nebo u všech otevřených souborů obecně? A na jakém filesystému?

[Sten]

Zkuste se uklidnit a neplést si pojmy a dojmy.

cp nevyrobí nový inode, ale přepíše obsah starého. To Linux u spuštěných binárek nedovolí, protože by mu to přepsalo kód, který mapuje do paměti, a binárka by zhavarovala. Řešení je vytvořit soubor třeba $NAME.new a potom mv $NAME.new $NAME, který atomicky smaže $NAME (inode zůstane zachován, dokud program poběží) a nahradí jej za $NAME.new. Všechny balíčkovací systémy to tak dělají.

[rastos]

Tak to na mojom Slackware bude asi niečo zle. Pretože upgrade sa robí tak, že sa roztaruje balík v root-e. Ten rozhodne nejaké .new nerobí. A upgrade bežne robím tak, že zhodím X, updatnem balíky a nahodím X naspäť. Prepíšem tak glibc, bežiaci bind, openssl či sshd, ... čokoľvek. A nič nepadá.

[pht]

A víte co dělá ten tar? Nejprv cílový soubor smaže. Pak tam nacpe jiný.

[Ash]

Spíš je něco zle se Slackem, když musíte kvůli upgrade shazovat X :D

[rastos]

Ani nie s X ako s KDE. To je býva občas nešťastné, keď aplikácia loadne novšie verzie zdieľaných KDE knižníc, než má v sebe loadnutý zvyšok KDE. Aspoň myslím.

[chrono]

To Linux u spuštěných binárek nedovolí, protože by mu to přepsalo kód, který mapuje do paměti, a binárka by zhavarovala.

Linux to bez problémov dovolí (nie raz som si tak zhodil nejaký program).

[Sten]

Pokud jste tu binárku nespouštěl nějak exoticky (třeba přes ldopen + jmp), tak nedovolí. Ale dovolí přepsat knihovny, takže jste to mohl shodit tak. Dlouho se o tom vedla diskuse s Linusem, jak by měl Linux detekovat sdílené knihovny (k chráněné binárce připojené pomocí ld.so, tedy z user space) a nedovolit DoS útok (třeba kdyby user space mohlo provést MAP_DENYWRITE na „/etc/passwd“), ale nic z toho nebylo.

[ojel]

Zkoušel jste ověřit to, co tady stále dokola tvrdíte?

já jsem celý problém pochopil takhle:

1. spustím kuku.bin, což je třeba okenní aplikace, která zůstane běžet

2. otevřu si terminál a

cp bla.bin kuku.bin

výstupem je:

cp: cannot create regular file `kuku.bin': Text file busy

3. cp -f bla.bin kuku.bin

výstup žádný, binárka se přepíše, ale program běží klidně dál, funguje a nikam nepadá, jak tady bylo tvrzeno (možná je to tím, že binárka není moc velká a je celá v paměti)

Tohle je ve Fedoře 13, bez SELinuxu. A autor původního dotazu tvrdí, že ve Fedoře 14 se tohle chování změnilo, že se to i s přepínačem -f chová jako bez něj. Tak prosím, zanechte nepodložených tvrzení.

[Lol Phirae]

Asi tak nějak. Právě jsem si přepsal běžící bash busyboxem, funguje to naprosto normálně a nic nespadlo.

[Michal Kubeček]

To je pořád dokola… nic jste nepřepsal. Zkuste na to pustit strace, ať vidíte, co se opravdu děje.

[Lol Phirae]

Bezva. Takže mě cp -f funguje, když ten bash pustím znova, tak naběhne busybox, nic nespadlo, žádné chyby. Narozdíl od oněch bludů, co tady jsou označeny za řešení. (Co se opravdu děje píšou v man stránce, nicméně vám bych radši doporučil přečíst si původní dotaz a popis problému, ať se tady nebavíme vo hovně.)

[Michal Kubeček]

Trvám na tom, že jste ten soubor nepřepsal. To není jen slovíčkaření, ten rozdíl je dost podstatný. Přepsání by bylo to, co by udělal cp bez přepínače -f. Při "cp -f" (nebo obecně smazání a vytvoření nového) tam ten původní soubor zůstane až do chvíle, kdy ho poslední proces přestane používat (sice už na něj neodkazuje žádná adresářová položka, ale ve filesystému pořád je).

[Lol Phirae]

Cituji původní dotaz:

Po updatu na Fedoru 14 mě linux totálně šokoval, když "cp -f" odmítlo přepsat právě spuštěnou binárku.

Nechtěl byste se tedy vrátit k problému, který tady řešíme, místo off-topic nesmyslů a šíření zcela bludných "řešení"?

[Michal Kubeček]

Ne, nechtěl. Já totiž nereagoval na původní dotaz. Reagoval jsem na tvrzení, že se někomu podařilo přepsat spuštěný spustitelný soubor. Takové tvrzení je nepravdivé a vaše rozčilování na tom nic nezmění. Dokonce ani to, zda se původnímu tazateli opravdu nepodařilo nahradit (ne přepsat) běžící program novým souborem, na tom vůbec nic nemění.

[Lol Phirae]

Aha, takže vy jste sem přišel buzerovat s off-topic blábolením o akademických broskvovinách. To jsme opravdu nadšeni. Příště napíšu "přepsat" do uvozovek, abych se podobné debilní debatě z jedinci vašeho typu vyhnul.

[Michal Kubeček]

Nechtěl byste se uklidnit? Docela by pomohlo, kdybyste místo rozčilování pořádně četl příspěvky, na které odpovídáte, a sledoval kontext, ve kterém se vyskytují.

[Lol Phirae]

Možná by pomohlo, kdybyste si konečně ráčil přečíst ten původní dotaz. Kvůli vaší posedlosti blábolením o akademických nesmyslech nebudu slovo "přepsal" opisovat půlstránkovým technickým popisem toho, co se děje.

[Max]

Michal Kubeček jen reagoval nato, že jsi tvrdil, že se soubor přepíše. Toto slovo má svůj význam, který zřejmě zlehčuješ. Ty jsi se dopustil omylu/lži/prostě nepravdy a Michal Kubeček tě opravil. Tak už svůj úplk přijmi, neříkej tomu přepsání a bude klid .
Zdar Max

[Lol Phirae]

Já tomu neříkám přepsání, já jsem to napsal zcela úmyslně a hodlám to psát i nadále, viz předchozí příspěvek. Pokud s tím pan Kubeček nemůže žit, nechť vymyslí jiný jednoslovný výraz pro přepsání souboru pomocí "cp -f" a nechá si ho patentovat.

[Ash]

Tys tomu zase dal, taková konstruktivní diskuze a ty ses v tom takhle vyrochnil.

Michal samozřejmě ví, o čem mluví, už ani nepamatuji, že bych od něj někdy četl nějaký nepravdivý příspěvek, a ty do toho vlítneš se svými pokusy s bashem a busyboxem jak rotvajler do kurníku. Víc studuj než se začneš do někoho navážet. "Naběhl mi busybox! Důkaz proveden.". Takový kraviny tu musim číst. Bože.

[Lol Phirae]

Vy dva s Kubečkem mi připomínáte politiky, co "diskutují" o tom, že stát je na mizině, a místo řešení se celé týdny dohadují o tom, jestli se má říkat, že je státní kasa rozkradená, vytunelovaná, zpronevěřená nebo radši jen že je prázdná. Takové kraviny tu musím číst. Bože.

[pavlix]

Vy dva s Kubečkem mi připomínáte politiky, co "diskutují" o tom, že stát je na mizině, a místo řešení se celé týdny dohadují o tom, jestli se má říkat, že je státní kasa rozkradená, vytunelovaná, zpronevěřená nebo radši jen že je prázdná.

A ty mi připomínáš malé děcko, které se rozčiluje, že si taťkové politikové radši nepovídají s tebou o tom, proč je červená karkulka zrovna červená :).

Jinak to, co tu psal Michal Kubeček mně osobně strašně pomohlo, protože jsem doteď o tomto nevěděl. A že zajímavých a pro mě nových informarmací se na Abclinuxu zase tolik nedozvídám.

Že se vlákno objevilo u dotazu v poradně, se kterým blízce souvisí, to mi nijak nevadí. Ale že někdo zaplácává poradnu Abclinuxu urážením linuxových profíků jako je Michal, to už je docela trapný.

(Michala tímto zvu minimálně na pivo či nějaký ekvivalent.)

[ojel]

Vzpamatujte se už! Nikdo přece netvrdil, že se přepíše stejné místo na disku. To je přece známo, že se otevřený soubor ve skutečnosti nesmaže, dokud ho proces nepustí. A s tím cp je to podobné. Pokud je soubor otevřený, tak cp -f použije jiné inody, viz příklad nahoře. Ale má to udělat potichu bez odmítání.

[Lol Phirae]

Ale má to udělat potichu bez odmítání.

Hurááá. Aspoň někdo pochopil, o čem se tady bavíme.

[Michal Kubeček]

Přečtěte si, prosím, co jsem napsal a hlavně na co jsem odpovídal.

[pavlix]

Ale má to udělat potichu bez odmítání.

On to nejen udělat má, on to dokonce dělá, tedy pokud máš opravdu na mysli na mysli cp -f.

[stativ]

Podle dotazu zrovna cp -f nefunguje. Tipuji to ne SELinux.

[pavlix]

A... tak v tom máš pravdu.

[pht]

Tipuji to ne SELinux.

Nebo chmod -w adresář_s_programem

[ojel]

Aha, tak to mám asi vlčí mlhu.

Takže ještě jednou:

1.pustím binárku "kuku.bin", ta běží

2. stat kuku.bin vypíše:

  File: `kuku.bin'
  Size: 175817    	Blocks: 352        IO Block: 4096   regular file
Device: fd03h/64771d	Inode: 3810870     Links: 1

2. cp -f bla.bin kuku.bin

3. stat kuku.bin vypíše:

  File: `kuku.bin'
  Size: 39060     	Blocks: 80         IO Block: 4096   regular file
Device: fd03h/64771d	Inode: 3810857     Links: 1

4. Binárka furt běží a je funkční...

Nikdo netvrdil, že mají být obsazeny stejné inody. Tvrdil, že -f nezkopíruje jednu binárku na druhou. Tak jsem zvědav na nějaké argumenty podložené praxí.

[Michal Kubeček]

Tak si všimněte komu a na co odpovídáte. Tvrdil jsem, že ten soubor nebyl přepsán a na tom trvám. Koneckonců to potvrzuje i ten váš výpis.

[pht]

3. cp -f bla.bin kuku.bin

výstup žádný, binárka se přepíše, ale program běží klidně dál, funguje a nikam nepadá, jak tady bylo tvrzeno (možná je to tím, že binárka není moc velká a je celá v paměti)

To je tím, že -f provede smazání a vytvoření, pokud se nepovede přepsání.

[ojel]

No ano!

Ale půvovdní dotaz tvrdil, že mu to F14 odmítla přepsat v tom smyslu, že cp -f vůbec neproběhlo, ať už je kopírovací mechanismus jakýkoliv. Domnívám se, že autor příspěvku neřešil, zda se přepíšou stejné inody, nebo zda se soubor smaže a vytvoří nový se stejným názvem na jiném místě. Možná by se k tomu měl vyjádřit on, jak to myslel.

[pavlix]

Ale půvovdní dotaz

Netrefil jsi sled příspěvků ve vlákně. Přeskoč na začátek a čti znova, jinak to nemá smysl :). Jak to myslel autor dotazu v poradně je v tomto případě irelevantní.

[Ash]

výstup žádný, binárka se přepíše, ale program běží klidně dál, funguje a nikam nepadá, jak tady bylo tvrzeno (možná je to tím, že binárka není moc velká a je celá v paměti)

Nepadá to nikoliv proto, že by "binárka byla malá a byla celá v paměti", ale proto, že nebyla fyzicky přepsána, byla jen smazána a bla.bin obsadil jiný inode. Kdybyste ji opravdu přepsal, tak by to tak vesele dál neběželo. cp -f nepřepisuje existující soubor, pouze zařídí to, že to tak neznalému uživateli (nechci ho konkrétně jmenovat :) připadá.

[ojel]

Ano, to s tím "celá v paměti" beru zpět. Ale dohadovat se o tom, jestli slovo "přepsání" znamená přepsání konkrétních inodů nebo alokování jiných a přepsání hlavičky, se už nebudu, protože je to skutečně na úrovni červené a modré čepičky. Na druhou stranu by mne zajímalo, proč by vlastně měl program havarovat? Programoval jsem docela dost pod DOSem, kde žádné blokování zápisu do konkrétnách alokačních jednotek neexistovalo a nikdy nic nepadalo. Soubory .com vůbec ne, ty jsou celé v jednom paměťovém segmentu a exáče taky ne, pokud nepoužívaly tzv. overlaye na disku. Pochybuju, že by dnes existovalo mnoho binárek, které by se nevešly celé do paměti. A pokud se nevejdou do paměti, tak se spíše asi swapnou, ne? Žádné diskové overlaye. Tak mi někdo FUNDOVANÝ vysvětlete, proč by měly padat!

[Michal Kubeček]

jestli slovo "přepsání" znamená přepsání konkrétních inodů nebo alokování jiných a přepsání hlavičky … je to skutečně na úrovni červené a modré čepičky.

Ve chvíli, kdy tam budete mít hardlink, je ten rozdíl dost podstatný. Při přepsání bude druhá adresářová položka linkovaná na přepsaný soubor (tj. nový obsah), zatmco při nahrazení pod druhou položkou dál uvidíte původní soubor.

Pochybuju, že by dnes existovalo mnoho binárek, které by se nevešly celé do paměti.

To, jestli se vejdou do paměti, a tedy se mohou potenciálně obejít bez souboru ve filesystému, ještě automaticky neznamená, že se můžete spolehnout, že se do toho souboru už nebude sahat. Navíc i v případě, že by tomu tak u aktuální verze linuxového jádra opravdu bylo, pokud toto chování není zdokumentováno nebo ještě lépe podloženo specifikací předepisující, že to tak musí být, nelze se na něj spoléhat. Osobně nevím o tom, že by nějaká specifikace garantovala možnost beztrestného přepsání spuštěného spustitelného souboru (ale nemohu stoprocentně vyloučit, že existuje).

[Lol Phirae]

Kubeček, to psali podle nich?

[pavlix]

Lol Phirae?

Jinak, kdybysis potřeboval vybít vztek i na mě, mám v profilu i na webovkách celé jméno :).

[pht]

Programoval jsem docela dost pod DOSem, kde žádné blokování zápisu do konkrétnách alokačních jednotek neexistovalo a nikdy nic nepadalo. Soubory .com vůbec ne, ty jsou celé v jednom paměťovém segmentu a exáče taky ne, pokud nepoužívaly tzv. overlaye na disku. Pochybuju, že by dnes existovalo mnoho binárek, které by se nevešly celé do paměti. A pokud se nevejdou do paměti, tak se spíše asi swapnou, ne? Žádné diskové overlaye. Tak mi někdo FUNDOVANÝ vysvětlete, proč by měly padat!

V DOSu se program nejprv načetl do paměti a pak se spustil. V moderních systémech se jen namapuje adresa v paměti na prostor na disku a program se spustí. Načtení do RAM zajistí mechanizmus diskové cache. Stejný mechanizmus se ale může rozhodnout, pokud je tlak na paměť, že nacachované stránky zahodí a pokud IP běžícího programu dojde do té stránky, tak se zase dotáhne z disku. Tou dobou tam ale už můžou být nějaké bláboly, pokud ty data na disku přepíšete a program začne vykonávat úplně jiné instrukce a nejspíš spadne na SEGV.

Ukládání stránek s kódem do swapu nemá smysl, protože jsou stejně na disku v tom spustitelném souboru.

[ojel]

Díky za vysvětlení. Sice mi to připadá trochu podivné - resp. v tom nejsem schopný vidět žádnou výhodu, ale zkoumat zavaděč ELFu se mi už nechce, jsem na to moc starý, abych na to plýtval časem. Měl jsem za to, že daleko více paměti zabírají datové struktury, než vlastní výkonný kód a také jsem měl za to, že struktura běžícího programy v paměti neodpovídá 1:1 kopii sektorů na disku, takže to mapování paměti na disk nechápu, ale budiž. Ještě jednou děkuji.

[pht]

Měl jsem za to, že daleko více paměti zabírají datové struktury, než vlastní výkonný kód

Poměr kódu a dat závisí na spuštěném programu, každopádně to s tím úplně nesouvisí - pointa je, že nějaký kód ten program vykonává.

Pro ilustraci si můžete představit, že přepsání kódu v souboru na disku rovná se přepsání odswapovaných dat.

struktura běžícího programy v paměti neodpovídá 1:1 kopii sektorů na disku, takže to mapování paměti na disk nechápu

To si můžete jednoduše ověřit v /proc/PID/maps - dívejte se jak velké kusy jsou namapované s právem x (execute). Většinou tam najdete jeden blok pro exe soubor a po jednom pro knihovny. Kód přeložený do strojových instrukcí většinou stačí jen nahrát a spustit. Proto se tomu říká kód přeložený do strojových instrukcí.

[ojel]

podíval jsem se na mapování seamonkey

[ojel]

Proč jsou některé komentáře označeny jako řešení, když nejsou žádným řešením, nýbrž pustým bludem?

[pavlix]

Proč jsou některé komentáře označeny jako řešení, když nejsou žádným řešením

Tady ti musím dát za pravdu, zbytek věty radši nekomentuju.

[ojel]

Tak jsem to zkusil na F14, se zapnutým SELinuxem a cp -f mi běžící binárku normálně "přepsal" ("" pro puntičkáře). Tak by mne tedy zajímalo, co vlastně původní tazatel pozoroval???

[Michal Kubeček]

To je právě ten problém - bez bližších informací o tom, co konkrétně tazatel dělal a za jakých okolností (nejlépe doplněných o výstup strace) se to dá těžko nějak řešit, nanejvýš napsat "works for me".

[jekub]

Tak by mne tedy zajímalo, co vlastně původní tazatel pozoroval?

vzhledem k tomu, ze se v teto velmi plodne diskusi uz neobjevil, je to asi celkem jasne.