Společnost comma.ai po třech letech od vydání verze 0.9 vydala novou verzi 0.10 open source pokročilého asistenčního systému pro řidiče openpilot (Wikipedie). Zdrojové kódy jsou k dispozici na GitHubu.
Ubuntu nově pro testování nových verzí vydává měsíční snapshoty. Dnes vyšel 4. snapshot Ubuntu 25.10 (Questing Quokka).
Řada vestavěných počítačových desek a vývojových platforem NVIDIA Jetson se rozrostla o NVIDIA Jetson Thor. Ve srovnání se svým předchůdcem NVIDIA Jetson Orin nabízí 7,5krát vyšší výpočetní výkon umělé inteligence a 3,5krát vyšší energetickou účinnost. Softwarový stack NVIDIA JetPack 7 je založen na Ubuntu 24.04 LTS.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) spolu s NSA a dalšími americkými úřady upozorňuje (en) na čínského aktéra Salt Typhoon, který kompromituje sítě po celém světě.
Společnost Framework Computer představila (YouTube) nový výkonnější Framework Laptop 16. Rozhodnou se lze například pro procesor Ryzen AI 9 HX 370 a grafickou kartu NVIDIA GeForce RTX 5070.
Google oznamuje, že na „certifikovaných“ zařízeních s Androidem omezí instalaci aplikací (včetně „sideloadingu“) tak, že bude vyžadovat, aby aplikace byly podepsány centrálně registrovanými vývojáři s ověřenou identitou. Tato politika bude implementována během roku 2026 ve vybraných zemích (jihovýchodní Asie, Brazílie) a od roku 2027 celosvětově.
Byla vydána nová verze 21.1.0, tj. první stabilní verze z nové řady 21.1.x, překladačové infrastruktury LLVM (Wikipedie). Přehled novinek v poznámkách k vydání: LLVM, Clang, LLD, Extra Clang Tools a Libc++.
Alyssa Anne Rosenzweig v příspěvku na svém blogu oznámila, že opustila Asahi Linux a nastoupila do Intelu. Místo Apple M1 a M2 se bude věnovat architektuře Intel Xe-HPG.
EU chce (pořád) skenovat soukromé zprávy a fotografie. Návrh "Chat Control" by nařídil skenování všech soukromých digitálních komunikací, včetně šifrovaných zpráv a fotografií.
Byly publikovány fotografie a všechny videozáznamy z Python konference PyCon US 2025 proběhlé v květnu.
Ahoj,
mám funkční Full Disk Encryption (LVM on LUKS) kromě /boot (samostatný nešifrovaný oddíl), odemyká se heslem při startu počítače.
Jedná se o server běžící neustále, zadávání hesla je problém. Rád bych se vyhnul metodám:
Studuji tedy využití TPM 1.2 pro uložení klíčů. Pokud to dobře chápu, tak možnosti jsou:
U obou jsou potíže s aktualizací bootloaderu, kernelu a initramfs (používám Arch Linux, na žádnou automatizaci jsem nenarazil).
Neexistují ještě další postupy? Čistě paranoidně bych byl raději, kdyby ověření integrity proběhlo už v boot loaderu a kernel + initramfs by se načítal až z šifrovaného oddílu.
Řešení dotazu:
Mám pocit, že Grub2 podporuje jen TPM2.
Psaní vlastního háčku do initramfs (pokud to už někdo neudělal), je nutnost. Ale v tom háčku vy žádnou integritu neměříte. To za vás udělá Grub. To, co v háčku budete dělat, že
Já osobně používám druhou možnost, protože je jednodušší.
Dejte si ale pozor na to, kdo má přístup k TPM z korektně zavedeného systému. Registry TPM v Linuxu může číst kdokoliv, stačí ale chmod 0400 na patřičné soubory v sysfs. Jestli dešifrovat může kdokoliv, to netuším. Taky v druhém případě si dejte pozor, aby alespoň jeden registr měřil úplně vše od firmwaru až po initramfs. Jinak by útočník mohl pozměnit initramfs, a heslo k LUKS zkonstruovat jako zřetězení registrů, které initramfs neměří, a vypočítaných hodnot registrů, které initramfs měří, ale je znám jejich inicializační vektor.
Ano, aktualizace měřených souborů je problém. Jakákoliv jejich změna vede ke znevěrohodnění systému a systém nenastartuje, protože nedokáže dešifrovat kořenový systém. To je ale zároveň požadovaná vlastnost.
Já jádro měním vždy, když jsem fyzicky u stroje. V initramfs mám kód, který při selhání připojení kořene se zeptá na jiné heslo a po jeho zadání mi dá shell. Jiné heslo je v initramfs uložené jako otisk, takže přečtení initramfs ho neprozradí. Z shellu prostě odemknu LUKS dalším heslem, nechám boot doběhnout a po otestování nového jádra zaktualizuji slot v LUKS, který se pomocí TPM.
Díky za užitečné poznámky. Jen doplním:
Dále:
V initramfs mám kód, který při selhání připojení kořene se zeptá na jiné heslo a po jeho zadání mi dá shell. Jiné heslo je v initramfs uložené jako otisk, takže přečtení initramfs ho neprozradí. Z shellu prostě odemknu LUKS dalším heslem, nechám boot doběhnout a po otestování nového jádra zaktualizuji slot v LUKS,
Není to zbytečně komplikované?
Mám v plánu přidat do initramfs jen jeden hook - na přečtení klíče z TPM pro LUKS a jeho uložení do souboru. Existující hook 'sd-encrypt' podporuje otevření LUKS oddílu s paramatrem key-file, pokud klíč nenajde (nebo otevření selže), standardně se optá na heslo pro crypttab (na konsoli, vyzkoušeno). Tuším, že podobně by se mohl chovat i původní hook 'encrypt' (prostřednictvím konfigurace v /etc/crypttab).
A ohledně aktualizace:
- buďto si necháte pomocí TPM dešifrovat heslo k LUKS, přičemž TPM to provede, pouze když obsah registrů< TPM bude stejný jako při zašifrování hesla,
Ten extra restart počítače při změně grub/kernel/... pro uložení klíče do TPM (seal) dost komplikuje automatizaci. Jedině, že bych jiný, dočasný, LUKS klíč uložil natvrdo do initramfs pro první restart a následně jej smazal a pro další restarty by se opět použil ten vytažený z TPM.
- nebo použijete obsah registrů PCR jako heslo k LUKS.
Lze dopředu zjistit, jaké budou hodnoty PCR, aniž bych restartoval počítač? (Po aktualizaci kernelu atd..) Tj. mohl bych vyjít z předpokladu že např. PCR 00 - 03 zůstane beze změny, ostatní až po PCR 09 už by nějaký prográmek mohl přepočítat. Tyto hodnoty bych pak uložil jako aktualizovaný klíč pro LUKS.
Tak na toto si asi odpovím sám: nástroje nejsou, mohl bych si to sám naskriptovat podle measurement logu Grub2 (ale dle bug reportů se neloguje vše) a modlit se, že Grub2 nezmění metodiku. Asi bude snazší upgradovat jednou za čas, abych nemusel monitor a klávesnici nosit do sklepa moc často kvůli heslu na konsoli
Jenom doplním, že nejspíše zvolím variantu klíče uloženého v NVRAM.
Mělo by to výhodu pro aktualizaci:
To nestačí. Ještě musí přijít člověk a to heslo tam naťukat. Což člověk znalý neudělá, protože ví, že kromě poruchy to může být útok.
Spíše mi vysvětlete, jak by mě měl ochránit secure boot. Jako útočník přidám před váš postup jeden krok: Vypnu secure boot v nastavení firmwaru.
A co když někdo rozebere stroj (jumper, baterie)?
Takže útočník se na disk nedostane a majitel, pokud má zazálohované klíče ano?
Slyšel jsem o nb (HP), u kterého prý nepomůže ani vytažení baterie. Pokud je firmware zaheslovaný, tak to prý nepomůže. Ale jak tu psal k3dAR. Stále se dá přeflešnout čip.
Takže útočník se na disk nedostane a majitel, pokud má zazálohované klíče ano?V ideálním případě by to tak mělo být. Otázkou je, jak to je skutečně implementované a zda tam nejsou chyby.
Stále se dá přeflešnout čip.S tím už toho moc nenaděláš. Také tím nevyřešíš obranu proti cold-boot útoku. Na to by byl potřeba nějaký destrukční mechanismus při fyzickém otevření počítače. Na cold-boot ještě pomůžou paměti připájené na desce, ale proti přeflashování firmwaru nenaděláš nic než to nějak pořešit fyzicky.
V ideálním případě by to tak mělo být. Otázkou je, jak to je skutečně implementované a zda tam nejsou chyby.
Tak pokud to bude fungovat, tak je to dobré.
Já naneštěstí na obou strojích nemám TPM, ale jen PTT. Takže kdybych si nastavil sicherboot a někdo by pak vytáhnul baterii z MB, bude to potom fungovat stejně jako s TPM?
TPM měří i kód firmwaru. Přeprogramování firmwaru tedy neunikne pozornosti.
Vyvstává otázka, co kód, který měří firmware. Ten by měl být skutečně v nepřepsatelné paměti. Je to ten kód, který startuje procesor a zavádí firmware, když ještě není nakonfigurovaná fyzická paměť. Kdysi tomu tak skutečně bylo. Nicméně jak je tohle implementované na dnešním překomplikovaném hardwaru, těžko říci. Poslední procesory implementují TPM samy, protože jej emulují v servisním procesoru velkého CPU (na Intelu to je nějaký ARM).
Tiskni
Sdílej: