Google Chrome 139 byl prohlášen za stabilní. Nejnovější stabilní verze 139.0.7258.66 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 12 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře. S verzí 139 přestal být podporován Android 8.0 (Oreo) a Android 9.0 (Pie).
Společnost JetBrains se stala platinovým sponzorem multiplatformního open source herního enginu Godot. K vývoji her lze používat Rider for Godot. Zdarma pro nekomerční účely.
Byla vydána verze 9.0 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Verze 9.0 je založena na Debianu 13 Trixie. Přehled novinek v poznámkách k vydání a informačním videu.
Operátor O2 dává všem svým zákazníkům s mobilními službami poukaz v hodnotě 300 Kč na nákup telefonu nebo příslušenství jako omluvu za pondělní zhoršenou dostupnost služeb.
Společnost NVIDIA vydala verzi 13.0 toolkitu CUDA (Wikipedie) umožňujícího vývoj aplikací běžících na jejich grafických kartách. Přehled novinek v poznámkách k vydání.
Byly vyhlášeni vítězové a zveřejněny vítězné zdrojové kódy (YouTube, GitHub) již 28. ročníku soutěže International Obfuscated C Code Contest (IOCCC), tj. soutěže o nejnepřehlednější (nejobfuskovanější) zdrojový kód v jazyce C.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za červenec (YouTube).
Konečně se ochladilo, možná i díky tomu přestaly na chvíli padat rakety jako přezrálé hrušky, díky čemuž se na Virtuální Bastlírně dostane i na jiná, přízemnější témata. Pokud si chcete jako každý měsíc popovídat s dalšími bastlíři, techniky, vědci a profesory u virtuálního pokecu u piva, Virtuální Bastlírna je tu pro Vás.
Ještě před ochlazením se drát na vedení V411 roztáhl o 17 metrů (přesné číslo není známé, ale drát nepřežil) a způsobil tak… více »Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
PixiEditor byl vydán ve verzi 2.0. Jedná se o multiplatformní univerzální all-in-one 2D grafický editor. Zvládne rastrovou i vektorovou grafiku, pixel art, k tomu animace a efekty pomocí uzlového grafu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí GNU LGPL 3.0.
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: