Společnost Red Hat představila program "Red Hat Enterprise Linux (RHEL) for Open Source Infrastructure" aneb Red Hat Enterprise Linux zdarma pro open source projekty.
Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 190. sraz, který proběhne v pátek 26. února od 17:00 na Jitsi Meet.
Po open source ergonomickému trackballu (dnes Classic Trackball) a open source myši představila společnost Ploopy nový open source Nano Trackball (GitHub). Trackball bez tlačítek a kolečka. Pouze kulička.
Webový prohlížeč Brave lze vedle standardního prohlížení (Nové okno) a anonymního prohlížení (Nové soukromé okno) používat i pro anonymní prohlížení s využitím Toru (Nové soukromé okno přes Tor) a pro přistup k webům v doméně .onion. Nejnovější verze Brave řeší několik bezpečnostních chyb, kdy DNS dotazy místo do Toru směrovaly k poskytovateli DNS. Ten tak mohl zjistit, že uživatel chtěl přistupovat například k sejnfjrq6szgca7v.onion (debian.org).
Byla vydána nová verze 2021.1 průběžně aktualizované linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek i s náhledy a seznamem nových nástrojů v oficiálním oznámení. Kali Linux má nové webové stránky.
Multiplatformní open source počítačová hra Minetest byla vydána ve verzi 5.4.0. Přehled změn v changelogu. Jedná se o hru inspirovanou Minecraftem.
Byla vydána (Twitter) nová verze 3.18 svobodného multiplatformního geografického informačního systému QGIS (Wikipedie). Přehled novinek i s náhledy a animovanými gify ve visuálním changelogu a také na YouTube.
Byla vydána nová verze 4.16 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl aktualizován na verzi 10.0.12. Thunderbird byl aktualizován na verzi 78.7.0. Linux byl aktualizován na verzi 5.10.13. Tor byl aktualizován na verzi 0.4.5.5.
Dokumentační tým projektu LibreOffice vydává příručku Getting Started Guide 7.0. Příručka je určena pro každého, kdo se chce seznámit s programem LibreOffice a představuje hlavní komponenty LibreOffice: textový procesor Writer, tabulkový procesor Calc, prezentační program Impress, vektorový grafický program Draw, databázový program Base a editor rovnic Math. Příručka je ke stažení na stránce LibreOffice, kde lze stáhnout i české překlady dalších příruček.
Byl vydán Mozilla Firefox 86.0. Přehled novinek v poznámkách k vydání, poznámkách k vydání pro firmy a na stránce věnované vývojářům. Novinkou je Total Cookie Protection aneb "každý web má vlastní dózu na sušenky". Nově lze používat funkci obraz v obraze současně pro několik videí. Řešeny jsou také bezpečnostní chyby. Nejnovější Firefox je již k dispozici také na Flathubu.
Balíček s utilitou sudo byl vydán ve verzi 1.9.5p2. Řešena je bezpečnostní chyba CVE-2021-3156. Lokální uživatel může získat práva roota i když není uveden v souboru sudoers. Podrobnosti i s videoukázkou v příspěvku na blogu společnosti Qualys. Chyba byla do kódu sudo zanesena na konci července 2011 (commit 8255ed69). Týká se tedy verzí 1.8.2 až 1.8.31p2 a 1.9.0 až 1.9.5p1.
Tiskni
Sdílej:
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)
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: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
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.
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.
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.
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.
rm -rf /
.
(ale ako dodatocny log record sa mi to paci)
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.
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í.
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)
systemd-run
, ktory spusti proces v presne definovanom prostredi a mas nad tym prostredim omnoho vacsiu kontrolu.
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 serverwat 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.
wat ssh root@127.0.0.1 /cesta/ke/skriptu.shAno 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.
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.shAha, 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.
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 nejistotyA 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.