Vlákno názorů k článku
Bizarní chyba v systemd od Ľubomír Mlích - To je zajímavé, kolik lidí kope do LP....

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.