Hlavní navigace

Vlákno názorů k článku Tails: superbezpečný systém nejen pro Snowdena od Trubicoid2 - Není ten qubes ještě snowdenovatější? Tam všechno běží...

  • Článek je starý, nové názory již nelze přidávat.
  • 29. 1. 2016 21:15

    . . (neregistrovaný)

    "bezpečné linux distribuce" jsou teď in :).

    Qubes si hraje na bezpečnost, myšlenky mají dobré, ale mít "nebezpečný" síťový VM a hned vedle něj "bezpečný" firewall na stejné plnotučné Ubuntu distribuci mi trochu nesedí, stačí jen exploit a prosvištíš si to napříč :).

    Zdrojový kód je dost neučesaný, nepřehledný, občas pěkná prasárna. Spojovat jednotlivé VM pomocí VNC není špatný nápad, ale dopad na performance je značný. Na druhou stranu je to ideální distribuce pro vývoj linux SW :).

    Tails je jen takový přívěsek, sice v dokumentaci důrazně doporučují zkontrolovat integritu staženého ISO, ale bez problémů si nechají spustit upravený obraz, stejně tak chybí možnost v spuštěném systém zkontrolovat, že vše sedí. Tor je super věc, ale pokud na všechny otevřené stránky dotyčný používá jeden a ten samý prohlížeč, stejně udělá dřív nebo později nějakou botu a prozradí se. O obrovských LibreOffice a další spoustě SW, které nejspíš obsahují ještě řadu neobjevených chyb ani nemluvě. Vlastně mě napadá jediné využití, pro vlastní pocit klidu.

  • 29. 1. 2016 23:43

    Jenda (neregistrovaný)

    > ale mít "nebezpečný" síťový VM a hned vedle něj "bezpečný" firewall na stejné plnotučné Ubuntu distribuci mi trochu nesedí

    Neposlouchají tam žádné služby, takže jediný možný exploit by byl na IP stack v kernelu. A kernelu se nevyhneš na žádné distribuci.

    Šlo by tomu pomoct pomocí grsecurity, který tam nevímproč nemají.

    > sice v dokumentaci důrazně doporučují zkontrolovat integritu staženého ISO, ale bez problémů si nechají spustit upravený obraz, stejně tak chybí možnost v spuštěném systém zkontrolovat, že vše sedí

    Jak by sis takovou kontrolu představoval? Když budu backdoorovat software v distribuci, tak změním i ten program, který ji má zkontrolovat.

  • 30. 1. 2016 0:06

    Vít Šesták

    > Šlo by tomu pomoct pomocí grsecurity, který tam nevímproč nemají.

    O tom se diskutovalo. Grsecurity by mohlo pomoci, ale:

    1. Jsou nějaké problémy Grsecurity v kombinaci s Xenem (aspoň u PV). AFAIK by šlo Grsecurity použít, ale omezeně.
    2. Přínosy jsou u Qubesu omezené. Například nemají moc význam kernel privilege escalation exploity z pozice neprivilegovaného uživatele, protože Qubes řeší sandboxování jinak.

  • 30. 1. 2016 22:02

    . . (neregistrovaný)

    Grsecurity je v tomhle případě k ničemu. Aktualizací s nedostatečnými pravidly v firewallu se tam může dostat aktivní služba, která průnik zprostředkuje. Kontrola změn u takového balíku SW není jednoduchá a vede k chybám.

    Na kontrolu integrity je relativně dost způsobů, viz i dokumentace u Tails. Co mě ale v tomhle případě vadí je, že sice krásně popisují důležitost kontroly u staženého ISO, už ale nepopisují jak takovou kontrolu provést u bootovatelného usb. Tails je primárně určen k fyzické bezpečnosti a změnit data na usb je tak snadné...

  • 30. 1. 2016 22:20

    Vít Šesták

    > Grsecurity je v tomhle případě k ničemu.

    To je dost odvážné tvrzení. Grsecurity nabízí mnoho voleb, kterým ztíží útočníkovi některé cesty. Pokud bude například problém s memory-safety v kernelu, vlastnosti jako ASLR nebo PAX_RANDKSTACK. Problém se může samozřejmě objevit i jinde, ale i tak nemůžu říct, že by Grsecurity zde bylo k ničemu.

  • 30. 1. 2016 22:31

    . . (neregistrovaný)

    jasně ;), Grsecurity je určité vhodné mít, ale nemohu se na něj spolehnout, že zabrání všem zranitelnostem.

    Zrovna PaX je velice užitečné pro jeho prevenci přetékání proměnných kam nemají, častá to nemoc SW. Raději než ASLR bych ho doporučoval kvůli lepší kontrole oprávnění.

    Každopádně trochu offtopic, správné nastavení selinux/appar­mor/grsecurity je občas trochu alchymie a vše jen proto, aby se vyrovnala pozice openBSD s linuxem. Proč rovnou na firewall nepoužít openBSD? :)

  • 30. 1. 2016 22:46

    Vít Šesták

    > nemohu se na něj spolehnout, že zabrání všem zranitelnostem.

    To ale u ničeho :)

    > kvůli lepší kontrole oprávnění.

    V kontextu Qubesu, kde typicky máme jediného uživatele daného VM? Tam mii zrovna toto nepřijde jako až tak významná fíčura. (Byť může mít nějaké využití.)

    > Proč rovnou na firewall nepoužít openBSD? :)

    Mám pocit, že se o něčem takovém diskutovalo a byl pro to snad i nějaký důvod, ale nevzpomínám si. Ale když už by se to mělo měnit, tak radši MirageOS :)

  • 30. 1. 2016 22:55

    . . (neregistrovaný)

    Grsecurity bylo původně zmíněno jako odpověď jak ten VM zabezpečit, tak jsem ho rovnou diskvalifikoval, protože to není všelék :).

    mluvím o RBAC, kde je možné pro jednotlivé procesy detailně nastavit k jakým zdrojům a za jakých podmínek mají přístup a jaká pravidle se vztahuje pro daný proces, třeba i tebou zmiňovaná ochrana stacku. Vhodné zejména pro okleštění nutných služeb v VM ať už ntp, tak i řídící procesy pro qubes atd. však jich tam běží nemálo.

    Hm, musím pohledat, to mi nějak uniklo. MirageOS mám rád, dají se do něj dobře generovat pravidla pro FW a běží velice stabilně. Dříve jsem byl proti němu, agrumentoval jsem chybějícími nástroji pro ladění, postupně jsem ale došel do situace, kdy vidím, že ladící nástroje nejsou potřeba moc často.

  • 31. 1. 2016 6:23

    Jenda (neregistrovaný)

    > mluvím o RBAC, kde je možné pro jednotlivé procesy detailně nastavit k jakým zdrojům a za jakých podmínek mají přístup

    Přiznám se, že když jsem mluvil o Grsecurity, šlo mi hlavně o jejich kernel hardening. Proto jsem taky v hned předcházející větě zmínil exploit na IP stack.

    > ntp

    IMHO tam není, netřeba.

    > tak i řídící procesy pro qubes atd.

    Ty ve VM komunikují jen s Dom0. Pokud je ten vyhackuje, tak je stejně všechno ztraceno.

  • 31. 1. 2016 6:21

    Jenda (neregistrovaný)

    > Raději než ASLR bych ho doporučoval kvůli lepší kontrole oprávnění.

    Myslel jsem, že diskutujeme o firewall VM. Ta vystrkuje ven jenom kernel, který má přehazovat pakety do ostatních VM (a zahazovat ty, co nechceme). Žádná služba dostupná zvenku ani žádný uživatelský kód na ní neběží.

    > a vše jen proto, aby se vyrovnala pozice openBSD s linuxem

    To by si zasloužilo rozvést. Podle mě jsou OpenBSD a Linux na tom s bezpečností tak zhruba nastejno (stále uvažujeme firewall; ale i pokud budeš používat userspace z openbsd na linuxovém kernelu, tak to bude podobné).

  • 31. 1. 2016 6:17

    Jenda (neregistrovaný)

    > Aktualizací s nedostatečnými pravidly v firewallu se tam může dostat aktivní služba, která průnik zprostředkuje.

    Není mi jasné, co tím myslíš. Na update nemá firewall vliv, stažené balíčky se kontrolují GPGčkem.

    Grsecurity by mělo chránit proti různým overflow v kernelu.

    > Na kontrolu integrity je relativně dost způsobů, viz i dokumentace u Tails.

    Jmenuj jeden, který splňuje tvoje požadavky (zablokování spuštění upraveného obrazu, kontrola zevnitř systému).

  • 1. 2. 2016 13:17

    . . (neregistrovaný)

    Spojím odpovědi dohromady :).

    Koukejte na to ze dvou úhlů, jeden je ten primární, kdy VM má aktivní pouze firewall a přes něj routuje komunikaci dál. Tady bezpečnost závisí na FW, kernelu a dalších zjevných věcech. V tomhle nedokážu s vývojáři quebes-os polemizovat a vše vypadá dobře.

    Z jiného úhlu ale ale nutné tenhle stav zajistit v čase napříč aktualizacemi systému a případnými chybami ze strany maintainerů aktualizací a správce/uživatele systému, tj. proti dopředu neočekávaným věcem. Existuje zásada, že minimalizace množství SW a tím i případná rizika. Plnotučná Fedora distribuce obsahuje poměrně dost SW, tomu bude odpovídat i množství změn, které je potřeba zkontrolovat při aktualizaci a existuje riziko, že projde změna, která třeba spustí službu, která dříve neběžela nebo naopak změní nastavení služby, která třeba nemá poslouchat venku. A o tomhle riziku mluvím.

    Grsecurity a RBAC je právě způsob jak všem ostatním aplikacím defaultně přistřihnout křidélka, tak aby nemohlo v budoucnu dojít k neočekávané zranitelnosti změnou samotné aplikace přes její aktualizace. Tj. na systému plošně zakážu, aby kdokoliv jiný mohl použít vnější interface, vytížit CPU atd.

    OpenBSD z mého pohledu je dál než linux. Hlavní sílu vidím v tom, že kernel vývojáři jsou zároveň maintaineři balíčků, systém je zevrubně dokumentovaný a možná bezpečnostní rizika s použitím čehokoliv jsou jasně vykřičena ven, všechny balíčky kopírují stejnou strukturu, systém je přehledný a stabilní. Lze snadno sestavit minimální verzi openBSD pro právě jednoúčelové zařízení a jeho pf FW mi sedí daleko více než iptables. Nemyslím si, že je užitečné poměřovat pt**ky a přitom většinu bezpečnostích chyb nezpůsobí technika, ale její "uživatelé" a *BSD je pro mě přehlednější, determinističtější a stabilnější pro konfiguraci. Nejen pro mě, ne nadarmo důležité systémy právě používají tyhle OS, ne nadarmo nám pohání hraniční servery a loadbalancery.

    Třeba podporu pro Xen dlouho Raadt zamítal a teprve několik měsíců jsou k dispozici patche a snad zanedlouho se dostanou do testovacího sestavení.

    Pokud jde o kontrolu integrity a reálný příklad, třeba teď se hodně mluví o chybách v Juniper. Pracoval jsem s ScreenOS, ten si umí kontrolovat digitální podpisy obrazu podle klíčů, které jsou v podepsaném firmwaru, tj. dostanu HW, zkontroluji podpisy firmware, poté nahraji OS a ten zkontroluji proti firmwaru při každém startu. Tohle je ale pro Tails sci-fi a s vnitřní kontrolou integrity jsem zašel daleko, jak jsem popsal v jiném vlákně, stačily by mi nástroje, kde je možné zkontrolovat již připravenou boot flashku z jiného systému, aby to dokázal udělat běžný uživatel.

  • 2. 2. 2016 22:03

    Vít Šesták

    > Plnotučná Fedora distribuce obsahuje poměrně dost SW

    Jo, ale:
    * Je tu fedora-23-minimal. Já používám tuto šablonu, doinstaloval jsem si tam toho minumum (zejména firmware, sudo a haveged).
    * Velká část z tohoto software (např. Firefox a tuna knihoven) stejně bude ležet v sys-firewall ladem a nic nebude dělat. Riziko tu u „velkých“ šablon je, ale ne tak velké.

    > Grsecurity a RBAC je právě způsob jak všem ostatním aplikacím defaultně přistřihnout křidélka, tak aby nemohlo v budoucnu dojít k neočekávané zranitelnosti změnou samotné aplikace přes její aktualizace.

    Obecně ano, ale v případě sys-firewall tu vidím ještě menší bezpečnostní zlepšení než pomocí fedora-23-minimal.

    > Třeba podporu pro Xen dlouho Raadt zamítal a teprve několik měsíců jsou k dispozici patche a snad zanedlouho se dostanou do testovacího sestavení.

    To bude asi ten důvod, proč sys-firewall nejede na BSD :) A asi ani nikdy nepojede, když se experimentuje s MirageOS.

  • 30. 1. 2016 0:02

    Vít Šesták

    > mít "nebezpečný" síťový VM a hned vedle něj "bezpečný" firewall na stejné plnotučné Ubuntu distribuci mi trochu nesedí, stačí jen exploit a prosvištíš si to napříč :).

    * Umožní to bránit se zranitelnostem v driverech. (Nutná ale podpora VT-d.)
    * Experimentuje se s firewallem na unikernelu. Pak by ani zranitelnost v síťové části Linuxového kernelu mohla mít dost omezené pole působnosti. (Má to více výhod, vč. HW nároků.)
    * Detail: Není to Ubuntu, ale Fedora, případně je možno ji nahradit za Debian. (A s trochou snahy i Ubuntu, ale musíš chtít…)

    > Spojovat jednotlivé VM pomocí VNC není špatný nápad

    Není to VNC, ale vlastní protokol, byť se to možná VNC dost vzdáleně podobá.

    > ale dopad na performance je značný.

    Subjektivně mi nepřijde.

    > bez problémů si nechají spustit upravený obraz, stejně tak chybí možnost v spuštěném systém zkontrolovat, že vše sedí

    Není to na kontrolu trošku pozdě? Dostatečně pokročilý malware může takovéto kontroly podvrhnout.

  • 30. 1. 2016 21:48

    . . (neregistrovaný)

    za záměnu Ubuntu <> Fedora se omlouvám, ulétlo mi to :).

    Ano, zranitelnost v driverech lze takhle odstínit, ale už ne bordelem ve firmware. Plnotučnou distribucí jsem spíše narážel na situaci, kdy při update je changelog plný nepoužívaných knihoven a kontrola je o to obtížnější a může tam prolést úmyslně/neúmyslně zneužitelná chyba, s poměrně dost nepřehledně napsanýmí firewall pravidly a hromadnou aktualizací mi to nepřipadá košér. Rád bych tam viděl mnohem tenčí systém, pokusy s mirageOS jsem viděl a vypadá to zajímavě.

    Otevři si 100 jednoduchých oken a porovnej Fedora desktop a tohle. Subjektivně to také vidím ok, ale vyšší spotřeba u více oken jde vidět na baterii u notebooku, subjektivně u přehrávání videí na velkém rozlišení. Ano, protokol mají svůj, ale jak jsem ho viděl, hned jsem měl v hlavně framy u VNC, hodně se inspirovali.

    Na kontrolu pozdě není, ta možnost by být měla a cesty existují, ale tím jak se profilují, tak tohle vidím jako kámen bezpečnosti. U Tails jde primárně o to, aby nedošlo k odposlechnutí informací, které teprve začnu vytvářet.

  • 30. 1. 2016 22:05

    Vít Šesták

    Současný sys-firewall v Qubesu možná bude časem brán jako takový první hack, pokud se experiment s MirageOS podaří. (Snad ano.)

    Jo, graficky náročnější věci jsou trošku problém, pro mě ale většinou dobře vyhovuje.

    Když si stáhnu ISO a chci ho ověřit, měl bych ho ověřit dřív, než z něj cokoli spustím. Aspoň pokud mi jde o záměrné modifikace a ne o náhodné poškození. To, co navrhuješ, je jako kdyby měl někdo dělat sám sobě kontrolora. Pokud nevěřím, že ISO není modifikované, a spustím z tohoto potenciálně upraveného (=>nedůvěryhodného) ISO souboru potenciálně upravený nástroj pro kontrolu integrity a ten mi řekne, že je vše v pořádku, co se z toho dozvím? Jsou tu dvě možnosti, co mohlo nastat:

    a. Je opravdu vše v pořádku.
    b. Někdo to modifikoval a upravil i nástroj na kontrolu integrity (případně jeho data).

    Jinými slovy, vyloučil jsem jen jednu možnost:

    c. Někdo to modifikoval a byl tak blbej, že nástroj na kontrolu integrity (a jeho data) ponechal beze změn.

  • 30. 1. 2016 22:20

    . . (neregistrovaný)

    s MirageOS bude ještě hodně práce, co jsem pochopil tak nikdo z core vyvojářů s ním nemá velké zkušenosti. Mě to ale zatím moc netrápí, používám ho primárně pro snadnější testování SW.

    Dobře tak jinak, rád bych měl nástroj, který mi zkontroluje integritu flashky na které mám Tails z jiného systému. Tails používám proto, že někdo třetí má přístup k mým věcem, ISO si po stažení zkontroluji tak nebo tak, hodím ho na flashku a už jen spoléhám, že tam je pořád nezměněné...

    Existuje pár krkolomných způsobů se šifrováním pro kontrolu integrity spouštěného systému, některé viry se takhle snaží maskovat, je ale pravda, že technická náročnost a přidaná hodnota je nepoměrná.

  • 30. 1. 2016 22:30

    Vít Šesták

    Kontrolovat integritu z jiného systému už dává smysl. (Pokud předpokládám, že nikdo nemodifikoval firmware flashky…) Pokud nedělám aktualizace, mělo by to jít zkontrolovat ve stylu head -c<velikost> /dev/sdb | sha256sum. Pokud dělám aktualizace, pak je to otázka. Ale pokud má Tails jiný mechanismus než apt-get, pak možná to taky půjde.

    Šifrovat pro kontrolu integrity – to má hned dva problémy:
    1. Musel bych nabootovat odjinud, jinak to nemá moc smysl.
    2. Šifrování a autentizace jsou dvě různé věci (viz malleability). Ale OK, toto je řešitelné.

  • 30. 1. 2016 22:35

    . . (neregistrovaný)

    Ano, kontrola z jiného linuxu je snadná, Tails ale je určen spíše lidem, pro které to snadné není :), chybí mě to v dokumentaci.

    Teoreticky lze využít UEFI a podepsaný zavaděč, tj. kontrola integrity by byla v něm, tohle je ale pro mě vyšší dívčí a nevím v jakém stavu jsou zavaděče pro UEFI.