Názory k článku
Bizarní chyba v systemd

Víš co ňufíku? Nejdřív si zjisti jak to funguje a pak o tom mluv. Systémový unit file vyrobí jen člověk, co má oprávnění roota, nebo /etc/systems/sys­tém/
Ten se spouští pod uživatelem definovaným v Unit file.

Uživatelské unit soubory (pokud tím uživatelem není root) se pochopitelně pod rootem spustit nedají.
Ale kdybys nebyl naprostý dutohlav, došlo by ti, že na tebou popisovanou bezpečnostní chybu by stačilo prostě napsat do usera root, nemusel bys blbnout s čísly.

@j
Proc tu:
- lzes
- jsi sprosty?

I jedna z tehle veci by bohate stacila na to, abys pusobil jako nesnesitelny fracek. Ale tohle kombo...

Systemd nevidí do hlavy správci, aby mohl rozpoznat každou nesprávnou konfiguraci. Nejde jen o zpětnou kompatibilitu se staršími verzemi systemd, jde i o kompatibilitu s jinými aplikacemi, které používají unit soubory. Při rozpoznání pravděpodobně nesprávné konfigurace vypíše varování do logu.

Tady se ukazuje rozdíl mezi správci, kteří po napsání jednotky otestují, zda funguje, a zkontrolují logy, a správci, které nějaké varování nezajímá a řeší až případ, kdy jim služba vůbec nenastartuje (a nejspíš je pak na to stejně musí upozornit někdo jiný).

To není proto, že jméno začíná nulou.

Ano, při kontrole logů může být pozdě, proto má správce jednotku napsat správně a spustit ji teprve po kontrole. Když do ExecStartPre zadá rm -r /*, tak mu to smaže celý systém. To je také chyba systemd?Když zadá Usr=nobody, spustí se jednotka pod rootem. Taky chyba systemd?

Sorry, ale samotný systemd s tebou nesouhlasí:


systemd[1]: /etc/systemd/sys­tem/t.service:3: Invalid user/group name or numeric ID, ignoring: 0tomasxxx
systemd[1]: /etc/systemd/sys­tem/t.service:5: Unknown lvalue 'Usr' in section 'Service'


Evidentně to dělá rozdíl mezi neznámou lvalue a mezi vadnou hodnotou známé lvalue.

Ano, oba řádky se to rozhodne ignorovat. To je asi to jediné, co mají společného. Pokud se do User dá jméno, které systemd považuje za validní, tak už to položku User neignoruje a začne se to podle ní řídit.

Což mimochodem taky znamená, že pokud v budoucnu se systemd změní a jméno "0tomasxxx" to bude považoval za validní uživatelské jméno, tak ta unita selže na neznámého uživatele. Unita, která do té doby "zpětně kompatibilně" fungovala.

Nechápu, jak tohle může někdo obhajovat.

Vždyť popisuješ přesně to, co jsem napsal. Neznámá volba nebo neznámý formát volby znamená varování do logu a přeskočení dané volby. Obojí je logické kvůli kompatibilitě s jinými programy. Teprve pokud je volba známá a má známý formát, systemd se ji pokusí zpracovat. V případě uživatelského jména tedy vyhledá uživatele s daným jménem – a pokud neexistuje, je to jednoznačně chyba, proto také systemd danou jednotku nespustí.

Pokud se systemd v budoucnosti změní, může se změnit různými způsoby. Číslice na začátku může být chápána jako prefix – podobně, jako např. spuštění příkazu může mít prefix +. A nebo by číslice na začátku mohla být považována za validní uživatelské jméno, teprve pak platilo to, co jsi napsal – že by jednotka při startu selhala, pokud by ten uživatel neexistoval.

Pokud nechápeš, jak to někdo může obhajovat, měl bys nejprve napsat, co ti vlastně vadí. To, že je volba s neznámou syntaxí ignorována? Nebo obecně princip kompatibility formátu, kdy je ignorována neznámá volba nebo volba s neznámou syntaxí? Nebo ti to vadí jen u volby User a ta by se měla chovat jinak, než ostatní volby?

Já chápu, že to chování je na první pohled divné. Ale to zacházení s neznámými volbami a neznámými formáty voleb je logické, a je logické, že se systemd ke všem volbám chová stejně.

Pokud nechápeš, jak to někdo může obhajovat, měl bys nejprve napsat, co ti vlastně vadí.

Pokud napíšu lvalue= tak očekávám:

* Pokud lvalue nezná, tak mě na to upozorní. Ocenil bych možnost, kdyby to nebylo jen upozornění, ale kdyby to s neznámým atributem vůbec nejelo (prostě tato unita nebude provedena, dokud jsou v ní chyby nebo neznámé atributy).

* Pokud lvalue zná, tak očekávám, že se to pokusí zpracovat hodnotu a pokud toto zpracování selže, unita nebude provedena a systemd ohlásí chybu (tak jak se děje, pokud dám do User neexistujícího uživatele).

Prostě tak jak se chovají jiné programy. Pokud jinému programu dám lvalue=nesmysl, tak typicky ani nenastartuje.

Pokud jinému programu dám neznámou lvalue, tak většina z nich mě na to upozorní (systemd taky, v logu).

Co ovšem nechci je to, aby chování záleželo syntaxe hodnot. Tady, syntax error znamená, že se to bude celé ignorovat. Tohle je chyba o které se tady diskutuje.

Pokud se systemd v budoucnosti změní, může se změnit různými způsoby. Číslice na začátku může být chápána jako prefix – podobně, jako např. spuštění příkazu může mít prefix +. A nebo by číslice na začátku mohla být považována za validní uživatelské jméno, teprve pak platilo to, co jsi napsal – že by jednotka při startu selhala, pokud by ten uživatel neexistoval.

Aha, takže máme bezpečnostní problém (spouštění unit za roota, pokud správce nastavil attibut User, považuji za vážný bezpečnostní problém), ale budeme ho ignorovat, protože větší výhodu má budoucí změna syntaxe.

Takhle se systémový software opravdu nepíše.

Ale asi je to fakt o těch správcích, jak jsi psal. Já mám rád software, který svou práci bere vážně. Kdysi jsem psal o jednom příběhu s MySQL, který se taky rozhodl ignorovat to, že innodb (po změně konfigu) nenajelo, ignorovalo to create table ... engine=innodb a vytvořilo to typ mysiam, ignorovalo to begin tranaction a rollack (myisam nepodporuje). Však co na tom, že někdo přišel o data, sere pes...

Jestli tímto způsobem autoři software přemýšlí (a u Lennarta na to máme důkazů už dost), tak je celkem dobré ten software nepoužívat. U normálního softu mě to na nestandardní konfiguraci upozorní. Pokud hodnota neodpovídá typu konfigurační volby, tak to nenajede. Apod. Je soft, kde to jeho autoři berou vážně. A potom je ten zbytek.

Oba požadavky znamenají, že syntaxe jednotkového souboru je striktně vázána na jednu verzi systemd. Předpokládám, že jednotkový soubor má ambici být univerzálním formátem, který budou používat i jiné nástroje spravující služby. Dovedu si třeba představit, že v jednotkovém souboru bude i popis toho, na kolika a jakých strojích v clusteru se má jednotka spustit.

To, že program ignoruje neznámé hodnoty, je běžná situace – zejména v případech, kdy nepoužívá formát souboru určený jenom pro daný program.

To, že se ignorují neznámé formáty (ty píšeš „syntax error“) je nedílná součást té otevřené definice formátu, která umožňuje budoucí úpravy. Třeba v HTML prohlížeče ignorují jak neznámé tagy (což by odpovídalo těm neznámým volbám), tak neznámé atributy na známém tagu (což by odpovídalo tomu neznámému formátu). Jenom díky tomu se HTML může vůbec vyvíjet – kdyby to tak nebylo, HTML už dávno zemřelo ve verzi 1.0.

Mně se ten formát jednotkových souborů vůbec nelíbí, ale když už byl zvolen takhle, zachází se s ním logicky, konzistentně, a je možné, aby se programy používající ten formát rozvíjely. Ostatně i samotné systemd už několikrát využilo toho, že přidalo nový formát volby.

Pokud správce nastavil User na neplatnou hodnotu a pokusí se to spustit, je to jeho chyba, ne bezpečnostní chyba systemd. root má milion způsobů, jak omylem něco spustit jako root – a musí si to pohlídat, od toho je root.

Systemd na nestandardní konfiguraci upozorňuje. Ale změnit to na tvrdou chybu by znamenalo úplně rezignovat na kompatibilitu formátu jednotkových souborů. Může se ti to nelíbit, třeba bys dal přednost formátu souboru svázaného s konkrétní verzí systemd (což by byl krok i proti modulárnosti systemd). Ale autoři systemd se rozhodli pro kompatibilní formát, což má tenhle důsledek. To ale neznamená, že to autoři systemd neberou vážně.

Neregistrovaný, 14:15: Vynucené automatické aktualizace Windows se týkají domácích Windows, které žádného správce nemají.

Neregistrovaný 15:11: Čemu na tom nerozumíte? Windows, které mají správce, používají pro distribuci aktualizací WSUS.

Souhlas, WSUS jde používat i bez active directory a je to takový základ.

Pane J:

To co popisujete je důsledkem toho, že jste ve WSUS konzoli zaškrtl že chcete dostávat přes WSUS Windows 10 language packy.
Když jste je potřeboval, nevím proč si zde stěžujete.

A za druhé - tajemné kouzlo WSUSu je v tom, že si můžete aktualizace o které nemáte zájem odmítnout. Klienti pak nebudou hlásit že je potřebují.

Přeji pěkný den.

Všiml jste si, že čím slušněji Vás oslovuji, tím hruběji píšete?

To vaše "MOZNA NEKDY NECO " řeší on-demand aktualizace které nejsou needed. Např pro novější desítky .net framework 3.5. Ale máte pravdu, že se to zatím používá méně než by mohlo.

Needed u jazykového balíčku dává docela smysl, když chcete mít na WSUS jazykové balíčky (já tedy ne). A chcete tam mít téměř všechny větové jazyky, tak WSUS jasně hlásí, že má v databází něco co klient nemá nainstalované. Můžete je tedy bud odmítnout, nainstalovat, nebo ignorovat.

Nenapadá mě které aktualizace pro Windows 10 nejsou na WSUS, ale pro ostatní systémy občas vycházejí hotfixy které jsou dostupné na update catalogu. Z catalogu je můžete imporotvat do wsusu. Například SMB patch pro XP/2003 naposledy.

Petr M: To ale pořád počítáte jen s jednou jedinou aplikací. Zkuste si představit, že takhle přidáváte nový atribut pro nějaký tag v HTML.

Očividně o té chybě ví, když ji zaloguje jako warning.
Systemd očividně rozlišuje mezi chybou a varováním.

Máš nějaký konkrétní příklad? Tomu argumentu nerozumím. Proč by měl systemd akceptovat formát svého vlastní direktivy, kterému nerozumí (a jen to přejít logem), jenom proto, že jej může používat jiná aplikace? Ta si přece může použít jiný název direktivy.
To není direktiva systemd, je to direktiva jednotky (unit file). Jiná aplikace je třeba budoucí verze systemd. Váš přístup by znamenal, že s každou změnou formátu by se musel změnit i název volby. Já osobně považuju formát jednotkových souborů za to nejhorší na celém systemd, ale prostě zvolili takovýhle formát a to, že různé formáty hodnot voleb budou označovat různé chování, tak to respektuju.

Pokud se mi služba i jen pro otestování spustí pod rootem, může to nadělat pěknou paseku třeba na filesystému - vyrobí mi klíčové soubory pod rootem a budu pak pěkně dlouho dohledávat a měnit práva souborů, aby mi zase běžela pod neprivilegovaným userem.
Taky si má nejdřív správce zkontrolovat, co spouští. Když takhle spustí přímo MySQL nebo nějaký skript, může napáchat úplně stejné škody.

V případě jednotky ale správce tu službu nemusí hned spouštět, může nejprve na jednotku spustit systemd-analyze verify, která mu ta varování vypíše bez nutnosti jednotku spouštět.

To, že se přidal formát, neznamená nutně, že nová jednotka se starým systemd nefunguje správně. Když se k volbě Description přidá možnost prefixem @lang= zadat jazyk popisku jednotky, start služby to nijak neovlivní.

Vy to pořád popisujete, jako kdyby to byl formát jen pro systemd – jenže tak evidentně nebyl zamýšlen.

Mně se ten formát nelíbí, radši bych formát, kde se příznaky nebudou zapínat tím, že se použije nový formát zápisu hodnoty, radši bych formát, kde bude možné udělat podmínku na zpracovávající aplikaci nebo její verzi. Ale autoři systemd zvolili tenhle formát, a v rámci toho formátu je to chování logické a konzistentní.

Já osobně považuju formát jednotkových souborů za to nejhorší na celém systemd, ale prostě zvolili takovýhle formát a to, že různé formáty hodnot voleb budou označovat různé chování, tak to respektuju.

Já osobně považuji tento formát za velmi vhodný.

Prostě ini-like, [sekce] klíč=hodnota

Stejný formát napříč vším, logind.conf vypadá stejně jako .network nebo .mount. Tohle mi vyhovuje.

Co mi nevyhovuje je, že někdo obhajuje, že klíč=hodnota vlastně není klíč=hodnota, ale že to ještě navíc záleží na syntaxi té hodnoty a vlastně to může znamenat něco úplně jiného.

Váš přístup by znamenal, že s každou změnou formátu by se musel změnit i název volby.

Což by bylo správné řešení. Pokud by si někdo vymyslel seznam uživatelů, klidně může vzniknout UserList=. Nevidím na tom nic špatného, právě naopak, protože seznam uživatelů je evidentně něco jiného, než jeden uživatel.

Co mi nevyhovuje je, že někdo obhajuje, že klíč=hodnota vlastně není klíč=hodnota, ale že to ještě navíc záleží na syntaxi té hodnoty a vlastně to může znamenat něco úplně jiného.
To je přesně to, co mi na tom formátu nejvíc vadí. Jenže pokud by to mělo být jinak, s tím postupem [sekce] klíč=hodnota by to nejspíš nešlo. Stačí se podívat jenom na ExecStart, který se může opakovat a může obsahovat prefix @, + a -. Rozepsat do klíč=hodnota by šlo, ale jak by to vypadalo…

Stačí se podívat jenom na ExecStart, který se může opakovat a může obsahovat prefix @, + a -. Rozepsat do klíč=hodnota by šlo, ale jak by to vypadalo…

Vypadalo by to úplně normálně a hlavně by to nerozbilo zpětnou kompatibilitu. Prostě ExecStart je plná cesta k binárce a její parametry. Pokud si někdo později vymyslel @+-, stačilo zavést třeba ExecMod, do kterého by šlo zadat mod spouštění (třeba jako bitmapu, nebo pomocí symbolů @+-). Vůbec to není potřeba cpát do hodnoty parametru ExecStart a porušit tím předchozí kompatibilitu (@/bin/bash evidentně není validní cesta k souboru).

Jenže ExecStart se může opakovat a ty prefix se týkají každého příkazu zvlášť. Navíc ty modifikátory nemusely být zavedeny najednou, takže pak by pro ně nestačil jeden ExecMod, ale podle pravidla „při každé změně novou volbu“ by těch voleb muselo být několik. Takže ze současného

ExecStart=@+-/opt/backup/run-backup.sh backup-home
ExecStart=@+-/opt/backup/run-backup.sh backup-var
ExecStart=/opt/backup/upload-backup.sh

by se stalo

ExecStartArgv0=backup-home
ExecStartFullPrivileges=yes
ExecStartIgnoreError=yes
ExecStart=/opt/backup/run-backup.sh
ExecStartArgv0=backup-var
ExecStartFullPrivileges=yes
ExecStartIgnoreError=yes
ExecStart=/opt/backup/run-backup.sh
ExecStart=/opt/backup/upload-backup.sh

Ten první zápis je hrozný, ten druhý je ještě horší.

Ten první zápis je hrozný, ten druhý je ještě horší.

Tak to je otázka vkusu. Asi jako všechny flamy v historii o tom, která syntaxe je lepší, která horší, která je úsporná a která je readonly.

Mě osobně druhý zápis nijak nevadí. Pokud by se to naformátovalo pěkně, tj mezi každou skupinu ExecStart dala třeba mezera, tak osobně nemám problém s čitelností.

Ale to je věc vkusu.

Systemd neignoruje jen volby, které nezná, ale také volby, které mají neznámou syntaxi. Což umožňuje syntaxi volby rozšířit – třeba se později někdo rozhodne, že bude možné uvést seznam uživatelů oddělených čárkou, a použije se první, který v systému existuje. Jiná věc je, jestli je vhodný tenhle způsob konfigurace, kdy se různé nové volby zavádějí třeba tak, že se před hodnotu zadá nějaký prefix (plus, zavináč apod.).

Z hlediska syntaxe unit souboru zkrátka není rozdíl mezi tím, zda uvedu UserXXX=nobody nebo User=@"#!, v obou případech je to pro aktuální systemd neznámá volba (a v obou případech to něco může znamenat pro jinou aplikaci nebo pro budoucí verze systemd).

Proč pořád řešíte špatně zadanou volbu? Tady jde o případ, kdy správce zadal tu volbu zcela správně a s platnou hodnotou. Je tam prostě User=0day, což je normální platný uživatel.
Neznámá volba a neznámý formát hodnoty volby jsou pro systemd to samé. Obojí umožňuje kompatibilitu jednotek s jiným softwarem (např. budoucími verzemi systemd).

0day pro systemd není platný uživatel.

To vypadá že v zájmu kompatibility s něčím budoucím, co neexistuje ani není naplánováno, už nyní není kompatibilita s něčím co funguje.

Pokud neni uvedena, pouzije se defaultni hodnota a pokud ma chybny format, sluzba se nespusti s chybovym hlasenim!
Čímž zabijete jakoukoli kompatibilitu jednotkových souborů.

Podle vás je díra, že root může získat práva roota? Podle mne to žádná díra není, to že root má práva roota je přece úplně normální… A běžný uživatel nemá právo User změnit, vždy se to spouští pod jeho účtem.
User=root se tam ani dávat nemusí – služba se normálně spouští pod rootem, volba User je volitelná a umožňuje to změnit.

User=root se tam ani dávat nemusí – služba se normálně spouští pod rootem, volba User je volitelná a umožňuje to změnit.

Jo, a přesně takhle se dělá bezpečný software. Admin chce omezit práva pro spouštěnou binárku, ono to nejde, tak se to spustí jako root...

S takovou se klidně můžu dočkat toho, že se nepovede zinicializovat nspawn, tak to systemd spustí přímo na daném systému.

Rozkaz zněl jasně, musíme to spustit. Nebylo čas lámat si hlavu jak...

Tomáš Crhonek, 9:21: Když admin něco chce, musí to systému nějak říct. Asi mám větší fantazii, než je běžné, ale dovedu si představit milion způsobů, jak chyba v jednotkovém souboru, kterou není možné nijak detekovat, může způsobit nějakou škodu. Stačí třeba do příkazů, které se spouští, zadat chybný příkaz. Systemd nemá jak zjistit, že jste chtěl do pre příkazu napsat rm -r /tmp/app, ale místo toho jste tam napsal rm -r / tmp/app. Můžete mít jednotku, která se spouští pod rootem, ale vzdává se nějakých capability – opět, když to zadáte špatně, nikdo nezjistí, že jste to myslel jinak. Některé služby dělají postaru su na uživatele samy – opět, když na příslušný parametr zapomenete, služba poběží pod rootem.

Od toho systemd vypisuje ta varování, když se mu něco nezdá. Ale jak byste to chtěl udělat, aby jednotkové soubory byly vždy bezpečné? Volba User bude povinná, ExecStartPre a ExecStartPost budou povinné, ve volbách Exec bude zakázáno rm a dalších asi milion podmínek, které budou bránit tomu, aby správce mohl napsat něco nebezpečného? Nebo kde má být ta hranice?

Asi mám větší fantazii, než je běžné, ale dovedu si představit milion způsobů, jak chyba v jednotkovém souboru, kterou není možné nijak detekovat, může způsobit nějakou škodu. Stačí třeba do příkazů, které se spouští, zadat chybný příkaz.

Stále vidím zásadní rozdíl mezi tím, kdy software ignoruje známou lvalue jen na základě hodnoty a mezi tím, kdy admin, možná omylem, napíše ExecStart=/bin/rm -r --no-preserve-root /.

Nebo kde má být ta hranice?

Tohle je fakt absurdní.

Ta hranice má být tam, co může systemd kontrolovat a co může systemd ovlivnit, co je v jeho gesci. Tzn je naprosto absurdní argumentovat tím, že do ExecStart si můžu dát příkaz pro odpálení atomové bomby a argumentovat tím, zda by to měl systemd kontrolovat.

Takže znova po sté: systemd by měl kontrolovat lvalue. Pokud lvalue zná (je to pro něj známá konfigurační volba), měl by se pokusit zpracovat její hodnotu. Pokud zpracovat hodnotu nelze, neměl by tuto lvalue ignorovat, ale měl by ohlásit chybu a celou unitu prohlásit za neplatnou. (+ jako bonus možnost nastavit striktní režim, že to nebude ignorovat ani neznamé lvalue, to bych si s chutí nastavil, ostatním to necpu)

Tímto způsobem běžný software hlídá chyby admina. Ano, pochopitelně existuje další milion možností, jak admin může systému uškodit. Ale to přece neznamená, že úplně rezignujeme na jakoukoliv kontrolu. (Kdysi BASIC na Didaktiku taky psal jen syntax error - a člověče najdi si to, dnešní kompilery poměrně přesně programátora navedou na výskyt chyby v kódu - podle tebe je to naprosto zbytečné, protože tu chybu lze ignorovat.)

SB, 11:20: Já vám rozumím. Systém té chybě může zabránit – ale jedině tehdy, pokud o ní předem ví.

Jednotkové soubory fungují tak, že mají nějaké volby, a těm volbám se zadávají hodnoty, které mají nějakou syntaxi. Pokud je ta syntaxe neznámá, systemd vypíše hlášku do logu a ignoruje jí. Možná řešení toho problému jsou dvě. Buď je možné určit, že volba User může mít libovolnou hodnotu – pak to skončí na chybu, že uživatel neexistuje, a budete spokojen. Jenže se tím zazdí možnost do budoucnosti přidat další volby pro položku User (třeba prefixem @ nebo + určit, že se má s názvem zacházet jinak – jako to má spousta jiných voleb v jednotkových souborech). Čímž se nesystémově zabrání jedné z milionu možností, jak může správce udělat chybu při konfiguraci jednotek. Druhá možnost je speciálně v případě User změnit varování na chybu. Proč ale zrovna v případě volby User, proč ne taky u jiných voleb?

Nejde o to, že ta služba má za každou cenu běžet. Jde o to, že s jednotkovými soubory se pracuje tak, že se neznámé volby ignorují. Pokud bude nějaké aplikace pracovat s jednotkovými soubory a nebude znát volbu Description, opravdu to má být důvod, proč s tím souborem odmítne pracovat? Když já si do jednotkových souborů přidám informace o tom, na kterých nodech clusteru se má služba spouštět, opravdu to má zabránit spuštění takových služeb, dokud neprotlačím do systemd a všech ostatních aplikací patch, že má tyhle volby ignorovat?

Já beru, že tu spousta lidí chce, aby se systemd choval jinak. Ale nikdo tu neměl tu odvahu, aby napsal, jak přesně se to zacházení s jednotkovými soubory má změnit. Třeba že se všechna varování mají změnit na chyby. Nebo že se se s volbu User má zacházet jinak. Ono je jednoduché, když vidím nějakou „chybu“, rychle vymyslet nějakou záplatu, která tu jednu domnělou díru zalepí – bez ohledu na cokoli jiného. Ale promýšlet to v celku, jak to ovlivňuje celkovou koncepci, zda tím náhodou nerozbiju něco jiného, jestli je to opravdu dostatečný důvod, proč porušit koncepci a zavést nesystémovou výjimku – to už je něco jiného.

Ehm. Zmanipulovaný balíček který vytvoří unit file s User=0neco je jeden z nejkrkolomnějších způsobů jak získat roota přes zmanipulovaný balíček. Proboha, pokud počítáš se scénářem zmanipulovaného balíčku, tak má jeho tvůrce bambilión a jeden způsob získání roota. A pokud trváš na krkolomných řešeních, úplně stejně jako přes ten unit file to jde získat přes sysv init skript.

V tomhle případě můžeš tedy za díru považovat samotnou instalaci balíčků pod rootem. Protože podvržený balík si může dělat v systému prakticky co chce a může zneužít init systém tisíci a jedním způsobem. Pokud chci přes podvržený balíček spouštět něco pod rootem pomocí systemd, proč bych se měla obtěžovat blbým User=123foobar, když můžu napsat rovnou User=root nebo User=0?

A hlavně, proč blbnout s jakýmkoliv initem, když můžu svým podvrženým balíčkem prostě do /bin vrazit shell s nastaveným SUID bitem?

NULL, 10:07: Právě jste překonal hranici mezi „opravdu o tom toho tak málo ví“ a „aha, ona je to jen čistá groteska“. Vám tedy prostě vadí, že root má na Linuxu neomezená práva, a viníte z toho systemd.

Mohl byste nastínit vaši představu, jak by se asi do Linuxu instaloval systémový software (nebo třeba jádro) tak, aby se nemohl spustit žádný kód pod rootem? Mohl byste nastínit, jak byste provozoval služby tak, aby žádná z nich nevyžadovala práva roota? Nebo co se vám nelíbí na systémových jednotkách, které může nainstalovat jenom root a které mohou běžet pod rootem? Chtěl byste, aby při každém startu takové jednotky musel root zadat heslo? Nebo jak byste si to představoval?

Balíčkovací systémy zpravidla nepřepisují uživatelsky změněné konfigurační soubory. Takže unita která má nastavená nižší práva šmahem nezíská vyšší.
Abys ovšem tohle mohl využít přes balíčkovač jako bezpečnostní chybu, musel bys přepsat celou service, změnit unit file… Prostě, přes podvržený balíček lze získat práva roota podstatně snazsším způsobem než takhle (navíc je to podstatně nápadnější)
Navíc se to NIJAK netýká této chyby a přes sysv init / upstart / bsd init jde udělat to samé.

Počkej, takže podle tebe nemá mít init systém vůbec možnost spouštět věci pod rootem? OK…

Jo mimochodem, ty máš nastavená pravidla pro SELinux tak, aby tvůj package manager nemohl zapisovat do /bin/? (SELinux žel neznám tolik abych věděla jestli to jde, ale počítám že ano)
Jak potom instaluješ software a provádíš updaty?

Já vím že toho jde nastavit hodně, ale apt/dnf asi nikdo mít nastavené tak, aby nemohly sahat do /bin nebude mít nikdo. To už může ten package manager vyhodit úplně a kopírovat nové binárky ručně.

Když se ta jedna distribuce rozhodne opatchovat systemd a místo volby User bude používat Usr, je to ten samý problém. Tohle je prostě obecně neřešitelný problém, systemd se to ve skutečnosti vůbec nijak netýká, a kde kdo se do toho strefuje jenom proto, že to někdo spojil se systemd a strefovat se do systemd je módní.

Patr M., NULL: Ve skutečnosti se tím akorát vyvalila obrovská neznalost, která panuje mezi „správci“. Několik lidí tady bez uzardění píše o tom, že je pro ně ohromné překvapení, že když spustí instalaci nějakého balíku pod rootem, provede se pod rootem cokoli, co je součástí instalace toho balíčku. To jste doteď nevěděli, že každý instalační balíček má možnost připojit skripty, které se provedou před instalací balíčku a po jeho instalaci (a jiné před a po odinstalaci)? Debianí balíčky mají preinst a postinst skripty, RPM mají skriptlety, ebuildy mají sekce pkg_preinst a pkg_postinst (a celý ebuild je shellový skript), ostatní balíčkovací systémy mají nepochybně něco podobného. Systemd s tím vůbec nijak nesouvisí, když budete mít špatně udělaný balíček, spustí vám pod rootem při instalaci balíčku nečekaný kód klidně na Devuanu. Mimochodem, ty pre- a post-instalační skripty se používají mimo jiné právě proto, aby zkontrolovaly podmínky nutné pro používání toho balíčku, takže například právě založí toho uživatele, kterého daná služba používá.

Nechtěli byste si místo kritizování něčeho, čemu nerozumíte, radši nastudovat základy správy balíčků?

Ano, pokud by byla direktiva User povinná, bylo by to řešení. A hned by spousta lidí na Rootu začala řvát, že je to hrozné, že jejich SysVinit skripty nic takového nemají a normálně se spouští pod rootem.

A hned by spousta lidí na Rootu začala řvát, že je to hrozné, že jejich SysVinit skripty nic takového nemají a normálně se spouští pod rootem.

Nedělej ze sebe idiota. Ano, rc skripty jako takové možná běží pod rootem, ale když si tam admin dá:


# su -c 'id' 0kokotlennart
uid=1006(0koko­tlennart) gid=1006(0koko­tlennart) groups=1006(0ko­kotlennart)


tak to prostě jede.

(A ne, fakt už podruhé nemusíš psát absurdnost s tím, co se stane když tam admin zapomene dát to username. User=0kokotlen­nart v systemd danou věc spustí jako root, su 0kokotlennart pod existujícím uživatelem nebo vůbec, pokud user neexistuje.)


Jul 04 10:58:03 raid systemd[1]: /etc/systemd/sys­tem/t.service:3: Invalid user/group name or numeric ID, ignoring: 0kokotlennart
Jul 04 10:58:03 raid systemd[1]: Starting t.service...
Jul 04 10:58:03 raid id[8748]: uid=0(root) gid=0(root) groups=0(root)
Jul 04 10:58:03 raid systemd[1]: Started t.service.


Ale klidně si to tom napiš další referát, jak je to vlastně správně...

JE to KRETÉN. Root něco nainstaluje, to si vytvoří uživatele 0LPjedebil a pod tímto uživatelem se to spustí. Opravdu je potřeba kontrolovat každou kravinu, jak se chová ve skutečnosti, když je nastavená jinak? Co všechno si má admin zkontrolovat? Protože pokud nad každou takovou kravinou mávneme rukou, nakonec budeme muset kontrolovat úplně všechno, včetně zdrojáků, protože "root má být uvědomělý". No jestli ono nebude nakonec jednodušší, napsat si vlastní systém, ne?
Ono je potřeba si uvědomit rozdíly mezi chybama. Chyba může být za určitých okolností ignorována a děje se tak zcela běžně, ale nemůžu něco pustit jako root, když mi konfigurák tvrdí něco jinýho, třeba nesmyslnýho. Když se přihlásím do systému jako neexistující uživatel 0hacker s nečekaně chybným (neexistujícím) heslem, má mně systém přihlásit jako roota, nebo mě má poslat do Lenarta?

Opravdu je potřeba kontrolovat každou kravinu, jak se chová ve skutečnosti, když je nastavená jinak?

Zkontrolovat si konfig po každé změně je nanejvýš vhodné u každého software. Většina software na to má nějaký nástroj.

Druhá otázka je, jak by se měl software při chybě chovat. Podle některých lidí i zde v diskusi je možné řádek s divnou hodnotou ignorovat. K čemu to potom vede jsem demonstroval na příkladu MySQL. Tam ignorování ze strany software vedlo až k poškození dat.

Tzn. chyba by nikdy neměla vést k horšímu stavu. Pokud admin zadá (v tomto případě) User a toto není možné z libovolného důvodu provést, není možné mít jako fallback roota. Kdyby byl fallback nobody, tak se o tom ani nebavíme. Default má být bezpečný. Osobně preferuji variantu, že software s vadným konfigurákem vůbec nenaběhne. V případě systemd by se dalá unita mohla prostě ignorovat jako celek.

Ano, teoretizovat se dá nad vším možným, ale to je dobrý do nabídky, nebo do školy. V případě jakékoliv realizace už teorie nikoho moc nezajímá. On se potom těžko obhajuje teoreticky správný stav, když je praktickým výsledkem něco rozbitýho, nefunkčního, nebezpečnýho...

A jak prosimte pri kontrole konfiguraku zjistis, ze ta naprosto jasna konfigurace, ktera naprosto jasne rika, ze si prejes pustit neco pod existujicim uzivatelem 0kokotlennart ... to ve skutecnosti spusti pod rootem?

Kontrola konfiguráku:


# systemd-analyze verify t.service
/etc/systemd/sys­tem/./t.servi­ce:3: Invalid user/group name or numeric ID, ignoring: 0kokotlennart


To, že to ten řádek ignoruje a spustí pod rootem je samozřejmě špatně, ale o tom už tady diskutujeme druhý den, to nemusím opakovat.

Další je je samozřejmně to, že toho uživatele můžu v systému mít (useradd to nekontroluje, případně si to napíšu přímo do passwd nebo do ldapu) a přes to pod ním nelze spustit službu přes systemd.

Chápu, že podle tebe by v případě chybné syntaxe User neměl systemd vypisovat varování, ale rovnou chybu a spouštění jednotky přerušit. Má to být jedna jediná volba, která má mít takovéhle speciální zacházení? Nebo kterých dalších voleb se to má týkat? Nebo budeme čekat, až zase někdo vymyslí nějaký nesmysl a zadá to na GitHubu jako issue, a takhle budeme budovat ad-hoc seznam voleb, které mají speciální zacházení?

chybné syntaxe

Tohle je nádherná ukázka absurdity, do které se tato diskuse stočila.

Pro mě o žádnou syntaxe nejde.

User= pro mě znamená nastavení konfigurační hodnoty na string, který je za tím znakem =.

To, že pro někoho přišlo jako geniální nápad odhadovat, zda ta věc za tím '=' je číslo nebo řetězec a podle toho určit, zda se jedná o UID nebo o UserName, je podle mě zásadní chyba. Chyba návrhu. Tohle má být oddělené.

Jenže někdo si řekl, že hodnota nebude hodnota, ale že se bude aktivně parsrovat (viz šaškárna s ExecStart, když první argument už není plná cesta k binárce, ale někomu přišlo hrozně fajn tam narvat další znaky (které v absolutní cestě nemají co dělat), takže se bude odhadovat co je cesta, co není cesta a co je řídící znak, místo toho, aby určilo jiným parametrem (viz navrhovaný ExecMod), jak přesně se bude s daným příkazem zacházet.

Mimochodem, krásná ukázka toho, co se stane, když software odhaduje datový typ a použije nesprávný:


var_dump(md5('24061­0708'));
var_dump(md5('QNKCD­ZO'));
var_dump(md5('24061­0708') == md5('QNKCDZO'));



string(32) "0e4620974319­06509019562988736854"
string(32) "0e8304004519­93494058024219903391"
bool(true)


Funkce MD5 vrací 128b číslo, toto číslo je převedeno na nějaký string, dva stringy jsou porovnávané, porovnávátko odhadne, že jde o float, float je moc velký, nevejde se, tak to ořeže a výsledkem porovnání je true... (A fakt nepiště, co všechno je tam špatně a jak to udělat lépe, na to to téma už se popsalo stovky stránek jinde.)

S automatickým odhadem (většinou samozřejmě špatným) datového typu je vůbec super sranda. Tuhle jsem něco importovat do Calcu. Další nepoužitelný software.

Tomáš Crhonek, 11:23: Za prvé, to, že se pro uživatelské jméno a UID používá jedna položka, je naprosto běžné. Podobně jako se třeba používá jedna položka pro zadání hostname nebo IP adresy. Za druhé, ten problém spočívá v něčem úplně jiném. Problém je v tom, že systemd má omezenou množinu hodnot, které považuje za validní vstup pro User, a když tam někdo zadá hodnotu mimo tuto množinu, vyhodnotí systemd celou volbu User jako nevalidní a ignoruje jí.

Na tom, že tenhle formát konfiguračních souborů, kdy se před hodnoty přidávají různé znaky a tím se mění jejich význam, se shodneme. Ale ten formát je takhle zvolený, a za mnohem horší bych považoval dělat nějakou nesystémovou výjimku pro jednu volbu. Pokud už by se na tom mělo něco změnit, ať se změní typ volby User, ať je to libovolný text (třeba jako Description), a validita ať se posuzuje až za běhu podle toho, zda na daném systém daný uživatel skutečně existuje. Sice se tím rozbije statická analýza, protože User=@#!$ projde syntaktickou validací bez problémů, ale správci, kteří píšou do jednotkových souborů náhodné údaje a doufají, že to bude dělat to, co chtějí, budou spokojeni.

Petr M, 12:34: Zneužitelnost jsem popsal. Pokud něco odladíte na systému, který číslici na prvním místě username nepodporuje, máte v username v tom jednotkovém souboru username, které začíná písmenem. Když to přenesete na jiný systém, systemd to bude stále vyhodnocovat jako platnou syntaxi, a pak bude záležet jenom na tom, zda daný účet na systému existuje nebo neexistuje. Zkuste příště vymyslet nějaký příklad, kde dojde k nějakému problému. A mimochodem, pokud jednotkový soubor nevzniká v rámci instalace nějakého balíčku, který i vytvoří příslušného uživatele, ale ten jednotkový soubor jenom přenášíte mezi systémy, a ani si nezkontrolujete, zda zadaný arbitrární uživatel na cílovém systému existuje, je to vaše chyba. A představte si, že úplně stejně to funguje třeba s cestama ke spustitelným souborů. Vytvoříte jednotkový soubor na jednom systému, zadáte tam cestu k existujícímu programu, pak jednotkový soubor přenesete na jiný systém, kde ta cesta neexistuje – a představte si to, systemd má takovou drzost, že tu jednotku nespustí.

V tom, že XML formát by byl pro tyhle konfigurační soubory daleko lepší, se shodneme. Předpokládám, že spousta ostatních diskutujících bude mít za to, že XML je to poslední, co systemd ještě chybí, aby to byl ten úplně nejhorší software v celém univerzu.

Karel 11:25: Ne, seznam položek jednotkových souborů, které mají speciální zacházení, je stále prázdný.

Systemd umí spustit jednotku pod uživatelem, jehož jméno začíná číslicí, akorát takového uživatele musíte zadat pomocí UID. Jediná skutečná chyba je to, že syntaxe volby User není zdokumentovaná. To, že některé hodnoty nejde do jednotkového souboru zadat jednoduše, je normální – třeba cestu k souboru, která obsahuje mezeru, tam taky nevložíte tak, že jednoduše cestu i s mezerou zkopírujete a vložíte.

upravit svůj program tak, aby akceptoval pravidlo Linuxu, že username může začínat číslicí
A pak přijde někdo, kdo si do /etc/passwd dá jako username kus programu v Perlu, a bude se to opakovat celé znova.

Pokud není User uveden, budiž spustit to pod userem který to startuje.
Přesně takhle se to ale chová…

jarda mira, 9:39: Nikoli, asi jste nečetl pozorně. Já tvrdím, že je v pořádku, že systemd chybné hodnoty ignoruje a napíše varování do logu – znamená to, že je kompatibilní s jinými aplikacemi, formát jednotkových souborů se může rozvíjet. Zároveň platí, že se systemd chová úplně stejně, jako všechny ostatní správce služeb – tedy když není řečen jinak, službu spustí pod rootem.

Je tady spousta lidí, kteří obhajují, že volba User je něčím speciální a měla by se zpracovávat speciálním způsobem. Proč zrovna User, proč ne taky Exec*, WorkingDirectory, *Paths a spousty dalších? V jednotkových souborech je tolik příležitostí, jak něco pokazit…

To že pokud je volitelná hodnota v nastavení (která má nějaký definovaný default fallback) nastavena na nesmysl / neznámou syntax, ignoruje se a použije se default je naprosto normální praxe ve spoustě konfiguráků. Tohle považuji za správné jednání a výhodnou věc pro zpětnou kompatibilitu.

Co mi přijde jako chyba je, že ač málo používaný, username s číslem na začátku prostě legální username je. V SystemD by se mělo opravit tohle jakožto špatně zvolený možný formát username, ne to chování jako takové.