V sobotu 9. srpna uplynulo přesně 20 let od oznámení projektu openSUSE na konferenci LinuxWorld v San Franciscu. Pokuď máte archivní nebo nějakým způsobem zajímavé fotky s openSUSE, můžete se o ně s námi podělit.
Byl vydán Debian 13 s kódovým názvem Trixie. Přehled novinek v poznámkách k vydání.
WLED je open-source firmware pro ESP8266/ESP32, který umožňuje Wi-Fi ovládání adresovatelných LED pásků se stovkami efektů, synchronizací, audioreaktivním módem a Home-Assistant integrací. Je založen na Arduino frameworku.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.8.
Herní studio Hangar 13 vydalo novou Mafii. Mafia: Domovina je zasazena do krutého sicilského podsvětí na začátku 20. století. Na ProtonDB je zatím bez záznamu.
Operátor O2 má opět problémy. Jako omluvu za pondělní zhoršenou dostupnost služeb dal všem zákazníkům poukaz v hodnotě 300 Kč na nákup telefonu nebo příslušenství.
Společnost OpenAI představila GPT-5 (YouTube).
Byla vydána (𝕏) červencová aktualizace aneb nová verze 1.103 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.103 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Americký prezident Donald Trump vyzval nového generálního ředitele firmy na výrobu čipů Intel, aby odstoupil. Prezident to zdůvodnil vazbami nového šéfa Lip-Bu Tana na čínské firmy.
Bylo vydáno Ubuntu 24.04.3 LTS, tj. třetí opravné vydání Ubuntu 24.04 LTS s kódovým názvem Noble Numbat. Přehled novinek a oprav na Discourse.
Mapování z cesty na kontexty pro relabel a kontexty dané přechodovými pravidly by měly být v souladu.
Pokud jste si udělal vlastní adresářovou strukturu, tak byste si měl rozmyslet, jestli kontexty, které dělá apache nedávají smysl. Pokud ano, tak si opravte mapování. Pokud ne, tak si opravte politiku pro apache nebo si nastavte restorecond, aby opravoval kontexty i ve vašich adresářích (nemusí si to ale být zcela bezpečné řešení).
semanage fcontext -l ... /var/www(/.*)? all files system_u:object_r:httpd_sys_content_t:s0 ... /var/www/html/configuration\.php all files system_u:object_r:httpd_sys_rw_content_t:s0 ...Apache ale vždy vytváří soubory s kontextem httpd_sys_rw_content_t a jediný správný soubor s tímto kontextem je podle mapování /var/www/html/configuration.php. Ovšem né všechny weby mají takové cesty a většinou je potřeba, aby apache zapisoval i jinam ve webovém adresáři. Třeba hostingy si nemůžou toto nastavovat a prostý uživatel nemá oprávnění ke změně mapování. Jak tedy nejlépe řešit konkrétně tuto situaci? Nedá se nastavit mapování pro danou cestu jak na httpd_sys_content_t, tak na httpd_sys_rw_content_t s tím, že se jako výchozí bude uplatňovat to první, ale aby bylo i ten druhý kontext pro tuto cestu správný?
Apache ale vždy vytváří soubory s kontextem httpd_sys_rw_content_t
Protože ten soubor apache vytvořil, tak proč by do něj neměl mít možnost znovu zapsat? Na tomto přechodovém pravidle obecně nevidím nic špatného.
Ovšem né všechny weby mají takové cesty a většinou je potřeba, aby apache zapisoval i jinam ve webovém adresáři.
Pokud to je potřeba, tak si nastavte mapovaní pro dané cesty na httpd_sys_rw_content_t. Z hlavy si nevybavuji všechny apachové kontexty, ale myslím, že tento je správný. Něco se lze dočíst v manuálové stránce httpd_selinux(8).
Třeba hostingy si nemůžou toto nastavovat a prostý uživatel nemá oprávnění ke změně mapování.
Proč by to provozovatel hostingu nemohl nastavovat? Od toho je mapování na kontexty nastavitelné. Samozřejmě že běžný uživatel nemůže měnit nastavit SELinuxu. To by byla bezpečnostní díra.
Jak tedy nejlépe řešit konkrétně tuto situaci?
Konfigurovat SELinux podle požadavků zákazníka (vždyť si to platí), nebo na celý DocumentRoot hodit httpd_sys_rw_content_t. Musíte rozhodnout sám, jestli to chcete mít pohodlné nebo bezpečné.
Nedá se nastavit mapování pro danou cestu jak na httpd_sys_content_t, tak na httpd_sys_rw_content_t s tím, že se jako výchozí bude uplatňovat to první, ale aby bylo i ten druhý kontext pro tuto cestu správný?
Ne. Soubor může mít nejvýše jeden kontext.
Toto mi právě nešlo do hlavy. Když zakázník nahrává webové aplikace, tak ani většinou netuší, jaká oprávnění tam potřebuje. Proto mi přijde nepraktické pro stovky/tisíce webů upravovat kontexty po každé větší aktualizaci webové aplikace. ... no ještě že nedělám hostingy. Já si jen hostuju cca 3 weby, ale stejně jsem narazil na to, že není možné pořádně uhlídat (respektive dá se to dlouhým zkoumáním zdrojového kódu dané webové aplikace), kam má mít apache rw přístup (např. redakční systémy a jejich rozšiřování pluginy).Konfigurovat SELinux podle požadavků zákazníka (vždyť si to platí), nebo na celý DocumentRoot hodit httpd_sys_rw_content_t. Musíte rozhodnout sám, jestli to chcete mít pohodlné nebo bezpečné.
Ano, napsat pořádnou politiku dá práci. Kromě čtení kódu lze přepnout SELinux do permissive režimu, procvičit aplikaci, a pak podle stížností v protokolu SELinuxu napsat politiku. Dokonce existuje nástroj audit2allow, který vám pomůže politiku vygenerovat.
Ve vašem případě ale stačí řešit zápis a čtení pomocí rozdělení kontextů pro soubory, kam se má číst a kam zapisovat. Z rozumně dokumentované aplikace lze snadno poznat, kam má a kam nemá zapisovat. Takže odhadnout mapování z cest na kontexty by neměl být problém. Samozřejmě záleží, jak daná aplikace vypadá. Mám takové neblahé tušení, že webové aplikace patří k horší půlce softwaru.
Tiskni
Sdílej: