Byla vydána nová major verze 27.0 programovacího jazyka Erlang (Wikipedie) a související platformy OTP (Open Telecom Platform, Wikipedie). Přehled novinek v příspěvku na blogu.
Byla vydána nová verze 1.8.0 svobodného multiplatformního softwaru pro konverzi video formátů HandBrake (Wikipedie). Přehled novinek v poznámkách k vydání na GitHubu. Instalovat lze také z Flathubu.
Microsoft představil nové označení počítačů Copilot+. Dle oznámení se jedná se o počítače poskytující funkce umělé inteligence. Vedle CPU a GPU mají také NPU (Neural Processing Unit). Uvnitř představených Copilot+ notebooků běží ARM čipy Qualcomm Snapdragon X Elite nebo X Plus.
Příspěvek na blogu Codean Labs rozebírá zranitelnost CVE-2024-4367 v PDF.js, tj. mj. prohlížeči PDF souborů ve Firefoxu. Při otevření útočníkem připraveného pdf souboru může být spuštěn libovolný kód v JavaScriptu. Vyřešeno ve Firefoxu 126.
Lazygit byl vydán ve verzi 0.42.0. Jedná se o TUI (Text User Interface) nadstavbu nad gitem.
K open source herní konzole Picopad přibyla (𝕏) vylepšená verze Picopad Pro s větším displejem, lepšími tlačítky a větší baterii. Na YouTube lze zhlédnout přednášku Picopad - open source herní konzole z LinuxDays 2023.
Byla vydána (𝕏) nová major verze 17 softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech GitLab (Wikipedie). Představení nových vlastností i s náhledy a videi v oficiálním oznámení.
Sovereign Tech Fund, tj. program financování otevřeného softwaru německým ministerstvem hospodářství a ochrany klimatu, podpoří vývoj FFmpeg částkou 157 580 eur. V listopadu loňského roku podpořil GNOME částkou 1 milion eur.
24. září 2024 budou zveřejněny zdrojové kódy přehrávače Winamp.
Google Chrome 125 byl prohlášen za stabilní. Nejnovější stabilní verze 125.0.6422.60 přináší řadu oprav a vylepšení (YouTube). Podrobný přehled v poznámkách k vydání. Opraveno bylo 9 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Jako správný paranoik mám (až na /boot) šifrovaný celý disk - a taky rád používám suspend to RAM. Tady už místní paranoici asi čuchají problém - uspaný počítač je totiž snad to nejlepší, co si útočník plánující coldboot útok může přát. cryptsetup má už delší dobu funkci "luksSuspend", která klíče zahodí. Z pochopitelných důvodů to nejde jednoduše použít na připojený root. I když... Po pár hodinách hraní můžu prohlásit obligátní "jde to, ale dře to!".
Z tarballu nám vypadne jeden prográmek v C, dva shell skripty a jeden patch. Celé představení se spouští skriptem "cryptsleep", ve kterém je zároveň i pár konfiguračních voleb (já vím, /etc...):
cryptsleep-bin je bastl v C, který: změní terminál na vybraný, přesune /proc, /sys a /dev do ramfs, chrootne do ramfs, v chrootu spustí cryptsleep-script a přesune filesystémy zase zpátky.
cryptsleep-script zavolá luksSuspend, uspí systém do RAM, po probuzení si řekne o heslo a zavolá luksResume. V tomhle skriptu je potřeba upravit název pod kterým máme v device mapperu root!
Instalace by měla být jednoduchá - upravit cryptsleep-script a cryptsleep, zkompilovat cryptsleep-bin: gcc cryptsleep.c -o cryptsleep-bin, opatchovat a zkompilovat jádro. cryptsleep-script a cryptsleep-bin nakopírovat do $LIBDIR.
Ve chvíli kdy zavoláme luksSuspend dojde ke smazání šifrovacích klíčů k disku a jakákoliv disková operace se zablokuje. Co se stane s jádrem které chytře zavolá před uspáním sync() je asi jasné. Pro jistotu se sync() volá i těsně před spuštěním skriptu z cryptsetup-bin. Druhý problém je v tom, že jakmile se zavolá luksSuspend začnou všechny procesy sahající na disk tuhnout ve stavu "Disk wait". A kernel před suspendem volá freeze na jednotlivé procesy - a pokud některý čeká na IO je zle. Moc jsem nevěděl co s tím, zkusil jsem mrazák vyhodit a překvapivě to funguje (to neznamená, že vám to fungovat bude taky!). Jestli to budete chtít taky zkusit, hodně štěstí!
Tiskni Sdílej:
Suspend nepoužívám, takže ani moc neznám, ale pokud vím, tak jádro normální boot a resume rozlišuje pomocí signatury ve swapu. Nedalo by se prvně nabootovat jen do initarmfs, tam se zeptat na heslo a pak přes kexec předat heslo třeba přes /proc/cmdline novému jádru s podporou uspávání? (Nebo složitěji přes reservovanou fyzickou paměť, protože u kexecu do paměti BIOS nešahá.)
Ale i myšlenka plně jaderné implementace není špatná. Jaderná správa klíčů umí klíče zašifrovat a zase odšifrovat a interaktivní jádro už stejně je (vga=ask).
Každopádně jsem viděl, že Fedora má resume do šifrovaného rootfs nějak vyřešený. Aspoň se to tak tváří.
Tím pádem stačí vzít paměť, stříknout dusík, přendat do jiného počítače a zkopírovat si ji. Velmi jednoduše se tak dostane kdokoliv dostatečně šikovný ke všemu, co zrovna běží, včetně klíčů od disku.Opravdu bych chtěl vidět tu jednoduchou demonstraci... Kdy na to máte po neděli čas? Počítám max. s půlhodinkou, je to přece velmi jednoduché.
a co tahle situace: utocnik si zkopiruje tvuh hdd (zasifrovany) a upravi boot aby mu po zadani hesla to heslo posal. Ty zadas heslo, system nastartuje a detekuje ze se neco zmenilo. Utocnik ale uz ma data i heslo...Data má, heslo nemá, síť se spouští (a kabel připojuji/vypínám RF kill) až po kontrole :)
Kazdopadne je pravda ze s fyzickym pristupem muze udelat i dalsi veci, ktery by nebylo tak snadny detekovat.Jo. Nehlídaný fyzický přístup = konečná. Ono teda vzato do důsledků, člověk by neměl věřit ani prodejci, že od něj dostává čistý HW. Na nějakou práci s extra citlivými daty bych si pořídil asi RapsberryPi, BeagleBoard, Pandaboard, kde člověk může zkontrolovat každý čip (ale zase, ten čip může být napíchnutý aby ukládal hesla/poskytnul backdoor atd. už z výroby). Akorát tam pořád jsou nějaké closed source části.
/lib/cryptsetup/scripts/decrypt_derived
jako keyscript
pro šifrovaný swap. Při zapnutí po hibernaci se to zeptá na heslo pro šifrovaný root a je vyřízeno.
/
s btrfs
na LUKS
) nedělal zbytečně.