Red Hat řeší bezpečnostní incident, při kterém došlo k neoprávněnému přístupu do GitLab instance používané svým konzultačním týmem.
Immich byl vydán v první stabilní verzi 2.0.0 (YouTube). Jedná se o alternativu k výchozím aplikacím od Googlu a Applu pro správu fotografií a videí umožňující vlastní hosting serveru Immich. K vyzkoušení je demo. Immich je součástí balíčků open source aplikací FUTO. Zdrojové kódy jsou k dispozici na GitHubu pod licencí AGPL-3.0.
Český telekomunikační úřad vydal zprávy o vývoji cen a trhu elektronických komunikací se zaměřením na rok 2024. Jaká jsou hlavní zjištění? V roce 2024 bylo v ČR v rámci služeb přístupu k internetu v pevném místě přeneseno v průměru téměř 366 GB dat na jednu aktivní přípojku měsíčně – celkově jich tak uživateli bylo přeneseno přes 18 EB (Exabyte). Nejvyužívanějším způsobem přístupu k internetu v pevném místě zůstal v roce 2024 bezdrátový
… více »Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-10-01. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Jedná o první verzi postavenou na Debianu 13 Trixie.
Byla vydána nová verze 4.6 svobodného notačního programu MuseScore Studio (Wikipedie). Představení novinek v oznámení v diskusním fóru a také na YouTube.
Společnost DuckDuckGo stojící za stejnojmenným vyhledávačem věnovala 1,1 milionu dolarů (stejně jako loni) na podporu digitálních práv, online soukromí a lepšího internetového ekosystému. Rozdělila je mezi 29 organizací a projektů. Za 15 let rozdala 8 050 000 dolarů.
Svobodný multiplatformní herní engine Bevy napsaný v Rustu byl vydán ve verzi 0.17. Díky 278 přispěvatelům.
Bylo vydáno openSUSE Leap 16 (cs). Ve výchozím nastavení přichází s vypnutou 32bitovou (ia32) podporou. Uživatelům však poskytuje možnost ji ručně povolit a užívat si tak hraní her ve Steamu, který stále závisí na 32bitových knihovnách. Změnily se požadavky na hardware. Leap 16 nyní vyžaduje jako minimální úroveň architektury procesoru x86-64-v2, což obecně znamená procesory zakoupené v roce 2008 nebo později. Uživatelé se starším hardwarem mohou migrovat na Slowroll nebo Tumbleweed.
Ministerstvo průmyslu a obchodu (MPO) ve spolupráci s Národní rozvojovou investiční (NRI) připravuje nový investiční nástroj zaměřený na podporu špičkových technologií – DeepTech fond. Jeho cílem je posílit inovační ekosystém české ekonomiky, rozvíjet projekty s vysokou přidanou hodnotou, podpořit vznik nových technologických lídrů a postupně zařadit Českou republiku mezi země s nejvyspělejší technologickou základnou.
… více »Radicle byl vydán ve verzi 1.5.0 s kódovým jménem Hibiscus. Jedná se o distribuovanou alternativu k softwarům pro spolupráci jako např. GitLab.
Současný vývojový kernel nese označení 4.5-rc3 a vydán byl 7. února. Linus k tomu řekl: „Vydání je trochu větší, než bych chtěl, ale ne o moc (a není to nic výjimečného). Většina patchů je celkem malá; mezi změnami dominuje odstranění (velkých) rdma ovladačů ve staging fázi, které se nijak nevyvíjely. Tyto patche představují 90 % objemu změn.“
Stabilní aktualizace: Minulý týden nebyly vydány.
Casey Schaufler zahájil svou řeč na letošním linux.conf.au poznámkou, že případný autor bezpečnostního modulu by mohl slyšet něco jako, že psaní nového bezpečnostního modulu není nutně dobrý nápad. Bylo by mu řečeno, že již máme k dispozici dobrý výběr bezpečnostních modulů nebo že je vše možné udělat v SELinux a že programování pro kernel je beztak těžké. Přesto pro psaní nových bezpečnostních modulů existují dobré důvody. Přednáška byla věnována právě těmto důvodům a seznámení s příslušnou stránkou jádra.
Takže proč psát nový bezpečnostní modul? Současné moduly jsou zastaralé – odpovídají modelu z dob, kdy uživatelé při práci na počítači fyzicky přítomni v příslušné místnosti. Tyto moduly se nehodí k řešení současných problémů; nebyly navrhovány s ohledem na systémy, jako jsou smartphony. Je nejvyšší čas věnovat se metodice, která nepochází z dob děrných štítků. A ne všechno se dá udělat pomocí SELinuxu.
Musíme si uvědomit, k čemu bezpečnostní moduly slouží. Představují způsob, jak přidávat nová omezení k operacím, které se procesy mohly pokusit provést. Nemohou nahradit stávající mechanismy kontroly přístupu, které pracují tak jako tak. Nabízejí tedy nový způsob, jak zabránit operaci, ale nemohou povolit akci, kterou by jinak uživatel vykonat nemohl.
Při přemýšlení o novém bezpečnostním modulu je nutné vzít v potaz několik základních pravidel. Za prvé se chceme vyhnout duplikování existujících modulů. Pokud SELinux dokáže to, co potřebujete, bude lepší, když se připojíte ke komunitě a pokusíte se protlačit svůj zájem. Dalším pravidlem je nespoléhat na pomoc ze strany uživatelského prostoru. Existuje proprietární modul, který požádá uživatelský prostor, aby učinil konkrétní bezpečnostní rozhodnutí. Toto řešení je neefektivní a poskytuje vazbu na proprietární kód – kterýkoli z těchto důvodů by měl postačit k tomu, aby se tento kód nikdy nedostal do upstreamu. Pamatujte, že pracujete na úrovni jádra a že nechcete naštvat jaderné vývojáře. podle Schauflera je to hlavně Al Viro, kterého není radno dráždit.
Nejdůležitějším pravidlem je však volné kopírování ostatních bezpečnostních modulů. Nevymýšlejte znovu kolo. Když Schaufler napsal Smack, vypůjčil si řadu věcí právě ze SELinuxu. Takhle se to dělá v linuxové komunitě.
Casey začal o mechanice bezpečnostních modulů povídáním o háčcích (hooks), na které spoléhají. V kernelu se nacházejí funkce, které bezpečnostním modulům umožňují rozhodovat o konkrétních akcích; jejich názvy začínají na „security_“. Moduly používají tyto háčky ke kontrole přístupů a ke všeobecné správě dat; je však nutné psát háčky tak, aby byly relevantní pro daný úkol. Podle běžné praxe vracejí háčky při úspěchu nulu (čímž běžně umožňují provedení požadované operace), EACCES by se měl používat k označení odmítnutí pravidla, zatímco EPERM znamená, že požadované oprávnění chybí.
Spousta (nebo většina) háčků patří k objektově založeným (object-based), to znamená, že se vztahují ke konkrétním objektům v jaderném prostoru. Háčky často pracují se strukturami inode – tyto struktury reprezentují v jádře soubory. Avšak některé háčky pracují s názvy cest. Cesty jsou uživatelsky přívětivější, protože takto uživatelé se soubory pracují, ale nemusí jednoznačně identifikovat odpovídající objekt (např. soubory mohou mít více než jedno jméno).
„Bezpečnostní bloby“ jsou datové struktury připojené k objektům prostřednictvím bezpečnostního modulu. Často se setkáme s pojmy secctx, které odkazují na textový řetězec spojený s blobem, a secid, který představuje 32bitové identifikační číslo pro daný blob. Existují dva typy modulů, označované jako „velké“ (major) a „malé“ (minor) – rozlišuje je skutečnost, že velké moduly používají bloby. V jádře může být aktivní pouze jeden velký modul a je spuštěn po jakémkoli jiném modulu. Zatím neexistuje mechanismus pro sdílení ukazatelů bezpečnostních blobů mezi moduly, Casey se snaží toto napravit doslova křížovou výpravou. Malé moduly proto nemají žádné bloby a neudržují si žádný stav pro každý objekt. K jejich spuštění dochází po příslušné kontrole, ale před spuštěním velkého modulu (pokud existuje).
Před návrhem nového bezpečnostního modulu je třeba odpovědět na několik otázek. První z nich je: Který zdroj má modul chránit? Jestliže nedokážete odpovědět, říká Casey, nemyslíte na bezpečnost. Odpovědí by mohly být soubory vytvořené konkrétním uživatelem či konkrétní cesty v rámci souborového systému nebo může jít o ochranu specifických procesů mezi sebou.
Což vede k druhé otázce, před čím musí být tento zdroj chráněn? Obvykle je bezpečnost založena na uživatelích, ale nyní máme na mysli škodlivé aplikace. Takže než abychom chránili uživatele před sebou samými, musíme se zabývat ochranou dat Facebooku před Netflixem.
A konečně, vývojář bezpečnostního modulu musí také vědět, jak bude ochrana probíhat. Tradiční odpovědí je zkrátka zamítnutí přístupu neautorizovaným uživatelům, ale jsou možné i jiné přístupy. Často se takové pokusy samozřejmě logují. Za zvážení stojí také rozsáhlejší změny, například změna vlastníka souboru tak, aby odpovídal poslednímu uživateli, který provedl zápis skrze skupinový přístup.
Bezpečnostní moduly zpřístupňují informace přes /proc. Je ovšem dobré vyhnout se pokušení použít názvy atributů podle SELinuxu. Nový bezpečnostní modul by měl mít svá vlastní jména.
Objekty obsahují velké množství různých atributů, které mohou bezpečnostní moduly použít. Patří k nim vlastnictví, režim přístupu, typy objektů a velikosti atd. Moduly je mohou používat dle libosti, ale neměly by měnit jejich základní význam. Uživatelské ID by nemělo identifikovat aplikaci, jako to udělal „jistý systém“. Bezpečnostní moduly mohou činit rozhodnutí na základě názvu cest, pokud to funguje nejlépe, přestože rozhraní k cestám nepatří v kernelu k těm nejlépe použitelným.
Co se týče sítí, nemá toho vývojář bezpečnostních modulů už tolik na práci. Linux obsahuje subsystém netfilter, který může vykonávat všechny druhy rozhodnutí ohledně přístupu, a tento přístup by měl být vždy první na řadě. Jestliže je skutečně třeba napsat nový modul, existují háčky pro různé socketové operace, a také pro doručování paketů. Operace SO_PEERSEC se dá použít k předání bezpečnostních atributů jinému procesu. Práce s unixovými sockety je jednoduchá, protože bezpečnostní moduly mají přístup k oběma koncům připojení. Internetové sockety jsou horší, k dispozici je pouze jeden. K posílání atributů po spojení se dá použít mechanismus CIPSO. Podpora pro IPv6 pro CALIPSO je na cestě.
Casey navrhoval, aby tyto moduly logovaly odmítnutí přístupu, což by mohlo pomoci při odstraňování chyb. Užitečné věci jsou k nalezení v linux/lsm_audit.h. Která data budou zaznamenávána, záleží na autorovi modulu; k formátování dat slouží různé nástroje dostupné v uživatelském prostoru.
Netriviální moduly pravděpodobně potřebují uživatelské rozhraní; administrátoři budou vyžadovat možnost měnit pravidla přístupu, podívat se na statistiky atd. Casey nedoporučuje přidávání nových volání ioctl() nebo systémových volání; místo toho radí vytvořit virtuální souborový systém, což ulehčuje volání sysfs_create_mount_point(). Odpovídající kód se dá vypůjčit z existujícího modulu.
Konečně, co vrstvení bezpečnostních modulů? V současnosti je vrstvení malých modulů jednoduché a doporučuje se, ovšem velký modul může být vždy pouze jeden, vzhledem k tomu, že existuje pouze jeden ukazatel na bezpečnostní blob. Na systémech, kde se kernel překládá ze zdrojových kódů, se dá podvádět – stačí přidat nový bezpečnostní blob do blobu SELinuxu. Na podpoře více velkých modulů současně se pracuje, ale momentálně nemohou být podporovány.
Nakonec Casey zdůraznil, že každý, kdo chce vytvořit vlastní bezpečnostní modul, by k tomu měl mít dobrý důvod. Některé věci opravdu patří do uživatelského prostoru. Máte-li napsat modul, udělejte to pořádně: Poskytněte dokumentaci a podporujte svůj kód. Nesnažte se znovu objevit kolo, obecné zabezpečení je tu už dlouho, vymyslete něco nového. Zatím nikdo neudělal například dobrou politiku řízení zdrojů. Pravidla vázaná na senzory současných zařízení mají velký potenciál. Bezpečnost nemusí být nudná.
Video z přednášky je dostupné na stránkách LCA.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Současné moduly jsou zastaralé – odpovídají modelu z dob, kdy uživatelé při práci na počítači fyzicky přítomni v příslušné místnosti. Tyto moduly se nehodí k řešení současných problémů; nebyly navrhovány s ohledem na systémy, jako jsou smartphony. Je nejvyšší čas věnovat se metodice, která nepochází z dob děrných štítků.
Co konkrétně je na Bell–LaPadula modelu zastaralé? Neříkám, že nejde vymyslet něco lepšího, ale kdyby se používalo aspoň tohle, dost by to bezpečnosti pomohlo – uživatel by si rozdělil aplikace a soubory do několika úrovní, takže by např. WWW prohlížeč nemohl číst SSH a GPG klíče a na druhé straně, když si dešifruje nějaký tajný soubor, tak se mu nestane, že si ho omylem zapíše třeba do /tmp
, odkud si ho přečte nedůvěryhodná aplikace.