Názory k článku
ModuleJail zakáže nepoužívané moduly kvůli bezpečnosti
-
BuldrZlatý podporovatelNávrat zpět ke striktnímu pesimistickému přístupu, kdy v systému bude pouze nezbytně nutné, vše nepotřebné vyhozeno, zakázáno a potřebné se pozavírá do Jails.
Tradiční přístup má něco do sebe :-)
-
Michal SmržStříbrný podporovatelhttps://github.com/jnuyens/modulejail/blob/master/modulejail
/proc/modules a nějaké base_modules konstanty
-
Michal ŠmucrBronzový podporovatelNo vida, zrovna minulý týden jsem o něčem podobném přemýšlel.
Ano jde k tomu přistoupit tak, jak tu myslím nedávno zmiňoval Wasper, který si pořád sestavuje vlastní jádra. Což určitě zmenšuje attack surface, ale je to v mnoha situacích obtížně realizovatelné. Resp. za mě se to vyplatí jen pro specifická použití (firewally, embedded), pár osobních strojů nebo naopak zas situace třeba s velkou flotilou identických serverů, co mají jasný účel a stejné použití. Takže se dá odůvodnit ta časová investice, kdy se tomu bude někdo trvale věnovat, automatizovat sestavování, balíčkování, podepisování... testovat to atd.
Blokování modulů a používání distribučních jader mi přijde mnohem schůdnější cesta pro většinu uživatelů, co to chtějí případně proaktivně řešit nad rámec normálních aktualizací.
A sice ano, už dlouho existují hardening nástroje, co s blokovaním částečně pomáhají.. (např. parsovat výstupy s Lynisu apod., vytvořit stuby pro vkládání do sysctl.conf a modprobe.conf), nebo jsou veřejně spravované a dostupné nějaké hardening role do Ansible.. ale to všechno to funguje spíš obráceně. Blokuje a vypíná to známe problematické věci a fíčury.
Naopak tohle by dynamicky udělalo blokování všeho, co není na whitelistu nebo aktivně používané.
Ale samozřejmě i v tomhle případě to nemusí být vždy úplně přímočaré a také s tím může být poměrně dost práce (byť pořád řádově míň v porovnání s těmi vlastními jádry). -
Pokud vite presne jaky hw mate v pocitaci.
Ja to snad nekdy uz od amd k6-3 ci dejme tomu sempron fakt uplne nevim.
Jaky mate I2C/SPI cip pro data ze senzoru? Ktery radic disku vc varianty? Ktery quirk patch je treba aby vam spravne fungoval power management?19. 5. 2026, 12:37 editováno autorem komentáře
-
Michal ŠmucrBronzový podporovatel
Ehm ... takze bude potreba hacknou blokovac modulu, ... 3, 2, 1 ... hotovo.
"Blokovač" sám aktivně nic neblokuje, vyrobí jen konfigurační soubory, co se dál používají úplně standardně (modprobe, sysctl, parametry startu jádra). Pokud někdo obejde zabezpečení těchhle nástrojů, mechanismů a bude to moct ovládat např. jako standardní uživatel, tak máme všichni ještě řádově větší problém.
Nebylo by mnohem lepsi aby tam proste vubec nebyly?
Bylo i nebylo, už jsem to psal výše. Jestli to chcete řešit, tak je trochu rozdíl mezi tím tohle dělat např. na svém počítači a notebooku s jednou distribucí, kde máte vždycky celý toolchain a můžete si s tím blbnout do aleluja, vracet se, když se něco nepovede atp., a pak třeba na desítkách serverů a stanic s nějakými okny pro údržbu, kde máte různé kombinace distribucí, jejich verzí podle aplikací, použití (bare metal, virtuály) a potřebných modulů..
Postavíte si na každou používanou distribuci nějaký specifický build host..? Uděláte si automatizaci, abyste mohl snadno rebuildovat s vašimi konfigy upstream verze do balíčků? Budete to mít podepsané pro secure boot a všude správné MOK v UEFI?
Zvládnete registrovat, jestli se třeba v těch aktualizovaných upstream jádrech nezměnily nějaké volby nebo chování (i na LTS jádrech můžete mít nějaké backporty, když se mění minor verze distribuce), budete to testovat?
Když bude potřeba změna konfigurace (nevím, budete např. chtít rozběhnout ad-hoc wireguard tunel), tak půjdete upravovat konfig a sestavovat nové jádro?Oproti tomu ty jednoduše verzovatelné soubory, co se dají snadno upravovat a aplikovat, jsou prakticky mnohem schůdnější.
