Aktualizace v Red Hat-Based Linux Distributions

V RHEL klonech jsou staré verze SW, ne vždy je přitom potřeba řešit upgrade na nové verze. Pro odstranění chyb a bezpečnostních problémů stačí využít tzv. backporting. Tento článek vysvětluje, co backporting je a jak funguje.

Backporting oprav zabezpečení v RHEL a jeho klonech

Termín backporting se používá k popisu akce spočívající v provedení opravy bezpečnostní chyby v nejnovější verzi upstream softwarového balíčku a aplikaci této opravy na starší verzi balíčku, který distribuujeme.

Backporting je nezbytný pro zajištění toho, že můžeme nasadit automatické aktualizace s minimálním rizikem. Má rovněž řadu výhod, ale může způsobit zmatek, když se mu nerozumí. Musíte si být vědomi, že pouhý pohled na číslo verze balíčku neřekne, zda obsahuje zranitelnost nebo ne.

Různé články pracují s frázemi typu: „pro vyřešení problému upgradujte na ApacheApacheApache je nejpoužívanější webový server, tzn. že dodává prohlížečům jednotlivé webové stránky…více httpd 2.4.37“. Ty však berou v úvahu pouze číslo upstreamové verze, což může být matoucí. Po instalaci aktualizovaných balíčků od dodavatele totiž není pravděpodobné, že zákazníci budou mít i nejnovější upstream verzi. Místo toho budou mít starší upstreamovou verzi s aplikovanými backportovanými záplatami.

Některé nástroje pro bezpečnostní skenování a audit také rozhodují o zranitelnostech pouze na základě počtu verzí komponent, které najdou. To má za následek falešné poplachy, protože nástroje neberou v úvahu backportované opravy zabezpečení.

Od ledna 2000 jsou k upozorněním připojené názvy CVE, což umožňuje snadno křížově odkazovat na zranitelnosti a zjistit, jak a kdy byla opravena, nezávisle na číslech verzí.

Co je backporting

Čísla verzí jsou důležitá, ale nejsou vždy taková, jaká se na první pohled zdají. Red Hat například často backportuje updaty softwaru, který dodává, aby zachoval verzi, se kterou byl nainstalován.

První otázka zní: Proč jsou verze důležité? V některých případech je to velmi jednoduché, novější software znamená nové funkce a nové možnosti.

Pak se dostaneme k nejnudnější a nejpodrobnější odpovědi na otázku, proč jsou verze důležité; software má chyby. Liší se v závažnosti, rozsahu a využitelnosti. Uživatelé požadují nové funkce nebo změny balíčků. Řešení těchto chyb a požadavků se odráží také v aktualizovaných verzích balíčků, které jsou součástí distribuce.

Než se ponoříme do podrobností o tom, co bylo aplikováno na tu či onu verzi softwaru, vysvětleme si nejdřív, jak je software udržován. Některé z těchto procesů nazýváme backporting. Ale co to je a jak k tomu dochází?

Pokud se podíváte na balíček RPM, všimnete si konzistentní konvence pojmenování. Chcete-li získat tyto informace, můžete spustit rpm -q openssh-server.

V tabulce je zobrazeno, jak jsou názvy balíčků RPM rozděleny podle názvu, verze atd.

• Název: Název softwaru. V tomto případě openssh-server.
• Verze: Verze projektu s otevřeným zdrojovým kódem použitým k vytvoření tohoto balíčku. V tomto příkladu je tento balíček založen na verzi 8.0.
• Extra vers[ion]: Tato část verze tohoto balíčku je specifická pro Red Hat Linux. RPM obecně poskytuje toto pole pro tvůrce balíčků softwaru, aby si udržel vlastní data specifická pro verzi. Protože tento balíček pochází od společnosti Red Hat, dodatečná data o verzi používá správce tohoto RPM Red Hat. Různí správci nebo týmy ve společnosti Red Hat se mohou rozhodnout formátovat toto pole mírně odlišně, ale vždy obsahuje určité informace o verzích a obvykle označuje verzi Red Hat Enterprise Linux, pro kterou byl balíček vytvořen.
• Arch[itechure]: Typ CPU, pro který jsou zkompilovány binární soubory obsažené v tomto balíčku. V tomto poli můžete vidět jiné architektury CPU, pokud byly binární soubory balíčků zkompilovány pro jiný CPU, např. aarch64 nebo noarch, což by znamenalo, že balíček je architektonicky neutrální.

Jak funguje backporting

Nyní se podíváme podrobněji, co udělal Red Hat pro vytvoření 10.el8 a jak se liší od dřívějších verzí balíčku openssh-server RPM. To, o čem teď mluvíme, je backporting. Doslova přebíráme kód z novější verze upstream a integrujeme jej zpět do starší verze softwaru. To je jedna z nejlepších věcí na open source.

Vzhledem k tomu, že změny jsou prováděny za účelem opravy chyb nebo řešení zranitelností, mohou inženýři Red Hatu převzít změny z upstreamu a integrovat je do aktualizace nainstalované verze. Ne všechny změny jsou samozřejmě zpětně portovány. Přísně se snažíme řešit především chyby a bezpečnostní problémy, než se snažit přinášet nové funkce do starších verzí.

Jak to vypadá pro lidi spravující stroj? Pokud se podíváte na changelog balíčku, v našem případě openssh-server, pomocí rpm -q --changelog openssh-server byste viděli něco jako následující:

Výpis je samozřejmě výrazně delší, ale na ukázku stačí nejnovější změny.

V tomto výstupu můžeme vidět historii balíčku a také to, co se změnilo v každé z vydaných verzí RPM. Poslední změnou je ta, která vygenerovala verzi 8.0p1-10.

Kromě popisu toho, co tato aktualizace řeší, zjistíte také ID číslo Red Hat bugzilla (#1836277). Jde o ID, nyní již vyřešeného, problému. Alternativně např. byla v aktualizaci, která vyústila ve verzi 8.0p1-9, vyřešena chyba zabezpečení (CVE-2020-14145).

Proč jsou balíčky v Red Hat udělané tímto způsobem? Proč věnovat veškerou snahu backportingu namísto pouhého stažení aktualizovaného zdroje z projektu s otevřeným zdrojovým kódem a kompilace nové verze? Red Hat je komplexní distribuce se spoustou různých balíčků, které tvoří produkt. Kromě toho na této platformě běží zákaznický software (jenž má svou vlastní složitost). Pokud by Red Hat nahradil balíček zcela novou verzí, mohla by tato změna ovlivnit některý z těch dalších balíčků nebo procesů běžících nad distribucí.

Nové vydání OpenSSH serveru by možná odstranilo nebo změnilo některé funkce, které by mohly ovlivnit skripty nebo software běžící nad OS. To je v pořádku pro upstream verzi nebo budoucí verze OS, když to uživatelé očekávají, ale špatné pro verzi, u níž se očekává, že bude mezi aktualizacemi stabilní.

Pomocí metody backportingu je možné poskytovat aktualizace operačního systému a současně snížit riziko historicky spojené s aplikací aktualizace na komplexní provozní infrastrukturu.

Řada organizací má bezpečnostní požadavky, které vyžadují, aby aktualizace systému byly aplikovány během určitého počtu dní nebo měsíců. Aby bylo možné měřit úspěšnost dodržování těchto zásad, lze systémy auditovat pomocí bezpečnostních skenerů.

Některý skenovací software, jak bylo již zmíněno na začátku, však nepočítá se zpětným portováním funkcí, které Red Hat používá pro údržbu a aktualizaci balíčků. Například připojení k démonu SSH zobrazí verzi:

Nejnovější verze OpenSSH z openssh.com je však 8.2, nikoli 8.0 hlášená ze systému. V takovém případě bychom pravděpodobně obdrželi oznámení od auditora týkající se nutnosti aktualizace SSH balíčku v našem systému. To ale zřejmě není potřeba, neboť na serveru máme nainstalovaný nejnovější podporovaný balíček. Zatímco náš server hlásí OpenSSH 8.0, zobrazuje také další verzi 10.e18. Stáhnout můžeme i data z RPM changelogu, abychom zkontrolovali, že zranitelnosti, na něž auditor upozorňuje, byly skutečně odstraněny pomocí zpětně portovaných oprav.