Názory k článku Tails: superbezpečný systém nejen pro Snowdena

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? :)

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.

> 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.

> 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é).

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.

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á.

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.