Bezpečnostní chyba v sudo (CVE-2021-3156) (diskuse)

[jv0]

po aktualizaci: 'sudo apt-get update' terminated by signal SIGILL (Illegal instruction)

[Petr Tomášek]

sudo je stejně sračka, security by obscurity, stejný nesmysl jako zakazovat přihlášení přes ssh na roota.

[Jendа]

Jak bys jinak řešil, když chceš nějakému uživateli povolit spouštět jeden konkrétní skript pod rootem?

[Gilhad]

Ja to napriklad resil tak, ze uzivatel zapsal do adresare SHARED soubor RUN_THE_SCRIPT a cron testoval existenci tohoto souboru a pokud uspel, spustil pod rootem ROOT_SCRIPT, ktery ten soubor smazal a pak si prosel nejakou databazi, zvalidoval si polozky v ni a na zaklade toho podniknul nejake akce ( typu if (value == "spust zalohovani") then spusteni_zalohovani(); )

Stejne tak by pod rootem mohl bezet nejaky promitivni "server" sedici na nejake roure a tam cekat na prikazy, ktere by opet "neprimo interpretoval", nikoli spoustel

Samozrejme je pak jeste problem s tim spoustenym skriptem, ktery sam musi byt "neprustrelny" - u me slo o skripty/akce patrici rootovi, kam uzivatel nemel pravo psat.

[cezz]

To je v podstate sudo s extra krokmi.

[Gilhad]

Tak je a neni :)

Daji se tim delat nejake veci snaz, nejake naopak hur ci vubec a pouziva to jinou filosofii (a, coz je tady podstatne, jine programy, takze zrovna tato chyba nehrozi).

Ja to potreboval pro zpristupneni nekterych akci uzivateli, ktery nebyl z principu duveryhodny. Takze (v podstate) jedine, co smel bylo vytvorit (prazdny) soubor, jehoz obsah se ignoroval a jmeno bylo pevne dano, a zbytek, kde uz byla nejaka prava zapotrebi, se delal pod jinymi uzivateli, kteri zase meli svoje vlastni omezeni. Ten neduveryhodny nemel ani pravo cist, co se spousti jako reakce na tu zadost, natoz to nejak zajimave ovlivnovat. A vysledky se dozvedel jinym kanalem jindy, v podobe pro nej vhodnejsi (na webove strance ikonky odpovidajici vysledku, vcetne historie)

[cezz]

Ja som to komentoval v kontexte toho ze to nahradi sudo. V principe to nie je len ten vytvoreny subor co ti nahradza sudo, ale aj cron ktory spusta tvoj program s potrebnymi opravneniami, filesystem, vzdialeny pristup k tomu suboru..

Znie to ako jednoduchsie riesenie (a mozno v tvojom pripade realne aj je jednoduchsie) ale je tam vela veci ktore predpokladas, ze uz su. Napriklad ako taky pouzivatel vytvori subor? Ako zabezpecis aby tym suborom nezaplnil cely filesystem? Ako zabezpecis, ze ten subor nevytvori nieco/niekto iny (iny pouzivatel) a spusti tak nieco co nemalo bezat? Co ak ten subor bude drzat otvoreny pre zapis a nebude sa dat vymazat, nezastavi to celu sluzbu aj pre ostatnych pouzivatelov?

Je mi jasne ze vela z tych veci mozno mas vyriesenych v ramci nejakeho ineho systemu. (napriklad pouzivatelia zrejme uz predtym mali pristup k tomu tam nejake subory nahrat predpokladam?) Ale ked to vezmes komplexne je tam kopa veci ktore maju nejaku nejaky attack surface a cisto v kontexte nahradenia sudo je omnoho viac veci ktore mozu byt hacknute.

Tym nechcem povedat ze tvoje riesenie nema zmysel, len ze to mozno nie je dobry priklad v tomto kontexte.

[Gilhad]

Ja to bral

1. v tomto kontextu jako odpoved na otazku:

   Jak bys jinak řešil (=bez sudo), když chceš nějakému uživateli povolit spouštět jeden konkrétní skript pod rootem?

   Odpoved, je, ze jsou mozne i jine cesty, napriklad nechat omezovaneho uzivatele jen nastavit priznak a povereneho hlidat existenci priznaku a na zaklade toho jednat - coz povazuju za priklad dobry (existuje reseni jine, QED)

2. V mojem kontextu ten BFU
   • pouziva webove rozhrani, cili klikne na tlacitko, prazdny soubor uz dela server na zaklade toho tlacitka (tedy skutecne prazdny, obycejny a zavre ho)
   • ma prava uploadovat datove soubory, cili zahltit muze takto snaze
   • kdyz soubor vytvori nekdo jiny, tak se porad provede ta sama akce (a obcas se to i takto hodi, kdy treba admin ten soubor udela rucne a necha automatiku probehnout)
   • ta akce je globalni, takze je jedno, kdo ji spusti
   • je delana tak, ze jeji opakovane spusteni system nezahlti (zjisti, zda bezi nejake veci, pokud ne, tak je spusti, pokud ano, tak netreba nic spoustet)
     • Dane veci zajistuji rozdilove zalohy,
       • opakovane spousteni bez zmeny nicim nehrozi,
       • opakovane spousteni po minimalni zmene ten system zatizi, ale neodstavi,
       • bezne to neni treba spoustet po kazde zmene, ale obcas se to hodi udelat "prave ted",
       • v noci (v nevytizenou dobu) obdobna vec spousti automaticky taky
   • jestli se nepletu, tak soubor drzeny pro zapis stejne jde smazat (teda jako jmeno z adresare), puvodni proces do nej psat muze, ale jine ho nevidi, takze muzou zalozit stejnojmenny soubor taky (a tim to znovu spustit) a ten muze byt nasledne smazan
     • i kdyby smazat nesel, tak to povede jen k tomu, ze se dana sluzba bude cyklicky spoustet nejakou dobu po dokonceni predchozi a pokud neni rozdil, tak to zdetekuje a nic neudela - takze by jen zablokoval moznost setrit cas nespoustenim te sluzby po kazde zmene
   • cron a spol tam bezi davno kvuli jinym zalezitostem
   Cili v mojem pripade tam nepribyla zadna komponenta, ktera by tam uz nebyla predtim, a attack surface se nezvetsil, DOS se nekona, jen se v nejhorsim pripade o neco malo zvysi bezna zatez systemu, snizi prehlednost logu a budou se delat zalohy po kazde zmene, nejen dulezite, ale objem zaloh se prakticky nezmeni, jen je nepujde odlozit na noc. Pokud to nebude hacknuto (vytvorenim nesmazatelneho souboru), tak se budou delat veci jen kdyz jsou potreba explicitne, nikoli porad (vyhoda oproti stavu, kdy by to muselo stejne periodicky bezet pro pripad potreby rychle reakce).
   Pokud by to tam nebylo, tak by
   • bud musel ten uzivatel dostat prava spoustet prikazy s vyssim opravnenim - cimz by se mu to zkomplikovalo a bezpecnost se nezvysila
     • navic by musel cekat na dokonceni ulohy, nebo ji spoustet na pozadi
   • nebo se to muselo spoustet samo porad dokola automaticky - cimz by se neusetril cas, pokud zaloha neni potreba hned po zmene (v danem pripade velice casty pripad, desitky, stovky, ci tisice zmen a staci, kdyz se zazalohujou az v noci, na druhou stranu obcas je potreba tu zalohu udelat "hned" (vzhledem k dobe trvani zalohy je zpozdeni pri cekani na cron nepodstatne) )
   Ta "zaloha" samozrejme neni jen zaloha, ale i rada dalsich navazujicich akci a muze trvat od par sekund (pri "prazdne zaloze" ) az po radu hodin (v "extremnich pripadech", ktere taky nastaly mnohokrat), ale pro jednoduchost jsem to zjednodusil na pojem "zaloha", ktery priblizne sedi

[cezz]

Jak bys jinak řešil (=bez sudo), když chceš nějakému uživateli povolit spouštět jeden konkrétní skript pod rootem?

Odpoved, je, ze jsou mozne i jine cesty, napriklad nechat omezovaneho uzivatele jen nastavit priznak a povereneho hlidat existenci priznaku a na zaklade toho jednat

Jasne, myslim, ze chapem o co ti islo. V principe je tych sposobov ako sa zaobist bez sudo vela. Moze to by cron proces ktory sleduje nejaky priznak niekde, moze to byt sluzba ktora vie nieco spustit s potrebnymi pravami a ktora pocuva na nejakom porte/sockete. Moze to byt sluzba ktora caka na nejaku spravu cez sms/email/AMQP/.. Mozes tiez jednoducho nastavit SUID nejakej binarke ktora robi tu jednu konkretnu vec. Alebo cez setcap nastavis potrebne capabilities. Proste je vela sposobov ako nieco spustit s potrebnymi opravneniami.

Ale ked si vezmeme ze alternativa v sudo je jeden riadok:

user ALL=(root) NOPASSWD: /cesta/k/skriptu

Tak musis mat pomerne specificku potrebu aby si to nahradil niecim spolahlivejsim a bezpecnejsim.

Preto mi ten tvoj konkretny priklad neprisiel velmi vhodny lebo podla mna predpoklada pomerne vela systemov ktore niekde uz bezia a su nejako zabezpecene. Ked sa na tu povodnu otazku pozries znova, ani nieco take jednoduche ako SUID bit nemusi byt riesenie, lebo Jenda sa pyta na skript. Cize minimalne by si tam potreboval nejaku binarku ako wrapper. (to uz mozes pouzit rovno to sudo) Rozne beziace sluzby a ktovie co ine ani nehovorim.

Opat nevravim, ze tvoje riesenie je zle pre tvoj konkretny pripad, ale ked tu povodnu otazku zoberies ako je - bez nejakych extra predpokladov ako nějakému uživateli povolit spouštět jeden konkrétní skript pod rootem, tak mi nenapada jednoduchsie a spolahlivejsie riesenie ako sudo.

[Martin Mareš]

tak mi nenapada jednoduchsie a spolahlivejsie riesenie ako sudo.

Problém je, že to řešení je sice jednoduché, ale jak praxe ukazuje, není moc bezpečné. Historie bezpečnostních bugů v sudo je dlouhá a barvitá. Jasným zdrojem je překomplikovanost.

Takže pokud mi záleží na bezpečnosti, sudo nepadá v úvahu.

Jinak docela jednoduchá alternativa bez wrapperu (respektive jedním univerzálním pro všechny skripty) je suidgw, které zmiňuji o pár příspěvků vedle.

[cezz]

Absolutna vacsina problemov sudo su velmi specificke problemy s velmi specifickou konfiguraciou. CVE-2021-3156 je jedna z mala chyb ktore su pomerne jednoducho v standardnej konfiguracii zneuzitelne.

suidgw je pekny pocin, napisal si celkom fajn wrapper (paci sa mi to riesenie so symlinkami) ale neriesi to priamo to ze konkretny pouzivatel ma mat pravo spustat iba konkretny skript. (ak to spravne chapem) A tiez fakt, ze bezna distribucia nema suidgw v balickoch a teda by som bol zodpovedny za akekolvek aktualizacie. (v tom zmysle, ze by som si to musel zostavit a distribuovat) Co je v produkcnom prostredi trochu problem.

[Martin Mareš]

Jelikož suidgw respektuje filesystemová práva původního uživatele ke spouštěnému programu, neměl by být problém zařídit pomocí ACL, aby program mohli spustit pouze vyjmenovaní uživatelé.

Co se balíčků týče, souhlasím. Ale když se občas zmíníte, že něco takového existuje, ono se to třeba časem začne lidem líbit natolik, že to někdo zabalíčkuje a bude udržovat :)

Pardon, mně nikdy moc nešlo udržování komunity kolem svých programů. Většínu věcí píši prostě proto, že je sám k něčemu potřebuji, a pak je zveřejním pro případ, kdy by se hodily někomu dalšímu. Když se někdo ozve, že našel chybu, tak ji opravím. Ale o víc se málokdy mám čas starat.

[cezz]

Ono je to s tymito vecami tak trochu hlava 22. Na jednu stranu clovek preferuje koli bezpecnosti nieco co sa vyuziva masovo v komunite, aby bola vacsia sanca ze niekto pozrie obcas na kod a odhali nejaky bug, na druhej strane potom maju problem prerazit nove veci ktore mozu byt lepsie (lebo robia iba nejaku podmnozinu funkcionality) ale proste nemaju ten uvodny userbase.

[Petr Tomášek]

Popravě, tenhle use-case nepotřebuji. Podle mě 99% užití je pro blbé BFU, aby měli pocit, že dělají věci bezpečně, tak napíšou "sudo rm -rf /*" (pochopitelně bez hesla), místo, aby se přihlásili jako root a pak udělal "rm -rf /*". Prostě úplně naprd.

(A nejhorší je, když distribuce ani nejde nainstalovat bez vytvoření uživatelského účtu [ne-root], i když je to jenom na server, kde žádný uživatel není potřeba. Ale jasně, sudo pak funguje bez hesla. Kokotina...)

[cezz]

Tak pokial sa tam prihlasuje jeden pouzivatel, tak preco nie. Ale vo firme casto pozadujes nejaku formu auditu. (casto je dolezitejsie mat nejaku stopu v logoch v pripade ze niekto vykona akukolvek zmenu ako tej zmene vediet zabranit) Tam sa sudo celkom hodi.

[Xerces]

To jste ale napsal blbost, co? . Bohužel tohle si audit v některých firmách opravdu myslí. :-/

[cezz]

Nemusis mi vykat, nepotrpim si.

Nemyslim, ze som napisal blbost, niektore audity su proste take. Sarbanes–Oxley je napriklad v podstate len o tom, ze sa neda produkcna zmena spravit bez zaznamu a nie nutne o tom ze ako velmi si voci takej zmene zabezpeceny.

Neviem velmi posudit ako velmi ma taky audit zmysel, je mozne ze samotny audit je blbost, ale proste ho firma moze v nejakom stadiu potrebovat (napriklad ked chces poskytovat sluzby inym firmam ktore potrebuju byt SOx compliant) a potom nemas moc na vyber.

A mozem s tebou suhlasit ze passwordless sudo je prakticky to iste ako pouzivat priamo root ucet, ale v jednom pripade auditom prejdes, v druhom nie.

[Xerces]

Ano, s tímto uvažováním mám také zkušenost, ale asi chápeš (viz. začátek tvého třetího odstavce ) jak je ta věta ... (casto je dolezitejsie mat nejaku stopu v logoch v pripade ze niekto vykona akukolvek zmenu ako tej zmene vediet zabranit) ... nesmyslná z toho pohledu, že pokud je systém díky chybě kompromitován, tak můžeš veškeré auditní záznamy podvrhnout, nebo zničit.

[Jakub Lucký]

pokud je systém díky chybě kompromitován, tak můžeš veškeré auditní záznamy podvrhnout, nebo zničit.

To ale jen v případě, že je logován na lokálním stroji. Pokud se logy odesílají na centrální logovací server, tak to úplně nepůjde.

[j]

Ehm ... pokud system ovladas, tak samozrejme muzes zabranit odeslani cehokoli kamkoli, pripadne tam poslat to, co sam uznas za vhodny.

A muzu ti rict, ze sem se s podobnejma vopicarnama uz parkrat setkal - udelat to tak, aby administrator byl administratorem a zaroven vlastne nebyl, je casto zhola nemozny. Primarne si nabijes hubu na tom, ze sytemy a aplikace s necim takovym vubec nepocitaji.

Sekundarni rit nastane v okamziku, kdy ty logy chce prevazne nejakej managor nejak vyhodnocovat, kdy se zjisti, ze ma biliardy zaznamu vseho moznyho a nemoznyho, ze kterych se ale neda zjistit vlastne nic zajimavyho.

Dotretice pak nastane pruser s tim, ze se zjisti, ze ty logy samy o sobe obsahuji spoustu nebezpecnych a potazmo i nelegalnich dat, klidne i kompletni pristupovy udaje a spoustu osobnich udaju.

---

Dete s tim guuglem dopice!

[Jakub Lucký]

No jo, ale než systém člověk ovládne, tak už jsou logy odeslané. Rozumné auditové logování se odešle v rámci přihlašovací procedury, předtím, než má útočník možnost udělat něco smysluplného, aby zprávu zastavil a zůstal neodhalený. A pokud by byla mimořádná potřeba mít bezpečnost, pak se dá logovat přes jehličkovou tiskárnu s faxovým papírem. Jakmile data odejdou, tak už se s nimi nedá hnout elektronickou cestou vůbec.

Argumenty 2 a 3 přece vůbec nesouvisí s tím, o čem se bavíme. Obojí je příklad admina, který nedělá svojí práci dobře. Nehledě na to, že třeba auditd logy rozhodně žádné přístupové údaje neobsahují.

[cezz]

Samozrejme, ze ked nejakym sposobom hacknes system, je velka sanca ze mas zaroven k dispozicii pristup k tomu aby si po sebe zmazal stopy.

Zasielanie logov na externy system, nejaka forma prihlasovania cez prostrednika ktory drzi logy (Kerberos, SAML a podobne) moze utocnikove moznosti znacne obmedzit a minimalne uvodny login bude niekde v zaznamoch. Ale to je cele mimo pointu.

Moj komentar bol v kontexte sudo vs priamo root konto. Kedy spustenie niecoho cez sudo vies naviazat na konkretneho pouzivatela kdezto so zdielanym root kontom uz to moze byt problem. Ak je system koli chybe kompromitovany tak to je samozrejme problem, ale je to problem ktory sa da riesit. (v tomto konkretnom pripade upgradom sudo)

[Martin Mareš]

Moj komentar bol v kontexte sudo vs priamo root konto. Kedy spustenie niecoho cez sudo vies naviazat na konkretneho pouzivatela kdezto so zdielanym root kontom uz to moze byt problem.

To je další výhoda použití ssh: loguje fingerprint klíče, kterým se uživatel přihlásil.

[cezz]

Celkom dobry napad. Pravda, prestava fungovat v momente kedy je bezne ze je pripojenych vela pouzivatelov naraz. Mas pripojenych 10 ludi, niekto spusti rm -rf /.

(ale ako dodatocny log record sa mi to paci)

[plostenka]

Popravě, tenhle use-case nepotřebuji. Podle mě 99% užití je pro blbé BFU, aby měli pocit, že dělají věci bezpečně, tak napíšou "sudo rm -rf /*" (pochopitelně bez hesla), místo, aby se přihlásili jako root a pak udělal "rm -rf /*"

'sudo' chce heslo uzivatele ktery ho spousti, 'su root' chce heslo roota. Sudo urcite v defaultu heslo vyzaduje, a to i kdyz ma uzivatel prihlasovani do gui bez hesla. A bavime se o BFU, takze defaultni sudoers.

(A nejhorší je, když distribuce ani nejde nainstalovat bez vytvoření uživatelského účtu [ne-root], i když je to jenom na server, kde žádný uživatel není potřeba.

Serverove distrubuce samozrejme instalaci jenom s rootem umi (Devuan, Debian...). Ze tam cpes neco jineho je tvuj boj.

[Martin Mareš]

Trochu minimalistickým, ale docela funkčním řešením může být suidgw.

Řeší to spoustu oblíbených pastí suid programů (například zavření deskriptorů 0-2 nebo podstrčení environmentu), neřeší to pár okrajových věcí, které by nešikovně napsaným programům mohly vadit, jako třeba posílání signálů skrz tty vrstvu. Ale to pokud vím sudo také neumí.

Další možné řešení je použivat na to socket-activated služby v systemd. To je od uživatele odstíněné daleko lépe, právy k socketu se dá omezit, kdo je může spustit, ale zase se sám od sebe nepropojí stdin/out/err.

[Martin Mareš]

A ještě další možnost, která vypadá praštěně, ale nakonec je docela praktická, je řešit to po ssh na localhost a v rootových authorized_keys přiřadit konkrétním klíčům vynucené příkazy. Opět oproti setuid je to podstatně lepší bezpečnostní bariéra.

Obecně problém s konceptem setuid je v tom, že mezi privilegovaným a neprivilegovaným procesem existuje strašně složité rozhraní, jehož součástí jsou file deskriptory, environment, konfigurace tty, current directory, current root, umask a kdoví co všechno dalšího. A je hrozně těžké napsat ten privilegovaný program tak, aby ho atypické nastavení toho rozhraní (třeba zavřený file deskriptor 1) nevyvedlo z míry a nepřimělo udělat něco nebezpečného. To považuji za jedno z méně šťastných návrhových rozhodnutí v UNIXu. Naštěstí z mála takových :)

[Jendа]

A ještě další možnost, která vypadá praštěně, ale nakonec je docela praktická, je řešit to po ssh na localhost a v rootových authorized_keys přiřadit konkrétním klíčům vynucené příkazy.

Tohle mě nenapadlo a zní to jako rozumné řešení.

[cezz]

Obecně problém s konceptem setuid je v tom, že mezi privilegovaným a neprivilegovaným procesem existuje strašně složité rozhraní, jehož součástí jsou file deskriptory, environment, konfigurace tty, current directory, current root, umask a kdoví co všechno dalšího. A je hrozně těžké napsat ten privilegovaný program tak, aby ho atypické nastavení toho rozhraní (třeba zavřený file deskriptor 1) nevyvedlo z míry a nepřimělo udělat něco nebezpečného.

Oprav ma ak sa mylim, ale nemam pocit ze by riesenie cez lokalne ssh nejak zasadne riesilo niektory z tych vyssie spominanych problemov. (v porovnani s vynutenym konkretnym prikazom v sudoers)

[Jendа]

Řeší to doslova všechny uvedené problémy. Nebo on snad SSH server bere od klienta něco z uvedeného? Jediné, co to neřeší, je několik proměnných prostředí - locales a bohužel nějakou přes kterou šel exploitovat Shellshock. Ale i to se dá v sshd_config zakázat (ale asi to nikdo nedělá)-

[cezz]

Cez ssh vies nastavit uplne akekolvek premenne prostredia. (pokial to nezakazes server-side, co je zvycajne zakazane by default, ale by default ma aj sudo povolene len niektore premenne prostredia) Vies do znacnej miery ovplyvnit aj tty alokaciu. Tie ostatne polozky su tak nejak nespecificky zmienene, ze neviem co si mam pod tym predstavit.

So sudo tiez nemusim riesit port forwarding, alebo dokonca vytvorenie tun zariadenia. Vseobecne nemusim riesit pomerne zlozitu sluzbu, ktora mala uz niekolko viac, ci menej vaznych bezpecnostnych problemov. (tym nechcem povedat, ze ssh je zly protokol, ale je to relativne komplikovana sluzba v porovnani so sudo) Nemusim riesit ci kluce ktore server alebo pouzivatelia pouzivaju su dostatocne nahodne. Nemusim riesit zabezpecenie samotnych klucov alebo to ako ich dostanem na server. Nemusim riesit celu PAM konfiguraciu pre tychto lokalnych specialnych pouzivatelov.

Vseobecne cele to tlacenie sedenia cez tcp, openssl, demona, login shell a ktovie co este mi pride prehnane komplikovane na to aby si pouzivatela ktory uz je autentifikovany v systeme autentifikoval este raz a mozno osetril par edge cases ktore sa zrejme daju riesit omnoho lepsie. V niektorych pripadoch vies pouzit napriklad systemd-run, ktory spusti proces v presne definovanom prostredi a mas nad tym prostredim omnoho vacsiu kontrolu.

[Jendа]

So sudo tiez nemusim riesit port forwarding, alebo dokonca vytvorenie tun zariadenia.

wat

ssh root@127.0.0.1 /cesta/ke/skriptu.sh

Vseobecne nemusim riesit pomerne zlozitu sluzbu, ktora mala uz niekolko viac, ci menej vaznych bezpecnostnych problemov.

Osobně mám sshd stejně na všech počítačích, takže to tam je tak jako tak.

Nemusim riesit ci kluce ktore server alebo pouzivatelia pouzivaju su dostatocne nahodne.

No naštěstí i když tohle někdo kompromituje, tak může pořád spustit jenom ten jeden nastavený příkaz.

alebo to ako ich dostanem na server

wat

Já si klíče vždycky generuju lokálně. Jakože pustím ssh-keygen a párkrát zmáčknu entr a on to udělá.

Nemusim riesit celu PAM konfiguraciu pre tychto lokalnych specialnych pouzivatelov.

Vůbec nechápu, o jakých lokálních speciálních uživatelích se bavíme.

[cezz]

wat

ssh root@127.0.0.1 /cesta/ke/skriptu.sh

Ano to je ten spravny sposob ako by to mal pouzivatel pouzit. Ale tiez moze urobit nieco ako:

ssh root@127.0.0.1 -w tun1 /cesta/ke/skriptu.sh

a ak ma dostatocne opravnenie, zrazu sa ti objavi na stroji tun device. Ak nemas specialnu konfiguraciu pre lokalnych pouzivatelov a mozes sa s rovnakym klucom pripojit externe, tak lokalne u seba ma ten pouzivatel pravo vyrobit tun device, u teba na serveri tiez, lebo je root. A zrazu mas p2p link.

alebo urobi:

ssh root@127.0.0.1 -R 80:localhost:8080 /cesta/ke/skriptu.sh

A ma otvoreny privilegovany port 80 forwardovany lokalne na 8080 kde uz moze zavesit cokolvek.

Osobně mám sshd stejně na všech počítačích, takže to tam je tak jako tak.

Musi ale riesit pomerne nestandardnu konfiguraciu.

No naštěstí i když tohle někdo kompromituje, tak může pořád spustit jenom ten jeden nastavený příkaz.

Co moze mat pre daneho pouzivatela velmi nepriaznive dosledky. (samozrejme zalezi od toho co spustas, ale vseobecne fakt ze niekto v mene niekoho ineho nieco spustil povazujem za bezpecnostny problem)

wat

Já si klíče vždycky generuju lokálně. Jakože pustím ssh-keygen a párkrát zmáčknu entr a on to udělá.

Nasledne musis the privatny kluc konfigurovat niekde v sshd_config. Nedaj boze ze pouzivatel omylom ten privatny kluc niekde pastne, to ho zas musis rotovat v konfiguracii sshd..

Vůbec nechápu, o jakých lokálních speciálních uživatelích se bavíme.

Mozno mi unika nejaky detail toho nastavenia ssh, ale na modernom GNU/Linux systeme zvycajne kazde overenie ssh spojenia prechadza cez PAM, co je pomerne komplikovany system (v porovnani so sudoers) a spominam ho ako dalsiu medzivrstvu cez ktoru to lokalne ssh lezie a ktore moze mat bezpecnostny problem. A ak chces napriklad povolit normalnu session pri pripajani sa z vonku, ale pri pripojeni na localhost mas nastavene povolene prikazy pre konkretny kluc, zacina to byt dost komplikovany setup.

[Jendа]

Ano to je ten spravny sposob ako by to mal pouzivatel pouzit. Ale tiez moze urobit nieco ako:

ssh root@127.0.0.1 -w tun1 /cesta/ke/skriptu.sh

Aha, takhle jsi to myslel. No já k tomu klíči s omezeným commandem dávám no-port-forwarding, ale přiznám se, že nevím, jestli to vlastně zablokuje i rozhraní vytvořené přes -w - takže máš pravdu, že i tady číhají určité nástrahy a nejistoty.

Nasledne musis the privatny kluc konfigurovat niekde v sshd_config.

Ne, privátní klíč se používá defaultní uživatelův ~/.ssh/id_rsa. A veřejný se dá do /root/.ssh/authorized_keys a napíše se před něj command="/cesta/ke/skriptu",no-port-forwarding.

A ak chces napriklad povolit normalnu session pri pripajani sa z vonku, ale pri pripojeni na localhost mas nastavene povolene prikazy pre konkretny kluc, zacina to byt dost komplikovany setup.

Proč bych tohle dělal? Jenda se může přihlašovat na roota, tak má klíč v rootově authorized_keys bez command. Franta smí spouštět jenom jeden skript, tak má klíč s command.

[cezz]

Ne, privátní klíč se používá defaultní uživatelův ~/.ssh/id_rsa. A veřejný se dá do /root/.ssh/authorized_keys a napíše se před něj command="/cesta/ke/skriptu",no-port-forwarding.

V podstate som myslel to. Proste je to nieco co musis riesit ako admin. (samotny kluc si vie pouzivatel vymenit sam) A je to uplne zbytocne, lebo ak je ten clovek prihlaseny pod svojim kontom, system uplne presne vie ktory pouzivatel je to. sudo na zaklade toho vie aplikovat pravidla. Ale ked to pretlacis cez lokalne ssh, ta informacia sa straca a potom musis uplne zbytocne riesit nejake kluce. A pri ich vymene aktualizovat authorized_keys (alebo kdekolvek nastavujes to mapovanie kluc - skript)

Proč bych tohle dělal? Jenda se může přihlašovat na roota, tak má klíč v rootově authorized_keys bez command. Franta smí spouštět jenom jeden skript, tak má klíč s command.

Jasne chapem, v tomto pripade to asi nie je take zlozite. Ale pridaj si napriklad prihlasovanie cez kerberos a uz to zas zacina byt komplikovane.

máš pravdu, že i tady číhají určité nástrahy a nejistoty

A podla mojho nazoru to nie je o nic lepsie ako sudo uz len preto, ze to ssh tu pouzivas na dost nestandardny ucel a default nastavenia nebudu mat pre take pouzitie vhodne hodnoty.

[Ivan]

Dneska bych uzivateli dal normalne root-a a logoval bych co kdo dela. To jak se s casem meni pouzivani serveru, tak se postupne meni role uzivatelu. K cemu je takovy uzivatel, ktery ma root-a?

Za databazi nezodpovida, samotna aplikace ho nezajima, s uzivateli ani zakazniky nekomunikuje. Spravce aplikace ma dneska mnohem vetsi odpovednost nez root. To ze ma nekdo admin prava z nej nedela lepsiho ani zodpovednejsiho zamestnance. Navic Linux security model stoji zaprd, a bez roota neni poradne mozne diagnostikovat ani ty nejbeznejsi problemy.

Stejne vsechny to kontejnery, kubernetes dalsi vopicarny vznikly proto, aby si programatori mohli rozhodnout na cem pobezi jejich aplikace.