Konferenci jako každý rok zahájil hlavní organizátor Petr Hodač, který zmínil, že jde o desátý ročník, na kterém jsme se sešli fyzicky. Když odečteme covidové roky, jsme tu podesáté.
LinuxDays mohou být jen tak dobré, jak je dobrá česká komunita. Když vám tu něco chybí, máte jedinou možnost: můžete poradit nebo se přihlásit a udělat to sami. Jen tak samo se to nestane.
Akci pořádají dobrovolníci ve volném čase.
Lukáš Bařinka: Coreutils a základy skriptování v shellu
Proč se vlastně máme zabývat skriptováním? Platí poučka: pokud to děláš podruhé, pravděpodobně to neděláš naposled.
U počítačů dává smysl věci automatizovat, aby se opakující se činnosti mohly dělat samy. Když to dělá věci za vás, vy se tím zabývat nemusíte.
Shell umožňuje psát příkazy na příkazovou řádku nebo je možné je zapsat do souboru a ty se pak postupně provedou samy.
Skriptování stojí na unixové filosofii „rozděl a panuj“, která říká, že s menšími problémy jsme schopni se vypořádat snáz než s velkými problémy. Kód by měl sám sloužit jako dokumentace, jsme schopni podle něj obvykle vše pochopit.
Pro rozdělení problému do menších kroků potřebujeme nějaké jednoduché nástroje – k tomu slouží coreutils. Musíme být schopni je nějak propojovat do složitějších celků.
Aby si nástroje rozuměly, potřebují mít nějaké společné rozhraní – tím je obyčejný text. S ním se vám bude dobře pracovat.
Je možné to připodobnit ke kostičkám Lega, které jsou velmi jednoduché, ale lze z nich postavit velmi zajímavé věci.
Existuje několik různých sad základních nástrojů, které se liší podle svého účelu. Máme k dispozici fileutils pro práci se soubory, textutils pro zpracování textu a shellutils pro podporu pokročilejšího programování. Když máte tyhle základní kameny, bude váš svět vypadat podle toho, co z nich dokážete poskládat.
Příkaz spustíme prostě tak, že napíšeme jeho jméno. Shell najde první odpovídající soubor v proměnné PATH a ten se pokusí spustit.
Můžeme přidat nějaké přepínače, které říkají, jak by měl program upravit svou činnost. Pomocí argumentů pak určujeme, s čím budeme pracovat.
Některé příkazy jsou vestavěné, protože by to bez nich nefungovalo. Příkladem takového příkazu je pwd, který se ale zároveň může nacházet na disku jako samostatný program. Pokud k němu uvedete cestu, můžete spustit konkrétní program v konkrétní cestě.
Program je možné si představit jako krabičku, která má nějaké vstupy a výstupy. Máme je očíslované a můžeme pak říct, který vstup a výstup chceme používat.
Standardní vstup má číslo 0, standardní výstup má 1 a chybový výstup 2. Jejich nastavení se dědí od rodiče a obvykle je vše nastaveno směrem na aktuální terminál. Pomocí špičatých závorek pak můžeme jako vstup či výstup použít soubor. Pomocí znaku „roury“ můžeme propojovat vstupy a výstupy jednotlivých příkazů.
Subshell, neboli substituce příkazů, slouží ke spuštění příkazu a následné nahrazení za výstup tohoto příkazu. K tomu slouží konstrukce $(), na jejíž místo se vloží výstup po spuštění příkazu. Tyto konstrukce je možné do sebe vnořovat, ale vznikne tím spousta závorek.
Můžeme si to ale zpřehlednit pomocí proměnných, které se vytvoří prostým zapsáním názvu proměnné a za ním rovná se.
Příkazy je možné spouštět také podmíněně. Je možné je jednoduše nezávisle řetězit pomocí středníku, ale následující příkazy se tím spouštějí bez ohledu na úspěch předchozích kroků. Pokud chceme následující příkaz spustit po úspěšném provedení toho předchozího, použijeme dva ampersandy &&. Pokud chceme naopak reagovat na neúspěch, potřebujeme dvě roury ||.
Pro vytvoření skriptu stačí příkazy zapsat do jednoho textového souboru, každý příkaz na samostatný řádek. Poté stačí pomocí příkazu chmod nastavit souboru právo ke spouštění a pak je možné skript spustit.
Jan Dušátko, Jan Kopřiva: Podvodné zprávy, phishing, spam a ochrana proti zneužití e-mailu
E-mail je tu s námi velmi dlouho, je to stará, ale velmi důležitá technologie. Stále jde o velmi využívanou technologii a o dominantní komunikační kanál.
Od počátku v něm chyběly bezpečnostní mechanismy, které se postupně přidávaly a přidávají. V kontextu bezpečnosti nás v první řadě zajímá, zda jde o důležitou zprávu či o spam. Na toto nám neumí stroj definitivně odpovědět, protože pro někoho je stejná zpráva zajímavá a pro jiného ne.
Filtrování vždy závisí na tom, jak příjemce vnímá dané zprávy. Jde vlastně o akceptovanou formu cenzury.
Jde o elektronické zprávy obsahující hlavičku a tělo samotného e-mailu. Pokud nepoužijeme žádný dodatečný mechanismus, posíláme obsah v čistém textu.
Z tohoto pohledu jde spíš o korespondenční lístek.
Pro zajištění bezpečnosti je potřeba, aby správce systémů nastavoval pravidla pro odesílání pošty. Nesmí se stát, aby si uživatelé mohli posílat cokoliv komukoliv.
Bezpečnost vyžaduje standardy a dobrou odbornou praxi. Standardy vytváří například nezisková organizace IETF, ale velké organizace mají často tendenci standardy nedodržovat. Google a Yahoo oznámily vlastní pravidla, ke kterým se postupně připojují další společnosti jako Apple, Meta, Microsoft a další.
Podle nich je třeba mít nejen platné záznamy v DNS, ale také je vynucováno použití SPF, DKIM a DMARC.
Tyto technologie se snaží garantovat autenticitu odesílaného e-mailu. Základní formou ověření jsou reverzní záznamy, které propojují provozovatelé domény a autonomního systému. Pokud máme správně nastavené reverzní záznamy, máme zajištěnou informaci o tom, že na dané adrese má běžet server pro odesílání pošty.
Abychom mohli explicitně říct, které servery mají za některou doménu oprávnění odesílat poštu, nastavíme v DNS záznam SPF. V malé organizaci to nastavíme hned, velkému korporátu to může trvat léta.
Pro základní potvrzení legitimity e-mailu slouží technologie DKIM, který do zprávy přidává elektronický podpis serveru. DMARC umožňuje nejen stanovit politiky pro přijímání pošty, ale zároveň umožňuje získat zpětnou vazbu o zpracování e-mailu.
Pokud používáme DMARC, můžeme nasadit BIMI. Tohle vymyslel někdo, kdo chtěl dostat bezpečnost e-mailů do firem.
Umožňuje totiž vedle e-mailové adresy ukázat také firemní logo. Pro nás techniky je to zbytečnost, ale marketingově to je velmi zajímavé.
E-mail používá čistě textový protokol, který nechrání před útoky Man-in-the-middle. I když poštu posílám nějakým šifrovaným tunelem, nemáme jistotu, že ten tunel je legitimní.
Proto se musíme zabývat také transportní bezpečností. K tomu slouží například mechanismy MTA-STS a DANE TLSA, které umožňují ověření a zajištění bezpečného kanálu. Bohužel DANE vyžaduje nasazení DNSSEC, bez něj nedává smysl.
Od e-mailu vyžadujeme také spolehlivost, takže potřebujeme mít nějakou zpětnou vazbu o tom, jak doručení dopadlo. Je třeba sledovat stavové kódy v bounces, abychom věděli, zda vše dopadlo dobře nebo proč se něco nepovedlo. U mnoha dalších technologií je možné signalizovat, jak by nám naši partneři měli posílat informace o tom, co se děje.
V doméně .CZ má přibližně jen třetina domén nasazený alespoň nejjednodušší mechanismus SPF. Postupně to roste, ale velmi pomalu. Na sto procent se dostaneme asi za dvacet let.
S implementací DMARC je to ještě horší, tam nám to současným tempem zabere asi sto let.
NÚKIB už před třemi lety vydal pravidla pro nastavení e-mailových služeb. Zhruba čtvrtina státních institucí nebyla schopná zavést ani SPF. Situace s DMARC je strašná, ale tady je výhoda v dědičnosti, takže situace se zlepšuje.
Bohužel ani doména gov.cz ještě nemá nastaven DMARC. Pokud vám něco přijde přímo z domény gov.cz, já bych tomu příliš nevěřil.
Tohle je situace ve státní správě, ale ani mimo ni není situace vždy dobrá. V oblasti průmyslu je situace ještě daleko horší.
Při stavbě vlastního e-mailového řešení je velmi špatným nápadem vynalézat kolo a vymýšlet vlastní standardy. Nedělejte to, ani když jste Microsoft nebo Google.
Neměli byste také zneužívat vyhrazené standardní e-mailové adresy, nechávat nechráněný e-mailový server jako open relay a podepisovat e-maily bez uvedení časové značky. V takovém případě může útočník posílat zachycený e-mail stále dokola.
V případě nových domén je nutné před použitím doménu „zahřát“. Dozrání nové domény trvá několik týdnů, do té doby je doména považována za nedůvěryhodnou. Existují firmy, které se na to zaměřují. Pokud začnete rovnou posílat z nové domény spoustu e-mailů, budete mít problém.
Jiří Eischmann: Fedora Asahi Remix: Linux na Apple siliconu
Apple přišel před několika lety s novými čipsety určenými pro notebooky, které jsou postaveny na 64bitové architektuře ARM. Linuxová komunita to nenechala být a vznikl projekt Asahi Linux.
Cílem je přinést Linux na tento nový hardware. Někteří lidé na tom dělají i na plný úvazek a dostávají dary od komunity.
Později vznikl Fedora Asahi Remix, což je běžně dostupná Fedora určená pro 64bitový ARM, do které jsou přidané vlastní repozitáře s doplňkovými balíčky. Není potřeba používat tuto distribuci, jsou k dispozici i varianty s Ubuntu nebo Arch. Jakékoliv novinky se ale dostávají nejprve do Fedora Asahi Remixu.
Instalace je velmi jednoduchá, stačí do macOS stáhnout a spustit shellový skript. Zeptá se vás na několik voleb a vybrat si můžete například desktopové prostředí.
Nevýhodou tohoto postupu je, že není možné si zašifrovat disk. Pro macOS není žádná utilitka, která by uměla používat LUKS.
Existují různé komplikované postupy, které to dokáží řešit, ale vyžaduje to pokročilejšího uživatele.
Z hlediska hardwarové podpory je situace velmi dobrá, funguje grafický výstup přes HDMI, zvukový výstup, webkamera, Wi-Fi, bluetooth a čtečka SD karet. Grafické ovladače jsou také na velmi dobré úrovni, výkon je velmi dobrý a podporovány jsou OpenGL 4.6, OpenGL ES 3.2 a Vukan 1.3. Většina logiky je skryta ve firmware počítače, takže nebylo potřeba vše programovat od začátku.
Pořád nefunguje integrovaný mikrofon a je nutné si v případě potřeby připojit externí pomocí USB. Zamrzí také nefunkční grafický výstup přes USB-C, protože port běží zatím pouze v režimu USB 3.0. Nefunguje ani čtečka otisků prstů TouchID, která je z bezpečnostních důvodů hodně uzavřená. Je otázka, jestli to bude někdy vůbec vyřešeno.
Problémem je zatím také vysoká spotřeba energie při uspání. V Linuxu se počítač vlastně ani neuspává, zhasne se obrazovka a počítač se podtaktuje na co nejnižší úroveň.
Spotřeba v takovém režimu je asi 1,7 % kapacity baterie za hodinu, tedy během dvou dnů se počítač vybije. Na druhé straně to ale velmi rychle nastartuje, než otevřete víko, je systém v provozu.
Z hlediska softwarového je k dispozici prakticky vše, co je možné najít v repozitářích Fedory. Problémem je třeba virtualizace, Boxes padají a KVM je extrémně pomalé.
Chybí nativní buildy komerčních aplikací jako Spotify, Slack, Chrome a podobně. Čerstvě je možné emulovat procesor x86 pro běh obvyklého software pomocí nástroje Fex. Automaticky se stáhne obraz základní Fedory a v něm je pak spuštěná emulovaná aplikace.
V takovém režimu je možné spustit například i Steam a v něm je možné hrát hry určené pro Windows pomocí Protonu. Jsou tam pak asi čtyři vrstvy abstrakce a běží to moc pěkně, dá se na tom docela dobře hrát.
Vývojáři se tímto směrem právě hodně zaměřují a brzy zřejmě uživatelé nepoznají, pro jakou architekturu je konkrétní software určen.
Petr Živoslav Bolf: Nixos – proč se tak liší od jiných distribucí?
Nix je balíčkovací systém a zároveň funkcionální deklarativní programovací jazyk, ve kterém se popisuje výsledný stav prostředí. Velkým cílem je spolehlivost, tedy konzistentnost celého operačního systému.
To obvykle řeší balíčkovací systémy, které ale běžně neumí řešit potřebu mít zároveň software v různých verzích.
Nix je možné použít v libovolné distribuci a použít jej jako doplňkový balíčkovací systém, jakými jsou například také Snap nebo Flatpak. Nebo je možné použít jej jako hlavní správce balíčků přímo v distribuci Nixos.
Většina distribucí je si velmi podobná, používají stejný software, stejné grafické prostředí a některý z běžně používaných balíčkovacích systémů. Vždy ve stejných adresářích najdu ty samé soubory, v principu je to pořád to samé.
Nix na to jde o dost jinak a je to v něm trošku složitější.
V adresáři/etc jsou všechny objekty jen symbolickými odkazy na soubory kdesi v /etc/static/ . Dokonce i takový základní soubor jako hosts, který je v každé distribuci.
V adresářistatic je pak další odkaz na soubor v /nix/store/ . V něm jsou vlastně uloženy všechny soubory. Aby to vypadalo jako běžný Linux, jsou na obvyklých cestách ty symlinky.
Každý balíček v /nix/store/ má svůj adresář, který má ve svém názvu heš odvozený od verze a konfigurace daného balíčku. Aby se vědělo, co na co odkazuje, používá Nix databázi uloženou v SQLite.
Balíčkovací systém podporuje také princip generací, které se vytvářejí po každé změně. Je pak velmi snadné se vrátit v čase kamkoliv zpátky, je to úplně blbuvzdorné.
Jediná skutečná konfigurace systému se nachází v souboru /etc/nixos/configuration.nix, pomocí něhož je možné si nainstalovat stejně nakonfigurovaný systém na mnoha různých serverech. Uvnitř je jednoduchý deklarativní jazyk, který jen přebírá parametry.
Soubor je možné rozdělit do mnoha modulů, které je možné v hlavním souboru volat.
V současné době je pro Nixos připraveno asi 100 tisíc balíčků, jejichž definice se nachází v jednom obrovském gitovském repozitáři.
Jakub Onderka: Postkvantová kryptografie prakticky
Kryptografii používáme k zajištění dostupnosti, integrity a důvěrnosti informací. To je triáda, podle které ověřujeme, zda je systém bezpečný.
Používáme symetrické algoritmy jako AES a asymetrické jako DSA, RSA, či algoritmy založené na eliptických křivkách. Tyto algoritmy jsou s námi desítky let a přestože nemáme důkaz o jejich absolutní bezpečnosti, pravděpodobnost prolomení je velmi nízká.
Situace se ale pravděpodobně brzy změní.
Kvantové počítače dneška jsou spíše kvantovými kalkulačkami, protože využitelnost v praxi je velmi nízká. Už se ale někdy uvádí, že některý výpočet byl už rychlejší než na klasickém počítači.
Ke skutečnému průlomu bychom potřebovali „kryptograficky relevantní kvantový počítač“, který by potřeboval přibližně 4000 qubitů, tedy asi dvacetkrát více než máme dnes.
Kdy něco takového bude k dispozici? Někdo tvrdí, že takový počítač už existuje, jen se o tom neví.
Jiní odborníci říkají, že takový počítač nikdy mít k dispozici nebudeme. Že je to jako s jadernou fúzí, kterou už máme mít taky k dispozici dvacet let a nemáme ji.
S poloviční pravděpodobností bude takový počítač existovat v roce 2032. Můžeme tedy být v klidu?
Současné symetrické algoritmy jsou kvantově bezpečné, bude u nich stačit pro jistotu navýšit délku klíčů na 256 bitů. Tohle umíme udělat už dnes, nebude to znamenat žádné komplikace.
Půjde vlastně jen o konfigurační volbu, která nám bezpečnost zajistí.
Problém je to u asymetrických algoritmů, které nejsou kvantově bezpečné a s dostatečně výkonným kvantovým počítačem budou prolomitelné. Musíme to tedy začít řešit už teď, protože IT má velkou setrvačnost a životnost různých systémů je často pět až sedm let.
Například centrální daňový systém je stejný už třicet let a upravit takovou aplikaci bude velmi složité.
Dalším problémem je, že útočník už nyní může sbírat zašifrovanou komunikaci a tu ukládat pro pozdější dešifrování. Typické tajemství má životnost pět let, takže u kritických informací přenášených v prostředí internetu potřebujeme do roku 2027.
Například vojenské informace jsou zajímavější i po mnohem delší době.
Nejrozšířenějším protokolem pro sestavení bezpečného spojení je TLS. Ten zajišťuje tři hlavní funkce: ověření funkce, dohoda na šifrovacím klíči a šifrování obsahu pomocí symetrických algoritmů. Hlavní problém spočívá v oblasti dohody na šifrovacím klíči, kde se využívá asymetrická kryptografie.
Jedním z řešení je kvantová distribuce klíčů, kdy se posílají fotony mezi dvěma místy a pomocí vlastností fotonů se přenáší klíč. Tohle má ale velmi mnoho technických omezení.
Omezené je i použití, protože není možné tento mechanismus použít pro bezdrátovou komunikaci. Zkouší se to a funguje to, ale náklady s tím spojené jsou natolik vysoké, že je naivní si myslet, že vznikne nový kvantový internet.
Druhou možností je vymyslet nové algoritmy, které budou odolné proti lámání na kvantovém počítači. Americký NIST v rámci soutěže vybral první algoritmus pro prostkvantovou dohodu nad klíči. Ten byl přihlášen pod názvem CRYSTALS-Kyber, který byl později standardizován jako ML-KEM. NIST má velkou sílu a co on schválí, se pak obvykle prosadí ve velké části světa.
Tyto algoritmy jsou ale velmi mladé a nejsou tak prověřené, jako ty klasické. Neznamená to, že se máme vrátit zpět, ale prosazuje se hybridní přístup kombinující klasický a postkvantový algoritmus.
Má to ovšem své nevýhody v podobě vyšší latence a výpočetní náročnosti. Pro prolomení komunikace ale musejí být prolomeny oba algoritmy.
Takový přístup se prosazuje v protokolu TLS v podobě algoritmu X25519MLKEM768, který v současné době prochází standardizací.
Podpora se už objevuje v software. Google Chrome a jeho deriváty od verze 124 podporují starší verzi algoritmu, od verze 131 bude k dispozici podpora pro standardizovanou verzi. Firefox od verze 124 má také svou implementaci, ale je třeba ji zapnout v about:config. Aplikace napsané v jazyce Go už také algoritmus podporují od verze 1.23. Obecně stačí pro přidání podpory používat knihovnu BoringSSL, což je fork OpenSSL od společnosti Google.
Podpora je k dispozici také od OpenSSH 9.9, která implementuje stejný algoritmus. Podpora také prochází standardizací, ale už je to zapnuté v klientu i v serveru.
Postkvantové šifrování může vypadat jako nějaké teoretické hraní, ale kromě prohlížečů také podporu ohlásily další služby jako Signal, iMessage a operační systémy od Apple. V praxi je tedy skutečně možné tento způsob zabezpečení použít, například Nginx stačí zkompilovat s knihovnou BoringSSL a pak v konfiguraci podporu algoritmů zapnout. Poté, co jsme to zapnuli, se nám nestalo, že by se někdo ozval s nefunkčním připojením.
Podpora se zatím ještě postupně zavádí a vývoj je překotný, takže se doporučuje s nasazením v produkci ještě počkat na lepší podporu ze strany výrobců a vývojářů. Rok 2025 bude rokem zavádění podpory pro postkvantovou výměnu klíčů.
Vyzkoušet je to možné na Portále NÚKIB, kde je dole v patičce informace „Zabezpečeno postkvantovým šifrováním“. Chtěli jsme tím získat nějaké praktické zkušenosti a propagovat postkvantovou kryptografii.
Příjemným bonusem přechodu na BoringSSL je také podpora HTTP/3.
Michal Špaček: Zadní vrátka pro zvířátka
Útok na dodavatelský řetězec znamená útok na nejslabší článek řetězce, nad kterým obvykle nemáme kontrolu. Je to útok na nějakou knihovnu, framework nebo API.
Dokonce to jde až tak daleko, že se může útočit na úplné základy – třeba na kompilátor.
Čínská skupina Barium se snažila v roce 2019 rozšířit svůj malware skrz upraveny kompilátor pro Visual Studio. Podobně se objevila upravená verze kompilátoru Xcode pro systémy od Apple. Když něčím takovým svůj kód zkompilujete, vypadne něco úplně jiného.
Jak ale můžeme vědět, že výsledek je tím, co jsme chtěli? K tomu se používají takzvané reproducible buildy a není to úplně jednoduché.
Existuje například návod pro sestavení klienta sítě Signal, ale ten je velmi dlouhý a složitý. Zkoušel jsem to a skončil jsem asi ve dvou třetinách a vzdal jsem to.
Podobně proběhl útok na ukrajinskou společnost, která vyvíjela účetní software. Útočníci upravili aktualizační systém tak, že se tisícům účetních nainstaloval nechtěný software. Tahle firma pravděpodobně ponese následky, což je novinka. Můžou za útok na někoho jiného a budou mít problém. Podle mě je to správně.
Takto upravený software se k nic netušícím uživatelům dostane aktualizací a nějakou dobu trvá, než si toho dodavatel všimne. Uživatelům je zároveň doporučováno co nejdříve aktualizovat, ale tím si mohou nainstalovat nový nedetekovaný problém. Co s tím? Nainstalovat si nejdřív software do testovacího prostředí, ale jak poznat problém? Já nevím.
Podobné problémy jsou všude kolem nás, Michal Špaček například zjistil, že autor knihovny pro dvoufaktorovou autorizaci nemá pod kontrolou záznam v balíčkovacím systému pro PHP. Ta knihovna je poměrně důležitá a stahuje ji poměrně hodně lidí.
Nezbývá než takový balíček nepoužívat, ale potenciál zneužití takového stavu je velký.
(Autorem fotografií je Petr Krčmář.)
ČLÁNKY DO MAILU