Byla vydána nová stabilní verze 7.6 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 140. Přehled novinek i s náhledy v příspěvku na blogu.
Byla vydána verze 1.90.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
GNUnet (Wikipedie) byl vydán v nové major verzi 0.25.0. Jedná se o framework pro decentralizované peer-to-peer síťování, na kterém je postavena řada aplikací.
Byla vydána nová major verze 7.0 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Nově je postavena je na Debianu 13 (Trixie) a GNOME 48 (Bengaluru). Další novinky v příslušném seznamu.
Společnost Meta na dvoudenní konferenci Meta Connect 2025 představuje své novinky. První den byly představeny nové AI brýle: Ray-Ban Meta (Gen 2), sportovní Oakley Meta Vanguard a především Meta Ray-Ban Display s integrovaným displejem a EMG náramkem pro ovládání.
Po půl roce vývoje od vydání verze 48 bylo vydáno GNOME 49 s kódovým názvem Brescia (Mastodon). S přehrávačem videí Showtime místo Totemu a prohlížečem dokumentů Papers místo Evince. Podrobný přehled novinek i s náhledy v poznámkách k vydání a v novinkách pro vývojáře.
Open source softwarový stack ROCm (Wikipedie) pro vývoj AI a HPC na GPU od AMD byl vydán ve verzi 7.0.0. Přidána byla podpora AMD Instinct MI355X a MI350X.
Byla vydána nová verze 258 správce systému a služeb systemd (GitHub).
Byla vydána Java 25 / JDK 25. Nových vlastností (JEP - JDK Enhancement Proposal) je 18. Jedná se o LTS verzi.
Věra Pohlová před 26 lety: „Tyhle aféry každého jenom otravují. Já bych všechny ty internety a počítače zakázala“. Jde o odpověď na anketní otázku deníku Metro vydaného 17. září 1999 na téma zneužití údajů o sporožirových účtech klientů České spořitelny.
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.