Názory k článku Doas: náhrada za děravé sudo z dílen projektu OpenBSD

V Linuxu se taky dá použít machinectl:


machinectl shell --uid=root


Není to přímý ekvivalent sudo, protože se tím vytvoří celé nové sezení jako kdyby se root přihlásil přímo. Záleží na případech použití, v některých se to výborně hodí. Nevýhoda je, že to předpokládá funkční polkit. Výhoda je, že místo sudoers se to dá nastavit přes polkit.

No ja neviem ... V článku je jasne napísané "Proti sudo má ale doas dvě výhody: je menší a má jednodušší konfigurační soubor. Obojí dohromady znamená menší složitost a méně bezpečnostních problémů." Platí to aj pre machinectl? Neštudoval som zdrojáky, ale mám pocit, že machinectl + polkit bude zložitosťou minimálne na úrovni sudo, možno aj o rád horšie.

Koncepčně je machinectl řádově složitější, než sudo. Jenže jak právě i tento příklad dokazuje, představa "jednodušší kód = méně bezpečnostních problémů" není automaticky pravda. Konkrétně tady byl problém v tom, že sudo implementuje parser (z podstaty věci zpracovává potenciálně nebezpečná vstupní data), v C (z podstaty věci snadno zranitelný), v rámci privilegovaného procesu - setuid root (což je konceptuálně špatně). Je to sice jednoduché, ale zároveň už z principu jasně nebezpečné.

machinectl je neprivilegovaná utilita, ověřování práv provádí nezávislý proces (polkit) a případný start sezení pod root další nezávislý proces (systemd). Je to složité, ale pokud se důvěřuje dbusovým rozhraním mezi nimi, pak zpracování nebezpečných dat a bezpečnostně kritické operace jsou vzájemně striktně oddělené, takže i kdyby dejme tomu v programu machinectl byla tatáž chyba, jako v sudo, takto zneužít by ji nešlo.

To samozřejmě neznamená, že machinectl a celé prostředí dbus/polkit/systemd nemůže mít zase jiné problémy. Jenže ve skutečnosti bezpečnost nakonec vždycky záleží na jádru a LSM, což je ještě mnohem komplexnější, než tohle všechno dohromady. Takže argument o jednoduchosti je z velké části lichý.

Takže to je spíš náhrada " su -" než sudo?

Je to víc, než su -, protože to nastartuje celé nové sezení včetně příslušné slice atd, což su pokud vím nedělá.

Jistě, ale z hlediska toho, k čemu to slouží, to spíš odpovídá su než sudo.

To je pravda.

doas aktivne pouzivam a na vsech strojich jsem na nej presel. Funguje bez problemu. Vtipne je pokud jste pod rootem a ze zvyku zadane doas cmd. Ackoliv jste root, neni pro roota zaznam v doas.conf, takze akce je zamitnuta.

Vtipne je pokud jste pod rootem a ze zvyku zadane doas cmd. Ackoliv jste root, neni pro roota zaznam v doas.conf, takze akce je zamitnuta.
Hlavně je to názorná ukázka, proč je používání sudo nebo doas na počítačích s jedním uživatelem totální nesmysl.

Není to nesmysl obecně, jen je nesmysl používat ho "the Ubuntu way", tj. podle hesla "když to vyžaduje práva roota, napište před příkaz sudo". Já ho třeba používám k tomu, abych mohl konkrétní příkazy (včetně parametrů), které potřebují práva roota, spouštět pod svým normálním uživatelem, pro ty příkazy pak obvykle mám i nějaký alias nebo wrapper script. Na tohle se to naopak hodí velmi dobře.

Jenom tam není žádný rozdíl oproti su -c.

Jakým způsobem pomocí " su -c" zařídím, abych jako konkrétní uživatel mohl spustit konkrétní příkaz s konkrétními parametry pod (E)UID 0, aniž bych musel zadat heslo roota?

28. 1. 2021, 12:32 editováno autorem komentáře

A jak je to se zadáváním hesla v dialogu, jako to třeba má gparted, používá se tam interně sudo? Případně dalo by se to taky nahradit za doas?

gparted nepouziva sudo ale poolkit (tak jako vetsina GUI programu (s vyjimkou tech kterem autor nenapsal parradkovej wrapper pro pkexec a polkit pravidlo)), drive se pro gui pouzivalo gksudo(z balicku gksu) ktere aby uz je obsolete, takze v distrech neni pritomno, tedy kdyz se GUI SW zepta na heslo, z 99% to je polkit dotaz...

Hlavně chybí wildcardy, ovšem pozor u sudo s wildcardy, viz https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-4-wildcards/

Pravděpodobně to je potenciálně nebezpečné, ale já jsem si poslední dobou oblíbil "su bez hesla pro všechny ve skupině wheel" - není k tomu potřeba nic doinstalovávat, pouze v /etc/pam.d/su odkomentovat
auth sufficient pam_wheel.so trust group=wheel
Jsem si vědom toho, že to nejspíš není ten správný přístup, jen mi to přišlo fér zmínit, když už se tady psalo o tolika možnostech (sudo, doas, systemctl magie nademnou...)

Moc děkuji za pěkný a velmi výstižný článek!

Jenom bych upřesnil, že i su se dá používat bez hesla, stejně jako sudo. Z hlediska hesel umí sudo navíc oproti su dvě věci^*). Za prvé místo hesla cílového uživatele vyžadovat heslo současného uživatele. Což je asi ochrana pro ty nezodpovědné uživatele, kteří nechávají odemčený počítač, když od něj odchází. Za druhé to, že si umí nějakou dobu pamatovat, že heslo bylo zadáno a nevyžadovat ho znovu – to pro případ, kdy je dotyčný ještě línější, a nejen, že nezamyká počítač, ale doufá, že během třeba patnácti minut mu tam nikdo nic neprovede.

*) su to neumělo dříve. Je možné, že už to mezi tím do su někdo také implementoval – nevím, nezkoumal jsem to, protože obojí považuju za nesmysl.

Zadání hesla není jen ochrana pro nezodpovědné uživatele. Ostatně, ten pojem nemám rád. Pokud nějaký jev pozorujeme u velké části uživatelů, je potřeba to přijmout jako fakt. Účelem je stavět i bariéru tomu, aby v některém scriptu, nebo třeba při lovení z historie, nevlétl do vykonání privilegovaný příkaz. To je trochu narušeno zapamatováním si sese, ale stále to jako částečná bariéra proti chybám slouží.

Sudo umí ještě jednu věc: omezit co se smí spouštět. Tady vidím velký koncepční problém sudo. Opět, omezení příkazů je šikovné jako ochrana před chybou. Koncepční problém vidím v tom, že si to spousta lidí zaměňuje za bezpečnostní opatření (ve smyslu ochrany proti obecným rizikům). Pochopitelně, rizikům se tím nepředejde, víceméně se musí předpokládat, že každý povolený program, script, má v sobě funkcionalitu, která může být zneužita a každý, komu povolím sudo (na roota) že musí mít plnou důvěru k provádění všech operací (nejen těch povolených).

Sudo považuji tedy za prasárnu ve smyslu, že povýšilo špatné návyky na standard. Nicméně bych neignoroval účelnost takového nástroje pro operace, pro které bylo určeno původně.

Mám dotaz ohledně "správnosti" používání "sudo" (či "doas"...).
Na systému mám sice administrátorský účet, pod kterým se dělají "nebezpečné" věci, ale fakticky se na něj hlásím jen vyjímečně; tímto účtem není "root" a když je potřeba něco "extra" (instalace aplikace...), používám "sudo". Prakticky, pokud jako běžný uživatel nutně musím udělat nějaký zásah do systému, volám "su - spravce" a pak "sudo destroy-it-all".
Přišlo mi to vždy celkem přirozené, ale teď se z diskuse zdá, že je to jedna bezpečnostní hrozba za druhou a jen si koleduji o !totální smajznutí desktopu s likvidací dat až k páté off-lineové kopii" (s trochou nadsázky).
A ještě dodatek: "normální" uživatel na "sudo" samozřejmě nedosáhne.

28. 1. 2021, 10:33 editováno autorem komentáře

Pointa je v tom, že používat sudo není o nic bezpečnější, než se přihlásit (nebo pomocí su přehlásit) přímo na roota. Pokud by v sudo nebyla série chyb (v poslední době vyplavávají), pak by sudo nebylo ani o nic nebezpečnější. Jenže díky své komplikovanosti je to magnet na chyby, které uživatel (správce) nevidí: navenek se sudo tváří jako skvělý nástroj, který může k bezpečnosti pouze přispět.

Ale v mém "modu operandi" nepotřebuji znát heslo uživatele "root", staží heslo toho správcovského účtu. Ovšem i tak jsem trošku chráněný před tím "provést blbost" - musím to heslo zadat do "sudo".
Sice je tu možnost, že "spravce" spustí pomocí "sudo" něco nebezpečného, aniž by se ověřoval, ale stejně se ověřuje svým heslem, takže mi to jako nějaké snížení bezpečnosti nepřipadá.
Podle mne je to jen taková "pojistka proti ukvapenosti", ve stylu "opravdu chceš dělat něco takhle nebezpečnýho? [a/N]".

Zadání hesla ve skutečnosti není vůbec žádná ochrana. Naopak to bezpečnost snižuje – uživatel se v tu chvíli soustředí na zadání hesla a přestane věnovat pozornost samotnému příkazu. S těmi skripty a historií jste si to vyvrátil sám s tím zapamatováním hesla.

Sudo umí ještě jednu věc: omezit co se smí spouštět.
Právě že neumí. Jenom vytváří tu iluzi, že to umí. sudo spustí nějaký proces s právy roota – a nad tím, co ten proces dělá, už nemá žádnou kontrolu.

Nicméně bych neignoroval účelnost takového nástroje pro operace, pro které bylo určeno původně.
Ale vždyť to, co sudo „umí“ navíc oproti su je právě to omezení toho, co je možné spouštět – přitom ve skutečnosti ale tohle není schopné zaručit. Takže ve skutečnosti je sudo použitelné přesně pro to samé, jako su, jenom vyvolává mylný dojem, že umí něco víc. A to je to, proč mám se sudo problém – evidentně je spousta lidí, kteří těm slibům věří.

Jestliže je "su" a "sudo" tak nebezpečné, jak by tedy měly být akové věci nastavené, například na běžném "desktopu", kde uživatel v podstatě nevyleze ze svého omezeného profilu a pouze občas potřebuje něco, co se dožaduje vyšších oprávnění (instalace programu, vynucený update, nastavení síťovky "pro všechny uživatele"...)?

Já to dělám už spoustu let pořád stejně, když přišlo do módy sudo, neměl jsem důvod něco na tom měnit. Pracuji jako běžný uživatel, a když potřebuji počítač spravovat, napíšu su -. Dostanu se do červeného rootovského promptu, a tam udělám, co potřebuji. Typicky mám vedle ještě terminál s obyčejným uživatelem, kde řeším ty věci, které nevyžadují roota. Nemíchá se mi historie. Na první pohled vidím, zda zrovna pracuji jako běžný uživatel nebo jako root, a to rozhodnutí dělám ještě před tím, než se začnu zabývat daným příkazem. Nepíšu automaticky před každý příkaz sudo.

sudo vytýkám jedinou věc – že je dnes vnímáno jako podstatně bezpečnější varianta su, když ve skutečnosti jsou na tom s bezpečností stejně (když má zrovna sudo zalepené všechny známé bezpečnostní díry). Povolit někomu su na roota, to si každý rozmyslí. Ale sudo rozdává na potkání.

> Zadání hesla ve skutečnosti není vůbec žádná ochrana. Naopak to bezpečnost snižuje – uživatel se v tu chvíli soustředí na zadání hesla a přestane věnovat pozornost samotnému příkazu.

Předpokládejme hypotetickou alternativu asadmin, která cokoliv co dostane prostě spustí jako root. Předpokládejme, pro účely diskuse, že se nějaké skupině crackerů podařilo infikovat Firefox nějakým malwarem.

Napadený firefox pustí asadmin cat /dev/random > /dev/sd0. Prů---švih jako vrata. Ve variantě sudo-se-zeptá-na-heslo je v takovou hypotetickou chvíli potřeba napadnout jak firefox, tak sudo. Není napadnout dva programy zároveň těžší, než napadnout jeden?

> Právě že neumí. Jenom vytváří tu iluzi, že to umí.

[Zdroj?]

Žádná hypotetická varianta neříká nic o reálné bezpečnosti. Já si můžu vymyslet jinou hypotetickou variantu, že nějaká akce webové stránky vyvolá kontrolu oprávnění v jádru, která však bude obsahovat chybu způsobující smazání disku. Když bude uživatel pracovat pod rootem, vyhodnotí se to hned na začátku a další kontrola oprávnění se provádět nebude, takže nedojde ani k té chybě a mazání disku. Znamená to, že v tomto jednom hypotetickém případě bude bezpečnější s prohlížečem pracovat pod rootem? Ano, znamená. Znamená to, že je obecně bezpečnější pracovat s prohlížečem pod rootem místo pod běžným uživatelem? V žádném případě.

[Zdroj?]
Je potřeba trošku tušit, jak fungují oprávnění v unixových systémech. sudo (když to jde dobře) zkontroluje, zda podle konfigurace může spustit daný příkaz (což je něco jiného, než zda správce chtěl povolit spouštění daného příkazu). Pokud ano, přepne efektivní oprávnění na roota a spustí požadovaný proces. Tím role sudo končí. Výsledkem tedy je, že požadovaný proces běží s oprávněními roota. Pokud v systému nejsou další ochrany omezující roota, ten proces může dělat v systému naprosto cokoli. Pokud v tom procesu bude chyba lokálního spuštění kódu, spustí kód pod rootem. Pokud bude proces spouštět jiný proces, spustí ho pod rootem. Cokoli bude ten proces provádět, dělá pod rootem. sudo s tím nic neudělá.

Kdybyste nechtěl při použití sudo předat úplná rootovská práva, musel byste si například ověřit, že cílová aplikace, tak jak ji spustíte, neumožní spustit žádný jiný kód. Ponechme teď stranou variantu chyby lokálního spuštění kódu. I tak byste si musel ověřit, že aplikace neumožňuje spustit žádný jiný proces. Že tam není žádná feature jako třeba ! ve vimu. Děláte to pokaždé, když něco zpřístupňujete přes sudo? Ne, jenom odevzdáte práva roota.

Myslíte si, že ty aplikace, které spouštíte přes sudo, se nějak extra brání záludnému uživatelskému vstupu? Představte si, že píšete program jako iptables, systemctl apod. – něco, co bude spouštět výhradně root. Budete nějak extra řešit, aby tam uživatel nemohl škodit zákeřným vstupem? Třeba když předává cestu k souboru, aby nemohl zadat /tmp/../home/u­ser? Proč byste to řešil, váš program přece spouští root, který může vše – takže přístup k nějakému souboru nebude získávat takhle krkolomně, vždyť si ten soubor jako root může kdykoli přečíst.

No a vy pak takovýhle program někomu zpřístupníte přes sudo pomocí program -d /tmp/*. Co by se asi tak zlého mohlo stát, vždyť jste umožnil pod rootem to spouštět pouze nad adresářem /tmp, že…

Jen dotaz "trochu bokem": neznamená "sudo" spíš "switch user and do" než "superuser do"?
Měl jsem za to, že se dá switchnout i na někoho jiného, než roota. (Alespoň u nás ve firmě, když žádám o dočasné povolení "sudo", musím napsat, na kterého uživatele se budu přepínat. Jasně, že to je snad vždycky "root", ale proto se, já začátečník, ptám.)

Význam té zkratky se různě dodatečně měnil. Původně to bylo „superuser do“, pak se řeklo, že to je „substitute user do“ a možná ještě něco dalšího. Většinou se uvádí to původní, protože se to obvykle používá pro přepnutí na roota. Pravda ale je, že se dá přepnout i na jiného uživatele.

: Výchozím uživatelem při použití doas je root, pokud chceme něco jiného (a máme
: to povolené), musíme použít parametr -u. Můžeme pak příkaz spustit pod jiným
: uživatelem:
: # doas -u www vim index.html

I sudo umí už dávno -u i -g. Zajímavé je spíš to, jestli doas nastavuje (nebo lze
nakonfigurovat) aspoň něco jako SHELL=/bin/false, protože jinak se dá při editaci
skočit do shellu a dělat cokoliv privilegovaně, že. Na editaci souborů je sudo
lepší pustit jako sudoedit a pak se editace realizuje na pracovní kopii a až po
skončení práce editoru se updatuje původní soubor. Proti sudo má asi doas
zásadní užitečnost v možnosti 'deny'. Ať už sudo nebo doas nebo cokoliv,
povolovány by měly být jen zcela konkrétní akce, aby byly řádně logovány. Třeba
'sudo -i' (resp. 'sudo sh') je prasárna, i když to je velmi pohodlné.

V OpenBSD je možné použít také volbu persist, která dovoluje již jednou autentizovaného uživatele nějakou dobu neobtěžovat zadáváním hesla (jako to umí sudo). Bohužel tato volba v Linuxu či FreeBSD zatím nefunguje.

Očividně existuje více implementací; na Alpine Linuxu se používá implementace z https://github.com/Duncaen/OpenDoas, která persist umí, pokud se povolí při kompilaci.

./configure --with-persist
make
make install

Nicméně k tomu autor přidává varování: This feature is new and potentially dangerous, in the original doas, a kernel API is used to set and clear timeouts. This API is openbsd specific and no similar API is available on other operating systems.

As a workaround, the persist feature is implemented using timestamp files similar to sudo.

Osobne nepovazuji stastne prebirat jednodussi reseni z jine a minoritnejsi platformy do Linuxu automaticky s tim, ze "PROTO BUDE BEZPECNEJSI".

Nebude (PROTO), to spise naopak.

Podstatne vice utoku, analyz a regresnich testu se delalo na linux a sudo (a stejne to nestacilo), je mnohem pouzivanejsi, a to, ze ma vice znamych problemu, je dusledek toho sirsiho pouzivani, a to, ze ma rozsahlejsi akod a vice funkci take (uzivani = feature for req = opravy = bobtnani kodu).

Naopak doas na linuxu muze trpet problemy, ktere na OpenBSD ani nejsou, tim padem sance, ze je nekdo na linuxu detekuje, se proti OpenBSD jeste radove snizuje.

Port doas na linux je pak svym zpusobem sazka do loterie, protoze tim se stane (na linuxu) jeste minoritnejsim a mene pouzivanym (a tim i testovanym, atakovanym, opravovanym).

Typicky v minulosti treba https://nvd.nist.gov/vuln/detail/CVE-2019-15901

Ve finale, pokud podstatna cast linux uzivatel prejde, se muze hypoteticky stat, ze na rozdil od pomerne uzavreneho a striktne rizeneho vyvoje v ramci OpenBSD bude port v "demokratictejsim" linuxu na prani uzivatel vylepsovan proti vuli puvodniho autora, forkne se od puvodniho kodu doas, a bude mit vlastni nove chyby a featury, a za par let tu mame zase sudo, jen jinak pojmenovane.

Mezitim nam nedejboze RH s Lenartem nadeli funkcionalitu sudo via nejake systemd like tooly (smajlik neudelam, abych to neprivolal)

openbsd tym neni zodpovedny za portaci doas na jine platformy, takze tento odkaz je mimo.

sudo je doporučované i pro logování privilegovaných akcí, na OS kde není třeba audit subsystém, např. OpenBSD!, tak je to jediná možnost jak "systémově" logovat takové příkazy.

Upřímně řečeno, význam SUDO mi dlouhodobě uniká.

Na desktopu mám určeného správce systému, který zná heslo root-a a tím pádem sudo nepotřebuje. Ostatní potenciální uživatelé prostě mají smůlu, požádají administrátora (jedná se o jednotky osob a jednotky případů), vlastně ani nemají potřebu toto řešit jinak, než že požádají svého admina.

A na serverech jsme sudo dříve masivně používali a připadali si cool. Jenže pak jsem zjistil, že stejně většina uživatelů-správců jako první příkaz po příhlášení použili (ekvivalent) sudo su - a zbytek odmakali přímo jako root. Takže uživatelské účty pro správce neměly význam. Sudo tedy zůstalo jen tam, kde někdo měl potřebu pouštět něco, co nešlo udělat úpravou práv (pokud nemohl být puštěn na plného root-a) a ostatní správci mohli přímo na root-a. A přístup jsme řídili pomocí SSH klíčů.

Použití sudo obvykle u jednoho příkazu nekončí, takže je nakonec lepší otevřít si rootovský terminál rovnou.

Takže jako mnoho ostatních, názor, že sudo a podobné zvyšují bezpečnost je dle mého názoru nesmysl...

Ten bug popisovaný v odkazovaném článku je už docela starý.

Máme tady docela čerstvý kousek: CVE-2021-3156.

Ano, proto jsou v článku odkazované tři bugy, včetně toho posledního. Také jsme o něm měli samostatnou zprávičku a právě na základě diskuse pod ní pak vznikl článek o Doas.

No nevím, bez ohledu na jednoduchost nebo složitost řešení a princip se i dočasná eskalace práv dá vždycky zneužít.
Ono nic nezabrání uživateli, aby si stáhnul /etc na SD kartu, doma pod rootem na svým stroji poupravil a když zvládne mount, napíše něco jako

mount /dev/mmcblk0p1 /etc/

A nemusí řešit, jestli je za tím sudo, su, doas, indiánský tanec při úplňku, nebo se rovnou přihlásí jako root.

Utilita sudo (superuser do) je tu s námi přes čtyřicet let a řeší klasický unixový problém: jak umožnit uživateli provést akci, ke které potřebuje práva superuživatele root. Na rozdíl od starší utility su nevyžaduje heslo roota, ale uživatel si vystačí se svou vlastní autorizací.

je tedy nevím, ale na všech isntalacích openSuse to mám jinak:
sudo s heslem - jednorázové provedení superuživatelské operace
su s heslem - trvalé přepnutí na superkuživatele

To se nevylučuje s tím, co je v článku napsáno. Rozdíl je v tom, že zatímco pro su musíte znát heslo roota, pro sudo vám stačí vaše vlastní heslo. Správce vám umožní udělat nějakou privilegovanou akci, aniž by vám musel prozradit heslo na celého roota.

Pro su není potřeba znát heslo roota. Může být nakonfigurované i tak, aby (pro vybrané uživatele nebo skupiny) heslo nevyžadovalo (stejně jako sudo).

A jde to su nastavit i s uzivatelskym heslem?

Myslím, že ne. Ovšem neměl by být problém to doprogramovat – pokud by to někdo považoval za dobrý nápad.

To je kvůli těmto dvěma řádkům v defaultním /etc/sudoers:

## In the default (unconfigured) configuration, sudo asks for the root password.
## This allows use of an ordinary user account for administration of a freshly
## installed system. When configuring sudo, delete the two
## following lines:
Defaults targetpw   # ask for the password of the target user i.e. root
ALL   ALL=(ALL) ALL   # WARNING! Only use this together with 'Defaults targetpw'!

Pokud chcete sudo používat "normálním" způsobem, je potřeba je smazat nebo zakomentovat.