Všem vše nejlepší do nového roku 2026.
Crown je multiplatformní open source herní engine. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT a GPLv3+. Byla vydána nová verze 0.60. Vyzkoušet lze online demo.
Daniel Stenberg na svém blogu informuje, že po strncpy() byla ze zdrojových kódů curlu odstraněna také všechna volání funkce strcpy(). Funkci strcpy() nahradili vlastní funkcí curlx_strcopy().
Byla vydána nová verze 25.12.30 svobodného multiplatformního video editoru Shotcut (Wikipedie) postaveného nad multimediálním frameworkem MLT. Shotcut je vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Společnost Valve publikovala přehled To nej roku 2025 ve službě Steam aneb ohlédnutí za nejprodávanějšími, nejhranějšími a dalšími nej hrami roku 2025.
Byly publikovány výsledky průzkumu mezi uživateli Blenderu uskutečněného v říjnu a listopadu 2025. Zúčastnilo se více než 5000 uživatelů.
V dokumentově orientované databázi MongoDB byla nalezena a v upstreamu již opravena kritická bezpečností chyba CVE-2025-14847 aneb MongoBleed.
Při úklidu na Utažské univerzitě se ve skladovacích prostorách náhodou podařilo nalézt magnetickou pásku s kopií Unixu V4. Páska byla zaslána do počítačového muzea, kde se z pásky úspěšně podařilo extrahovat data a Unix spustit. Je to patrně jediný známý dochovaný exemplář tohoto 52 let starého Unixu, prvního vůbec programovaného v jazyce C.
FFmpeg nechal kvůli porušení autorských práv odstranit z GitHubu jeden z repozitářů patřících čínské technologické firmě Rockchip. Důvodem bylo porušení LGPL ze strany Rockchipu. Rockchip byl FFmpegem na porušování LGPL upozorněn již téměř před dvěma roky.
K dispozici je nový CLI nástroj witr sloužící k analýze běžících procesů. Název je zkratkou slov why-is-this-running, 'proč tohle běží'. Klade si za cíl v 'jediném, lidsky čitelném, výstupu vysvětlit odkud daný spuštěný proces pochází, jak byl spuštěn a jaký řetězec systémů je zodpovědný za to, že tento proces právě teď běží'. Witr je napsán v jazyce Go.
Nejaktuálnější verzí je verze 3.2 vydaná 4. ledna. Začleňovací okno verze 3.3 je stále otevřené, více o tom, co bylo v uplynulém týdnu začleněno, se dozvíte níže. Verzi 3.3-rc1 pravděpodobně můžeme očekávat brzy.
Stabilní vydání: Stabilní jádro 3.1.10 vyšlo 18. ledna. Toto je poslední stabilní aktualizace v řadě 3.1.x, takže uživatelé by měli přejít na řadu 3.2.
Kromě toho vyšly 12. ledna stabilní verze 2.6.32.54, 3.0.17, 3.1.9 a 3.2.1.
Ani na vteřinu si nemyslete, že někdo něco neudělá jen proto, že je to evidentně nevhodné.
Myslím si, že tento řádek by tam neměl být vůbec. Nemá žádný smysl... uvědomuji si, že jsem jej napsal, a že tedy musí být bezchybný, ale myslím si, že odstranění tohoto řádku je ještě *více* bezchybné.
Sledovací body [tracepoints] se kupí jako dluh USA. Musíme stanovit nějaká pravidla. Buď vytvořením knihovny, která je schopná ošetřit drobné změny (jako jsou ty, co tu diskutujeme, i když memcpy by se s tím mělo vyrovnat), nebo musíme zarazit přidávání nových sledovacích bodů, protože je to novodobá móda. Snad bychom mohli sledovacím bodům dát stejná pravidla jako systémovým voláním.
Práce na dma-buf původně začaly s cílem sjednotit několikero soupeřících systémů „pro správu paměti“, které byly vyvinuty s ohledem na různé ARM SoC. Bylo by nemilé, kdyby vyhrazení použití dma-buf pro moduly licencované pod GPL, omezilo jeho rozšíření.
-- Robert Morell z NVIDIA
V době psaní textu bylo do hlavní řady přetaženo téměř 8800 neslučovacích změn pro vývojový cyklus 3.3 – 2900 od souhrnu z minulého týdne. V druhém týdnu se tempo začleňování změn jednoznačně snížilo, ale i tak byla začleněna řada zajímavostí.
Změny viditelné uživatelům od posledního týdne zahrnují:
Mezi změny viditelné vývojářům patří:
Vydání 3.3-rc1 se může objevit každou chvíli, poté bude zahájen proces stabilizace. Pokud bude platit obvyklé načasování, pak můžeme konečnou verzi 3.3 očekávat v druhé polovině března.
Už 12. ledna se zběžně psalo o návrhu na omezování systémových volání pomocí jaderného mechanismu filtrování paketů, ale v té době ještě tento návrh nekomentoval. Od té doby proběhlo několik kol komentování a revidování patchů spolu s oživením původní myšlenky dát procesu možnost omezit sebe sama a své potomky na aktuální úroveň oprávnění. Zatím byla odezva celkově pozitivní, a to natolik, že to vypadá, že se obecné filtrování systémových volání může dostat do hlavní řady v dohledné budoucnosti.
Už nějakou dobu se Will Drewry snaží najít přijatelný způsob, jak rozšířit funkčnosti seccomp v jádře do podoby, kdy je možné dělat flexibilnější filtrování systémových volání. Jde mu o prohlížeč Chrome/Chromium a umístění nedůvěryhodného kódu do sandboxu, ale i jiné projekty (včetně QEMU, openssh, vsftpd a další) projevily o tuto funkci zájem. On (a jiní) zkusili v posledních několika letech různé způsoby, aniž by se našel nějaký, který by vyhověl požadavkům. Jeho poslední pokus používající BPF (Berkeley Packet Filter) pro filtrování systémových volání vypadá, že se vyhýbá mnoha problémům, na které bylo při dřívějších pokusech poukázáno.
Hlavní myšlenkou je to, že namísto zkoumání obsahu paketů budou filtry zkoumat systémová volání a všechny argumenty předané v registrech (což znamená, že nebude následovat ukazatele, aby nedocházelo k race situacím kvůli odlišnému času kontroly a použití). Kód povolí jen ta volání, která projdou filtrem. Všechna volání, která nejsou na seznamu filtru nebo jejichž argumenty neodpovídají pravidlům ve filtru, vrátí chybu EACCES. Syntaxe vytváření filtru popsaná v dokumentaci je dosti nepříjemná, ale Eric Paris už začal pracovat na překladači, který převede čitelnější formu na pravidla BPF.
Aby se obešel dlouhotrvající problém s interakcí mezi binárkami, která mohou měnit svá práva (např. setuid), a mechanismy omezujícími práva procesů, Drewrův původní patch omezuje schopnost procesu učinit volání execve(), jakmile je nastaven filtr. Problém je v tom, že binárky měnící práva mohou být zmateny, když jsou v prostředí, kde mají méně práv, než očekávají. Toto zmatení může vést k eskalaci práv nebo bezpečnostním chybám. To je ten důvod, proč jsou chroot(), bind mounty a ve výsledku i uživatelské jmenné prostory omezeny na procesy s právem roota.
Jakmile ale filtrovaný proces nemůže úspěšně zavolat execve(), všechny obavy o zmatení binárek mizí. Ve výsledku to ale používání filtrování systémových volání činí poněkud neohrabaným. Člověk by čekal, že rodič nastaví filtry a pak spustí potomka, který by byl těmito filtry omezen, ale to by bez možnosti udělat exec nefungovalo. Toto se dá obejít u většiny programů pomocí fíglu s LD_PRELOAD, ale v rámci diskuze se objevilo i jiné řešení.
Andrew Lutomirski poukázal na svůj návrh execve_nosecurity jako na možné řešení. To by procesům umožnilo nastavit příznak, že oni (a jejich potomci) nemohou zavolat execve() a přidala by se nová varianta (s trochu matoucím názvem execve_nosecurity()), která by mohla být použita místo toho, ale u spuštěného programu by nedošlo ke změnám v právech. To znamená, že setuid, změny kontextu LSM, změny capabilities a tak dále by nebyly povoleny. Linus Torvalds souhlasil, že přidání možnosti omezit změny oprávnění by bylo užitečné:
Mohli bychom snadno zavést příznak procesu, který znamená „nemůže zvýšit oprávnění“. To by v podstatě zakázalo execve suid/sgid programů (a možná i dalších věcí a omezilo práva aktuálního procesu na ta stávající. A pak by se udělalo pravidlo, že *pokud* je tento příznak nastaven, můžete filtrovat napříč execve nebo chroot jako obyčejný uživatel nebo něco jiného.
To vedlo Lutomirského k návrhu příznaku v struct task_struct nazvanému no_new_privs, který by byl nastaven pomocí příznaku PR_SET_NO_NEW_PRVIS přes prctl(). Byla by to jen taková jednosměrná jízdenka, protože by nebylo cesty zpět, tedy jak příznak zrušit. Pokud by byl příznak nastaven, došlo by k omezení spouštění binárek podobně jako přes příznak mountu nosuid. Navíc by bylo procesu zakázáno měnit capabilities při exec nebo přecházet mezi kontexty SELinuxu.
Lutomirského patche ale neimplementuje sandbox, protože, jak Alan Cox upozorňuje, jej stále jde ošidit přes ptrace(). Cox měl také obavy, že zamezení SELinuxu, AppArmoru nebo jiným LSM měnit práva může vést k dalším problémům, neboť tyto přechody mohou být i ve směru k nižším oprávněním. Prosté zachování předchozího kontextu, jako to dělá Lutomirského patch, může vést ke spouštění programů s více právy. Ale Eric Paris sdělil, že přinejmenším SELinux bude stále dělat stejná rozhodnutí i bez přechodu (jako to dělá u mountů s nosuid), takže spuštění tak jako tak selže, pokud má proces nesprávný kontext.
Lutomirski také poznamenal, že sandbox bude mnohem méně užitečný, pokud execve() musí selhat, jakmile dochází k jakékoliv změně práv, jak Cox navrhoval. Přítomnost pravidel u konkrétní binárky by pak učinilo binárku nepoužitelnou ze sandboxu, ať už jsou pravidla jakákoliv. Lepším řešením by podle Lutomirského bylo nastavit bit no_new_privs, pak vytvořit sandbox (například za použití filtrování systémových volání přes seccomp od Drewryho) a pak spustit binárku, což by uspělo nebo selhalo v závislosti na aktuálních pravidlech mandatory access control (MAC). To řeší problém s ptrace() a dalšími metodami, jak zabezpečení obejít, protože sandbox vyžaduje jak patch no_new_privs, tak nějaký další mechanismus pro filtrování systémových volání:
no_new_privs není vůbec zamýšleno jako sandbox – jde o způsob, jak umožnit procesu v bezpečí zacházet sám se sebou takovým způsobem, který by mu umožnil poškozovat své vlastní potomky (nebo sebe sama po execve). Takže ptrace vůbec není problém – PR_SET_NO_NEW_PRVIS + chroot + ptrace je přesně tak nebezpečné jako ptrace bez PR_SET_NO_NEW_PRVIS. Ani jedno neumožňuje povýšení práv nad to, na čem jste začali.
Pokud chcete sandbox, zavolejte PR_SET_NO_NEW_PRVIS, pak povolte seccomp (nebo něco jiného) pro zakázání ptrace, zlomyslného přístupu k souborů, připojení k unixovým soketům, které se ověřují přes uid atd.
Drewry mezitím revidoval své patche, aby využil no_new_privs. Jedna z těchto revizí vedla k dalším obavám, zda by snižování práv mělo po nastavení bitu být povoleno. Torvalds má obavy, že povolení snižování práv by mohlo nějak vést ke zmatení ostatních programů: Už jsme tu měli bezpečnostní chyby *kvůli* snížení oprávnění – někdo odebral jedno oprávnění, ale už ne jiné, čímž navedl kód k činnostem, které nebyly očekávány. Lutomirského patch neomezuje věci jako volání setuid(), protože není určen k implementaci sandboxu – to je to, co dělá stávající seccomp nebo rozšířená verze z Drewryho patchů (neboli seccomp režim 2). Lutomirski vysvětluje:
Dá se to jinak říci takto: no_new_privs není sandbox. Je to jen způsob, jak sandboxům a jiným zvláštním věcem, co si procesy mohou provést, umožnit bezpečně pracovat napříč execve. Pokud chcete sandbox, použijte seccomp režim 2, což bude vyžadovat nastavení no_new_privs.
Je jasné, že si přinejmenším Lutomirski myslí, že no_new_privs nemůže vést k problémům, jakých se Torvalds a jiní (hlavně vývojář Smacku Casey Schaufler) obávají. Ale každý program, který používá no_new_privs, si musí být vědom toho, co to dělá (a co ne). Ve spojení s mechanismy pro filtrování systémových volání to vypadá, že to může jen vést ke zvýšení bezpečnosti systému. Ale interakce mezi bezpečnostními mechanismy často mají nepředvídané následky, často vedoucí k bezpečnostním chybám, takže má smysl dávat si pozor.
Prozatím jsou tyto změny stále diskutovány a žádný ze správců subsystémů neprojevil zájem si je pod sebe vzít, ale oba návrhy získaly podporu, kterou se předchozím nápadům nepodařilo získat. Zda dokáže Lutomirski přesvědčit ostatní jaderné hackery, že no_new_privs nemůže vést k jiným problémům, nebo zda musí vymyslet, jak zabránit odebírání práv, to není jasné. Ale vypadá to, že se konečně může rozšířený seccomp dostat do hlavní řady.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
30.1.2012 07:51
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
30.1.2012 13:54
rADOn | skóre: 44
| blog: bloK
| Praha
30.1.2012 12:18
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
Nie je to nahodou hlavny zamer jadra, aby boli ovladace otvorene (kedze je cele jadro pod GPL)? Urcite nie je pre NVIDIU pekne, ze cele jadro je pod GPL. Najradsej by ho asi forkli, pozmenili, zatvorili a potom predavali...To si nemyslím. Ovladače jen prostě nedostaly od právního oddělení zelenou a teď se jejich programátoři (kteří by jistě sami byli nejradši, kdyby jejich práce byla open source) snaží bojovat proti redundanci...
30.1.2012 14:21
rADOn | skóre: 44
| blog: bloK
| Praha
Otevreny ovladac by sice potesil, ale OTOH kdyby vsechen komercni shit byl aspon na teto urovni, uplne by to stacilo.
30.1.2012 15:50
pavlix | skóre: 54
| blog: pavlix
AFAIK ovladace nvidie jsou uzavreny protoze je v nich cizi licencovany kod ktery otevrit nemuzou.AFAIK se toto používá jako univerzální výmluva, podobně jako se třeba krize používá jako univerzální výmluva pro to, abys dostal za práci míň peněz a ještě pozdě. Cizí kód, stejně jako krize, může v konkrétních případech být skutečným důvodem. Ale čím víc je ta výmluva známá, tím měnší je podíl případů, kdy je opravdu relevantní.
Otevreny ovladac by sice potesil, ale OTOH kdyby vsechen komercni shit byl aspon na teto urovni, uplne by to stacilo.Jak komu. Ale o problému uzavřenosti driverů jsem se rozepisoval už tolikrát...
30.1.2012 11:59
Max | skóre: 72
| blog: Max_Devaine
jo , to je celkem problem ...
ono existuje dost experimentalnich systemu snazici se toto resit (treba Singularity od M$) ale kompaktibilita je s zbytkem sveta prakticky nulova. ...
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz