Vlákno názorů k článku
Napadeny desítky balíčků Red Hatu v oficiálním kanálu NPM
od Filip Jirsák - Je známo, jak došlo ke kompromitaci toho účtu...
-
Filip JirsákStříbrný podporovatelJe známo, jak došlo ke kompromitaci toho účtu na GitHubu? Jestli tam měl uživatel jen login a heslo a uniklo heslo, nebo unikl klíč – a nebo jestli měl účet zapnuté 2FA a i přesto došlo k napadení…
-
Filip JirsákStříbrný podporovatel
Právě proto, že těch způsobů napadení je relativně hodně, mne zajímá, jak k tomu došlo v tomto případě.
-
Popravdě, z tohoto důvodu se už nějakou chvíli dívám po nástrojích, co mají šifrovaná "data at rest". E2E už umí kde co, ale na lokálním stroji jsou ta data pořád nešifrovaná.
A LUKS ani encfs nebo podobné nepomohou, protože proces s právy uživatele k nim pořád má volný přístup.
Flatpak to teoreticky odděluje alespoň pomocí namespaces, ale zrovna npm nebo Python nástroje ve Flatpaku neběží.
-
Filip JirsákStříbrný podporovatel
To je limit desktopových systémů, že jsou oprávnění na soubory udělována uživatelům a ne dvojici uživatel+aplikace. Ono to historicky dávalo smysl – ta data patří uživateli, a uživatel používá aplikace, které považuje za důvěryhodné. Akorát že se ukázalo, že uživatelé potřebují používat i aplikace, které za důvěryhodné považovat nelze. Další věc je, že balíčkovací systémy nebo NPM spouští předinstalační nebo poinstalační skripty, kde se může dít cokoli.
Ještě vtipnější je to s AI, kde „bezpečnost“ znamená, že aby se nemusel odeslat nějaký soubor do LLM v cloudu, nechá se spustit skript napsaný AI, který může pod účtem uživatele dělat a spouštět cokoli…
Podle mne to oddělení alespoň pomocí namespaces budou muset desktopové OS řešit, protože to je aktuálně největší bezpečnostní díra.
-
Koho to trapi, tak ten pouziva https://www.qubes-os.org/
TLDR: https://en.wikipedia.org/wiki/Qubes_OS -
Ono to jde. Máme i rootless kontejnery a sandboxovací technologie, pro vývojáře a power users např. bubblewrapper. I AI agenti se to snaží používat - codex cli defaultně, claude code přes /sandbox. Ale kdo to doopravdy dělá... A jakmile začne být člověk líný a začne chtít, aby i z toho nejvíc minimalistického a sandboxovaného prostředí bylo možné pushnout větev a založit Github PR, tak tam stejně nakonec ten Github token a SSH klíč bude mít. A když ne vy, tak váš línější kolega ano.
Řešení může přijít z druhé strany - kdyby Github podporoval fine-grained tokeny i pro svoje CLI tooly. Uz zadne god-mode tokeny. Ale pokud jsem celou dobu pracoval s jednom repozitarem a najednou chci menit CI credentials v uplne jinem repozitari, tak at po me Github chce autorizaci s 2FA. Jenže na to jsou typické služby v developer světě nepřipravené.
Nebo můžete nasadit hackovací klobouk a začít si psát svoje proxy servery, které budou mít Github a jiné credentials schované v sobě a vašemu toolingu budou poskytovat omezenou množinu operací, někdy třeba i s tou autorizací.
-
Alternativně lze mít SSH klíč i na Macbooku v Secure Enclave.
SE i Yubikey vyžaduje potvrzení (stiskem tlačítka, otiskem prstu...), takže nejen že privátní část klíče nejde ukrást, ale ani kdyby se malware usadil přímo na vašem počítači s fyzicky přítomným klíčem, tak k němu nemá přístup bez vaší součinnosti. Za mě super.
