Fórum Root.cz
Hlavní témata => Distribuce => Téma založeno: LamZelezo 21. 07. 2025, 13:12:26
-
Uz nekolik mesicu vychazi bezpecnostni zaplaty kernelu RHEL (a jeho derivatu) v tydennim rytmu. K dnesnimu dni bylo vydano stejne mnozstvi zaplat jako ke konci lonskeho roku. Co je toho pricinou? Pekne to zere cas (ziju v tom, ze automaticke zaplatovani kernelu nefunguje poradne)
2025-07-21 - RHSA-2025:11411 - kernel-5.14.0-570.28.1.el9_6
2025-07-14 - RHSA-2025:10837 - kernel-5.14.0-570.26.1.el9_6
2025-07-07 - RHSA-2025:10379 - kernel-5.14.0-570.25.1.el9_6
2025-06-30 - RHSA-2025:9880 - kernel-5.14.0-570.24.1.el9_6
2025-06-23 - RHSA-2025:9302 - kernel-5.14.0-570.23.1.el9_6
2025-06-16 - RHSA-2025:9080 - kernel-5.14.0-570.22.1.el9_6
2025-06-09 - RHSA-2025:8643 - kernel-5.14.0-570.21.1.el9_6
2025-06-02 - RHSA-2025:8333 - kernel-5.14.0-570.19.1.el9_6
2025-05-26 - RHSA-2025:8142 - kernel-5.14.0-570.18.1.el9_6
2025-05-19 - RHSA-2025:7903 - kernel-5.14.0-570.17.1.el9_6
2025-05-13 - RHSA-2025:7423 - kernel-5.14.0-570.16.1.el9_6
2025-05-13 - RHSA-2025:6966 - kernel-5.14.0-570.12.1.el9_6
2025-04-30 - RHSA-2025:4341 - kernel-5.14.0-503.40.1.el9_5
2025-04-16 - RHSA-2025:3937 - kernel-5.14.0-503.38.1.el9_5
2025-04-02 - RHSA-2025:3506 - kernel-5.14.0-503.35.1.el9_5
2025-03-26 - RHSA-2025:3208 - kernel-5.14.0-503.34.1.el9_5
2025-03-11 - RHSA-2025:2627 - kernel-5.14.0-503.31.1.el9_5
2025-02-19 - RHSA-2025:1659 - kernel-5.14.0-503.26.1.el9_5
2025-02-11 - RHSA-2025:1262 - kernel-5.14.0-503.23.2.el9_5
2025-01-22 - RHSA-2025:0578 - kernel-5.14.0-503.22.1.el9_5
2025-01-08 - RHSA-2025:0059 - kernel-5.14.0-503.21.1.el9_5
2024-12-19 - RHSA-2024:11486 - kernel-5.14.0-503.19.1.el9_5
-
To je ale sviňárna - pravidelně záplatovat bezpečnostní chyby v jádře! Fuj! ::)
-
Tyhle bezpečnostní aktualizace každého jenom otravují. Já bych všechny ty internety a počítače zakàzala.
Ano, s tím se nedá nesouhlasit.
-
To se nikdo nepidi, proc se mu zvedly naklady na udrzbu stroju a co by se s tim dalo delat?
-
To se nikdo nepidi, proc se mu zvedly naklady na udrzbu stroju a co by se s tim dalo delat?
A co by s tím tedy měli dělat, když opravují zveřejněné zranitelnosti a aktulizace zveřejňují podle závažnosti?
Počítám, že tak trochu nemůžou dopředu vědět, co se objeví (hele Fando, už jich máme letos moc, počkej do listopadu, ať dorovnáme průměr).
Bylo by to podle vás lepší sdružovat do měsíčních kumulativních aktualizací jako třeba MS nebo Apple (pokud se nejedná o nějaký megaprůšvih)?
Navíc ty delší intervaly si můžete naordinovat tak trochu sám. Pročíst si info ke konkrétním RHSA, zvážit jak je to pro vás akutní, a případně jet podle nějakého pevného schématu (např. každá druhá sobota v měsíci).
Automatické aktualizace (např. přes dnf-automatic) fungují dobře na balíčky s aplikacemi, pokud tam můžete udělat nějaké přirozené okno (noc, víkend) a nejdede to 24/7 bez clusteru.
U balíčků s jádrem to jde použít taky, nainstaluje se to bokem, akorát pak musíte najít vhodný okamžik na restart.
Na zjištění, jestli potřebujete restart, nebo ne, pak po aktualizaci stačí zavolat dnf needs-restarting. Je tam exit-code 0, pokud to není potřeba, takže se to dá zapracovat do skriptu, co vás třeba nějak notifikuje. Když použijete totéž s parametrem -r, tak vám to vypíše lidsky do standardního výstupu včetně balíčků, co to potřebují (jádro, libc).
Restarty samotné se dají docela hodně zrychlit např. s použitím kexec, kdy se jen natáhne poslední jádro, bez toho, aby server musel probíhat celým postem, čekal na firmwary, BMC atp. Má to nějaké limity, ale obecně to dokáže zkrátit downtime z několika minut třeba na desítky sekund u fyzických serverů.
Jinak samozřejmě na RHEL s předplatným by měl fungovat kpatch na ty kritické záplaty v jádře i bez restartu, ale zas to může mít podle situace určitá omezení, je potřeba to pořádně ozkoušet (což se samozřejmě dá i třeba s virtuály a jejich developerskou licencí).
Oracle Linux s jejich Ksplice je pak obdobné, ale je to součástí jen toho dražšího předplatného.
-
Kernel se stal svou vlastni CVE autoritou a Greg KH prirazuje CVE vsem bugum ktere backportuje.
Na LWN jsou k tomu clanky s odkazy na poprask v bugzilach protoze downstream to tezce nedava….
-
Samozrejme Greg nebackportuje buggy ale bugfixy 😀
-
Jo jasně, tahle změna s vlastní CNA pro kernel určitě proběhla, ale už na začátku roku 2024. Za minulý rok bylo v součtu za celý kernel přes 1200 číslovaných CVE.
To si nemyslím, že tohle přímo souvisí s tím nárůstem aktualizací jádra v posledních měsících, na co se ptá tazatel.
Do jedné RHSA se klidně seskupí víc řešených CVE a následně vyjde nový balíček s jádrem.
Nevím, nepátral jsem úplně přesně po mechanismu, podle kterého se určuje, v který okamžik se zveřejní balíček. Počítám, že v tom bude hrát roli závažnost problému, nutnost nějakého širšího testování atp.
Stejně to jako admin musím někdy nasadit. Ale jak jsem psal, ty important a critical věci si většinou pročítám a můžu si zvážit, jak zásadní to na konkréním systému je. Klidně to může být zásadní, ale třeba u protokolu nebo nějakého subsystému, co se na daném serveru vůbec nepoužívá.
A ano určitě záleží i na prostředí, pokud pokud má někdo systémy, co jsou pod trvalým dohledem bezpečáků a nějakého systému, co řeší jen rostoucí červená čísla na nějakém dashboardu a hlava-nehlava trvají na co nejrychlejší aktualizacích, tak prostě nezbyde, než si na to zařídit prostředky (čas, lidi, odstávky).. nebo je přesvědčit o nějaké nutné flexibilitě.
-
Haleluja! Vcera vysel dalsi rhel9 kernel (kernel-5.14.0-570.30.1.el9_6) - dalsich 10 bezpecnostnich zaplat. Jestli to tak pujde dal, tak v dohledne dobe bude vychazet deset kernelu za den :) IBM proste vi, jak na to.
-
Haleluja! Vcera vysel dalsi rhel9 kernel (kernel-5.14.0-570.30.1.el9_6) - dalsich 10 bezpecnostnich zaplat. Jestli to tak pujde dal, tak v dohledne dobe bude vychazet deset kernelu za den :) IBM proste vi, jak na to.
Vrátím se ke své otázce. Co by podle vás měl RedHat/IBM se záplatami na CVE dělat jiného než je nabídnout klientům?
Týká se vás některé z těch CVE?
-
Vrátím se ke své otázce. Co by podle vás měl RedHat/IBM se záplatami na CVE dělat jiného než je nabídnout klientům?
Meli by zkusit treba:
a) Zjistit proc se zvysuje frekvence nalezu chyb a zaridit se podle toho. Prece nebudeme za rok zaplatovat 2x tydne.
b) Domluvit s lidmi okolo kernelu neco na zpusob mrkvosoftiho patch tuesday.
(u znalcu s hlubsim vhledem by se asi nasly i dalsi napady, ale to jen hadam)
Týká se vás některé z těch CVE?
Fakt nevim, jestli se nas tyka: RDMA/mlx5: Fix page_size variable overflow (CVE-2025-22091)
Navic si nemyslim, ze bychom meli zamestnat znalce linuxiho kernelu jen proto, abychom mohli instalovat zaplatovane verze s mensi frekvenci.
Kazdopadne dik za reakci.
-
Prece nebudeme za rok zaplatovat 2x tydne.
Ale tak přece záplatujte kdy chcete, co vám v tom brání?
Jaký je rozdíl v tom, když vy patchnete jednou za měsíc - a mezitím budete mít neopravený kernel - a tím, že RHEL vývojáři budou čekat celý měsíc - a mezitím budete mít neopravený kernel.
Jedině v tom, že ti, kteří patchovat chtějí, nebudou moci.
-
Ale tak přece záplatujte kdy chcete, co vám v tom brání?
Brani mi v tom fakt, ze v okamziku zverejneni zranitelnosti ji muze zacit zneuzivat skoro kazdy jouda, takze je treba urychlene zaplatovat.
Jaký je rozdíl v tom, když vy patchnete jednou za měsíc - a mezitím budete mít neopravený kernel - a tím, že RHEL vývojáři budou čekat celý měsíc - a mezitím budete mít neopravený kernel.
Jedině v tom, že ti, kteří patchovat chtějí, nebudou moci.
Pokud se nepletu, tak u windows se zranitelnosti zverejnuji az v okamziku, kdy jsou k dispozici zaplaty.
Je treba si uvedomit, ze zranitelnosti vetsinou existuji dlouhou dobu pred zverejnenim, tudiz pozdrzeni zverejneni o par tydnu zas tak velky problem nepredstavuje. Pokud tedy ta zranitelnost uz neni aktivne zneuzivana, pak okamzite zverejneni oprav je samozrejme zcela na miste.
-
Pokud se nepletu, tak u windows se zranitelnosti zverejnuji az v okamziku, kdy jsou k dispozici zaplaty.
Embargo date je obvykle domluvené napříč produkty. Takže ve chvíli, kdy se ta informace zveřejní v CVE databázi to prostě musí RHEL vydat.
Windows specifické chyby asi mohou mít embargo dlouhé podle potřeby Microsoftu. Ale linux není jen RHEL.
-
Embargo date je obvykle domluvené napříč produkty. Takže ve chvíli, kdy se ta informace zveřejní v CVE databázi to prostě musí RHEL vydat.
Windows specifické chyby asi mohou mít embargo dlouhé podle potřeby Microsoftu. Ale linux není jen RHEL.
Proto jsem vyse psal: "Domluvit s lidmi okolo kernelu..."
Jednodussi by samozrejme bylo, kdyby se treba zjistilo, ze za narust zranitelnosti muze nejaky nedbaly vyvojar(i) a provedl by se audit jeho(jejich) kodu, nebo se mozna objevili nastroje pro mnohem efektivnejsi hledani zranitelnosti v kodu a provedl by se audit celeho kernelu temito nastroji a tim padem by se potom cetnost nalezu vratila do starych koleji.
-
Fakt bych zkusil ten Lexaurin.
-
Fakt bych zkusil ten Lexaurin.
Zkus. Kdo ti brani?
-
Fakt nevim, jestli se nas tyka: RDMA/mlx5: Fix page_size variable overflow (CVE-2025-22091)
Navic si nemyslim, ze bychom meli zamestnat znalce linuxiho kernelu jen proto, abychom mohli instalovat zaplatovane verze s mensi frekvenci.
Začaly se ty věci poctivěji evidovat jako CVE a řešit samostatně. Sleduji https://lore.kernel.org/linux-cve-announce/, je toho prostě násobně víc než vloni, kdy asi řada bezpečnostních oprav skončila jako běžná kumulovaná úprava.
Na to, abys mohl třídit opravy podle driverů nebo subsystémů, které používáš, nepotřebuješ nějak velkého znalce linuxového kernelu, potřebuješ prachobyčejného linux admina, který umí pracovat s linuxem.
Jak to děláme my? Limitně se aktualizuje vše v nějakém pravidelném intervalu (třeba 3 měsíce), ale urgentně se aktualizuje jen to, co má reálný vliv a co se používá, takže opravu RDMA/mlx5 nebudu prioritizovat na linux stroj, kde mám jen ethernet karty. Tohle rozlišování bylo potřeba dělat odjakživa, stejně tak fungujeme i na Windows, kdy se musíme probírat aktualizacemi a rozhodovat, co a jak prioritizujeme.
U těch hodně kritických zranitelností využíváme kexec pro aplikaci patche na kernel (má to samozřejmě dopad na všechny procesy, které se musí restartovat). Snaha v posledních letech se odpovědněji chovat k systémům nás postupně dovedla k tomu, že vše máme dvojmo, resp. že minimalizujeme stav, kdy máme jen jediný server s nějakou službu a vše zdvojujeme, automatizujeme, aby se mohl udělat restart bez výpadku a hlavně odzkoušet případné problémy dopředu. Virtualizace a kontejnerizace tomu jde naproti.