Vývojáři webového prohlížeče Ladybird dnes oznámili, že mění způsob vývoje. S blížícím se vydáním alfa verze přestávají přijímat veřejné pull requesty. Všechny otevřené veřejné pull requesty budou uzavřeny. Tým nedokáže garantovat bezpečnost AI generovaných pull requestů.
OpenLogi (GitHub) je open source náhrada aplikace Logi Options+ pro přizpůsobení myší od společnosti Logitech. Zatím běží pouze na macOS.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za květen (YouTube).
Úřad pro ochranu osobních údajů řeší desítky stížností na jednotné měsíční hlášení zaměstnavatele, které stát spustil počátkem dubna. Systém, jenž má firmám odlehčit od desítek formulářů, nejenže výrazně zatížil jejich účetní oddělení, ale docházelo v něm i k únikům osobních dat zaměstnanců k firmám, kde nepracovali. Podle ministerstva práce a sociálních věcí stála za problémem technická chyba. „Incident se týkal několika stovek
… více »Byla vydána (𝕏, Bluesky) nová verze 22.0.0 open source webového aplikačního frameworku Angular (Wikipedie). Přehled novinek v příspěvku na blogu.
Vim Classic byl vydán ve verzi 8.3. Drew DeVault oznámil tento fork editoru Vim (verze 8.2.0148, tj. těsně před zavedením Vim9 skriptování) v březnu letošního roku. Důvodem forku bylo, že vývojáři editorů Vim a Neovim začali při vývoji využívat LLM.
Open source konference DevConf.CZ 2026 proběhne 18. a 19. června v Brně na FIT VUT. Publikován byl program a spuštěna byla registrace.
Společnost JetBrains uvolnila verzi 2 svého open-source velkého jazykového modelu (LLM) pro vývojáře Mellum.
Probíhá konference Microsoft Build 2026. Microsoft představuje své novinky: kvantový čip Majorana 2, Surface Laptop Ultra a Surface RTX Spark Dev Box s NVIDIA RTX Spark, Intelligent Terminal, Coreutils for Windows (fork Rust Coreutils), AI modely MAI, AI agenta Scout, platformu pro agent-first zařízení Project Solara, …
Google Chrome 149 byl prohlášen za stabilní. Nejnovější stabilní verze 149.0.7827.53 přináší řadu novinek. Podrobný přehled v poznámkách k vydání. Vylepšeny byly také nástroje pro vývojáře.
Omezit počet přihlášení umí kdejaká čipová karta. Na to TPM netřeba.
Síla TPM je v tom, že má vlastní sériové číslo a vlastní tajný klíč. Klíč nelze přečíst, jen vygenerovat či zapsat. Kombinací těchto dvou hodnot vzniká jedinečný a nereplikovatelný iniciační vektor pro hashovací funkci. Ta potom řetězově hashuje spouštěný kód (firmware, zavadeč, jádro, initram disk atd.), čímž v kterékoliv fázi startu systému máme otisk kódu, který byl až dosud vykonán. Tento otisk pak funguje jako důkaz, že systém je v požadovaném (= nenapadnutém) stavu.
Když budete otisk držet v tajnosti, tak ho můžete použít jako heslo pro rozšifrování blokového zařízení.
Nebo můžete využít další funkci TPM, a to že na hodnotu otisku navážete vydání dalšího soukromého klíče z TPM. A blokové zařízení dešifrovat až tímto dalším soukromým klíčem.
Příště by to chtělo méně arogance a více studia.
To by mohlo fungovat, budou-li tím klíčem šifrovány všechny klíčové části systému, které nejsou hashovány (v opačném případě vyndám kartu, upravím na ní třeba /etc/passwd, vrátím, naloguji se jako root, vytáhnu klíč z RAM, a TPM mě už nezajímá).
Ano. Klasický postup je mít vše kromě jádra a initramdisku v šifrovaném blokovém zařízení a v něm LVM a v něm všechny souborové a swapovací systémy. Tohle umožňuje zajistit integritu i utajení.
Jiný postup je, když stačí integrita. Pak místo šifrování se použije IMA na veškerý kód (jaderné moduly, spustitelné programy a dynamické knihovny) nebo i data (konfigurační soubory). V podstatě se posbírají otisky všech souborů a proženou se TPM. Při přístupu k souborům se pak kontroluje, že se jejich otisk nezměnil.
Tedy pořád zbývají útoky na běžící systém, ale ty jsou těžší.
Samozřejmě. Před chybou v ověřeném kódu (jako když na Mac OS stačilo dvakrát zadat prázdné heslo pro roota) vás neochrání nic.
Ale tohle bude fungovat jen se secure bootem. Pokud by systém nabootoval jakoukoliv kartu, půjde tam dát program co tím TPM hashem prožene FW plus původní bootloader/kernel/initrd, a vytáhne soukromý klíč k těm datům.
Nikoliv. Když systém nabootuje z jiné karty, tak se do TPM pošle jiný obsah zavaděče atd. a tudíž hash bude jiný.
Je třeba si uvědomit, že do TPM se posílá kód, který teprve bude spuštěn, a posílá jej tam kód, který již byl takto do TPM odeslán. Čili aby kód mohl podvádět (posílat do TPM jiný obsah, než který hodlá spustit), musel by se takový kód lišit od původního poctivého kódu. Jenže pokud takový kód běží, znamená to, že jeho odlišnost již změnila otisk v TPM ještě před tím, než nepoctivý kód byl spuštěn a mohl začít podvádět.
To samozřejmě přináší otázku, jak je to s úplně prvním kódem, který se posílá do TPM. Tedy s firmware. Správná implementace je, že při zapnutí počítače existuje neměnitelný kód (v ROM), který nejprve odešle obsah firmware do TPM a pak teprve spustí firmware.
Secure boot má podobný ale horší problém: Kdo ověřuje podpis firmwaru a jak má vědět, že kořenový klíč nebyl podvržen? Vzhledem k tomu, že kořenový klíč je možné importovat, obávám se, že secure boot je ve skutečnosti velká habaďůra. Je ještě možnost, že secure boot má dva kořenové klíče. Jeden importovatelný uživatelem a jeden neměnný. Ten neměnný se použije právě pro ověřený firmwaru. Jenže když jsou dva nezávislé kořeny, tak mezi nimi nemůže existovat důvěra a tudíž secure boot opět stojí na vodě. Aby secure boot byl důvěryhodný, kořenový klíč by musel být jen jeden a neměnitelný a nesměl by být vypnutelný.
BIOS je dneska software jako každý jiný. Velký, modulární, plný chyb a aktualizovatelný. Samozřejmě že ověřování sám sebou není bezpečné.
Bezpečná metoda je mít neměnitelný zavaděč BIOSu. Protože jej nelze měnit, můžeme mu věřit. Ten může poslat BIOS do TPM, či může ověřit jeho podpis proti klíči, který má neměnitelný kód v sobě.
Takový neměnitelný kód opravdu existuje a používá se pro spuštění částí BIOSu, které inicializují plně procesor a chipset. Nicméně zdá se, že výrobci jej nepoužívají jako kořen důvěry.
Třeba IBM v OpenPower strojích má v secure boot dva kořenové klíče. Jedním ověřuje firmware a druhý si může uživatel změnit pro ověření operačního systému. Kořenové klíče jsou uloženy v paměti, do které lze nové kořenové klíče nahrát pouze skrze běžící firmware, který si již vynutí, aby nový firmwarový kořen byl podepsán starým kořenem (zrovna tak jako aktualizace firmwaru). (A uživatelský kořen pouze po předložení hesla, jehož otisk je pravděpodobně uložen v téže paměti). Čili se vychází z předpokladu, že první firmware neobsahuje žádnou bezpečnostní chybu. (Nějak takto byla zabezpečena PlayStation proti instalaci Linuxu a nějak tak si Microsoft představoval secure boot na zábavní technice s armovými procesory.)
Ve světě PC UEFI se TPM zapíná až ve fázi Pre EFI Inicialization. Sice UEFI se do TPM pošle celé, ale ten první neměnný kód, který provádí předešlou Security fázi, to nedělá. Asi se vsází na stejnou kartu jako u OpenPower – že UEFI lze aktualizovat jen z běžícího UEFI.
Přijde mi to docela smutné, protože dobře udělané TPM umožňuje ochránit systém před off-line útokem. Secure boot to nedokáže, protože stačí restovat heslo do setupu, což standardní podporovaná operace.
11.12.2017 21:12
pVit | skóre: 11
9.12.2017 18:23
k3dAR | skóre: 63
11.12.2017 21:08
pVit | skóre: 11
(Vypadá to na nejspolehlivější způsob)
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz