Vlákno názorů k článku Rozšíření prohlížečů jsou hrozbou pro soukromí uživatelů od Václav Pávek - Pěkný článek, který poukazuje na velký problém. Jako vývojář...
-
. . (neregistrovaný)
ale to předpokládáš, že se ti nebezpečný kód nedostane z jednoho prohlížeče do systému. Jak víme z historie, i prohlížeče obsahují zranitelnosti.
Sám ale také nevím jak to řešit, abych nebyl příliš omezený. Většinu času jsem ale na internetu přes VNC na mašině, která běží z ramdisku, takže ono se to vyřešilo samo, jen to není moc pohodlné. Přitom stačilo nevyměnit rozbitý disk a nedomluvit si na FW jiný port než na VNC.
-
. . (neregistrovaný)
máš pravdu, vidím to snad v každé diskuzi, všichni vymýšlejí všemožná krkolomná řešení na obranu proti současné hrozbě a nemyslí na budoucnost. Snad nikdo v popisu zabezpečení neklade důraz na monitoring, auditing a přehled o systému, přitom na tom stojí základ bezpečnějšího systému.
-
. . (neregistrovaný)
pokud omylem v QubesOS otevřeš špatný web a zneužije slabinu v prohlížeči nebo spustíš špatnou aplikaci v tvém prostředí, kde máš důvěrné dokumenty nebo email, jak se o tom dozvíš? Jak se dozvíš, že ti někdo odcizil data nebo se tam naopak objevil proces, který tě bude šmírovat či si z tebe udělal proxy na útočení na jiné subjekty?
QubesOS je super, mám ho rád spíše proto, že mohu mít různé pracovní prostředí a rychle si vytvářet testovací sestavy pro vývoj, ale že bych díky němu mohl tvrdit, že mám počítač v bezpečí? To ani náhodou. Výchozí nastavení je takové divné, buď protěžuji jedno prostředí a dělám tam vše, tím je bezpečnost ta tam nebo si navytvářím spousty samostatných prostředí pro každou aplikaci, pak zase pokulhávají aktualizace nebo nějaký monitoring procesů a síťové aktivity. Jo, pár lidí to bude dělat dobře, ale osobně bych řekl, že to jsou lidé, kteří to budou dělat dobře na většině systémů a QubesOS je pro ně nástroj, který jim vyhovuje, ale bezpečnost tvoří pořád oni a ne systém.
QubesOS není špatná věc, ale bezpečnost neřeší komplexně, třeba se to časem změní, zatím se jedná o bezpečný systém pouze v rukách znalého člověka, který ví co dělá.
-
Obecne pokud to ma byt bezpecne, tak musis tam, kde mas duverne dokumenty (ci chodis do banky z prohlizece atd.) pouzivat jen a pouze ty duveryhodne aplikace a stranky. A data by mely byt oddelene - tzn by jsi v jednom prostredi nemel napr. pripojovat se na internet a spravovat duveryhodne dokumenty. Samozrejme to neresi vse, ale minimalne to bezpecnost vyrazne zvysuje.
Ale vyzaduje to dost premysleni pri navrhu tech prostredi. -
. . (neregistrovaný)
já chtěl přivést myšlenky k trochu něčemu jinému, proč se jen řeší ty silné a neproniknutelné dveře, to jednoúčelové prostředí a neřeší se situace, kdy už zloděje mám uvnitř, on se tam prostě jednou nějak dostane.
Takového zloděje chci přece sledovat, nechci ho pustit vem se svými věcmi, nechci, aby někde na mě něco vyzradil nebo aby si pozval kamarády a udělal u mě párty, chci ho mít pod kontrolou.
Zakládat bezpečnost na tom, že nikdy neudělám chybu a něco špatně je krátkozraké, mohu být sebelepší a tu chybu udělám, jsem pohodlný a slepý. Nebo stačí, že tu chybu udělá ta jedna banka, které důvěřuji a jsem také kompromitovaný, i s Qubesem.
-
K zastaveni by se musel udelat hluboky prikop a data pres nej soupat v otevrenem a kontrolovatelnem formatu - takovou technologii jsem ale zatim nikde nevidel - a pochybuji, ze nekdy uvidim. Lide nechteji bezpecna reseni, staci jim zdani bezpeci s nejakym kulatym razitkem nebo certifikatem - treba to, co se snazi delat Cisco s kouzelnou AI.
-
Firejail, co jsem se naposledy díval, moc nedokumentoval, před čím vlastně chrání. Podle mých pokusů to vypadá, že to dokáže snížit dopad některých slabších útoků jako path traversal, případně zabránit útoku, který nebyl vymyšlen s ohledem na Firejail. Pokud ale útočník může vykonat libovolný kód, pak nebylo těžké se z firejailu dostat.
Flatpak (BTW, není to Flatpack, ale jen Flatpak) a Wayland na tom snad budou líp, ale neřeší věci jako přístup ke schránce nebo fake GUI (napodobení dialogu pro heslo z jiné aplikace).
QubesOS má celkem srozumitelné vlastnosti a předpokládá celkem silného útočníka.
-
U flatpak / Waylandu by ta bezpecnost mela byt dobra, pokud je dobre udelany manifest.
Sandbox flatpaku je popisany zde:
https://github.com/flatpak/flatpak/wiki/SandboxV podstate je zajistena izolace na urovni cgroups a namespace, tzn. nevidi jine procesy, filesystem etc. Dle meho nazoru by to melo byt bezpecne.
-
Třeba izolaci schránky (aplikace přečte ciltivé informace nebo nahradí číslo bankovního účtu) nebo GUI (aplikace udělá fake password prompt) jsem tam nenašel.
Nebudu rovnou tvrdit, že je to k ničemu, ale spíše než před zákeřnou aplikací nebo dopadem RCE (OK, tady to s dobře napsaným manifestem umí házet klacky pod nohy, ale není to všemocné) to chrání před zranitelnostmi jako path traversal, a opět záleží na kvalitě manifestu.
-
> Třeba izolaci schránky (aplikace přečte ciltivé informace nebo nahradí číslo bankovního účtu) nebo GUI (aplikace udělá fake password prompt) jsem tam nenašel.
Toto je vec, ktera se musi resit na urovni Waylandu, ne flatpaku. Zaklad je ve Waylandu dobry - aplikace nemuze snoopovat obsah clipboardu, compositor mu musi explicitne poslat offer na prenos dat.
Jestli tento offer dostane, je veci compositoru (nedostane ho ale nikdy, pokud je neaktivni). Ale presnou implemetnaci napr. v Mutteru neznam, musel bych se podivat do kodu. Ale obecne clipboard je samozrejme problem - do nej proste citlive veci nepatri, mmj nikdy nevite, kdy je nekam omylem pastnete :-)
Co se tyka fake passwordu, tak diky architekture waylandu neni problem oddelit dobre vizualne okna (protoze jejich zobrazeni / placement ma na starosti compositor, aplikace nema nad obrazovkou jako celku zadnou kontrolu). Samozrejme ale je to jen tak mocne, jako uzivatel to pouzivajici. Ale aleson to aktivne nepomaha jako X11.
Nicmene souhlasim, ze to je vec, ktera jeste bude chtit spoustu zlepseni a vyladeni.
Stary, nicmene porad zajimavy talk na toto tema je zde:http://www.x.org/wiki/Events/XDC2014/XDC2014DodierPeresSecurity/xorg-talk.pdf
>Nebudu rovnou tvrdit, že je to k ničemu, ale spíše než před zákeřnou aplikací nebo dopadem RCE (OK, tady to s dobře napsaným manifestem umí házet klacky pod nohy, ale není to všemocné) to chrání před zranitelnostmi jako path traversal, a opět záleží na kvalitě manifestu.
Samozrejme, ze zalezi na kvalite manifestu - to je alfa a omega celeho zabezpeceni. Spatny manifest = zadna bezpecnost. Nerekl bych, ze to haze klacky pod nohy - nekterym druhum utokum to proste zabrani a pokud nebude chyba v sandboxovani (cgroups), tak je neobejde.
-
Definujme prostředí, scénář a výsledek. Například:
Prostředí: Aktuálním Ubuntu/Debianu/Fedoře/whatever po instalaci v desktopové variantě, aktualizaci všech balíčků a instalaci balíčku Firejail. Případně mohu Firejail zkompilovat, to asi nebude náročné, možná to ale bude chtít specifikovat konfiguraci. Možná by Fedora nebo rolling varianta OpenSuse byla dobrá volba – jsou tu celkem aktuální balíčky, minimálně ve Fedoře i Wayland a instalace je jednoduchá (jednak mi šetří čas a jednak se nebudeme dohadovat, co mám jak nakonfigurovat). Může to být víceméně cokoli, co mi pojede ve virtuálce na x64 (CPU: i7-7500U, virtualizace: QubesOS HVM). Vagrantu bych se radši vyhnul, to vy si mohlo vyžádat vnořenou virtualizaci, i když 32b virtuálku ve VirtualBoxu by to mělo snad zvládnout i bez nested VT-x.
Scénář: Například Bash ve Firejailu, ze kterého spustím zákeřný skript (simulace zákeřného programu nebo RCE). Můžeme se dohodnout na nějaké specifické konfiguraci Firejailu. Jsem za to, aby na konci scénáře proběhl restart a přihlášení, to mi může pomoci a je to – hádám – celkem běžná věc.
Výsledek: Může jít o spuštění kódu mimo sandbox nebo i o menší věci – přečtení jednoho souboru, přečtení/nahrazení obsahu schránky, fake password prompt a jiné. Tady bych jako výzvu bral i spuštění kódu mimo sandbox.
Takže, můžete něco vybrat (pokud možno tak, aby příprava prostředí nestála moc času) a já bych to zkusil.
-
pk (neregistrovaný)
Tak pro me je zasadni, ze na archlinuxu se z aktualni verze firejailu palemoon nedokaze dostat jinam, nez do vybranych slozek. A to ani kdyz jsem se snazil aby se dostal.
Nicmene i prulom prosteho bashe uzavreneho v sandboxu bez moznosti cist trebas ~/dokumenty/* by me zajimal. A urcite i developera firejailu. -
No jo, ale Firejail musí nějak poznat, kam má přístup dovolit (např. ~/.mozilla/firefox) a kam ne. Podobně jako přístup přes X11 se dá různě omezovat. Proto je potřeba specifikovat nějaký profil, který to určí. V dokumentaci jsem k tomu ale moc nenašel, celkový pocit jsem měl „Něco jsme omezili a má to nějak zlepšit bezpečnost.“ bez dalšího vysvětlení. To mě tehdy odradilo od dalšího zkoumání – není jasné, jestli jde o bug, nebo feature. Vždy se dá následně říct, že a) mám špatnou konfiguraci nebo b) to je mimo rozsah hrozeb, které má Firejail eliminovat. A i proto bych chtěl bližší specifikaci, jak mám Firejail nastavit.
ArchLinux se mi sice moc nechce instalovat od nuly, ale mohl bych zkusit si zbuildit šablonu v Qubesu. (To už jsem dělal pro jiné distro.) Ano, pak to nepoběží v HVM, ale v PV, navíc s trošku jiným prostředím – ale můžeme se domluvit, že vlastnosti X11 využívat nebudu (pokud tu je přímý přístup k X11, bylo by to až moc jednoduché, v podstatě by stačil xdotool) a že nastartuju nějaké celé grafické prostředí (KDE/Gnome/Mate, je to celkem jedno, ideálně něco, co nechce moc grafickou akceleraci).
