Vlákno názorů k článku Rozbor malware od Hacking Teamu: jak se používá? od roberto - to sem prekvapen ze nikdo nezna Qube OS...
-
roberto (neregistrovaný)
to sem prekvapen ze nikdo nezna Qube OS - oddeleny virtualy pro ruzne ucely, napr: 1) virtual - developement env 2) bezne browsovani, mozna i flash... 3) Internetbanking... 4)stealth prostredi, bitcoin klient..
Qube je zalozeno na fedore (pouziva i jeji repositare), kt ma nejmene vaznych zranitelnosti -kouknete si cvedatils.com
Jako browser bych doporucoval firefox-esr verzi kt je najbezpecnejsi. -
Ondra Satai NekolaZlatý podporovatelQubes mi padly do oka uz pred drahnou dobou. Ale odrazuje mne UI (KDE 4+ je prima, ale proste to neni muj salek i3. ) a mam, mozna neoduvodnene, strach, co vsechno se rozdpadne nejakym naprosto neocekavanym zpusobem.
-
Taky jsem se bál. Nainstaloval jsem to (3.0 RC1) vedle Ubuntu jako dualboot. Teď už dualboot nemám – Ubuntu jsem vyhodil.
Asi největším problémem byla instalace Bumblebee, našel a nahlásil jsem u toho dva nepříjemné bugy, kvůli kterým mi to odmítalo ten balíček nainstalovat. (Qubes má instalaci balíčků v privilegovaném VM řešenou částečně po svém, protože ten nemá přímý přístup do sítě – hádejte proč…) Ale ty už jsou dnes opraveny.
KDE není nutnost, je možno použít i XFCE. Šlo by i jiné prostředí, ale jen s patchnutym okenními managerem (a k dispozici jsou Kwin a Xfwm) Zkusil jsem obojí a nejspíš budu používat Xfce s Kwin. Už jsem si s Xfce integroval i aktivity :-)
Podpora Linuxových VM je celkem dobrá, umí většinou i dynamicky přidělovat RAM jednotlivým VMs. I když prostor pro zlepšení tu určitě je a s malou RAM bych Qubes nedoporučuje. Swapování například není poreseno úplně ideálně…
Nedoporučil bych Qubes lidem, kteří potřebují nutně grafickou akceleraci něčeho jiného než desktopu.
Pro Windows VM bych zatím nedoporučil 3.0 RC1, i když se to snad brzy změní.
Jinak tu jsou nějaké glitche (na 3.0 RC1), ale dá se s nimi žít.
A na mailinglistu Qubesu jsou ochotní.
-
Jenda (neregistrovaný)
Můžu opakovat otázku? (nějaký jiný uživatel mi posledně neodpověděl)
- Jak je to s provozem „nedůvěryhodných USB zařízení“? V mém případě softwarové rádio, osciloskop a JTAG programátor FPGA. Do virtuálu můžu přehodit USB řadič, ale to mi asi přestane fungovat USB klávesnice, ne?
- Je tam nějaká alespoň elementární akcelerace videa (XVideo, OpenGL…) nebo to posílá škálované pixmapy (a je to použitelné?)
-
"Do virtuálu můžu přehodit USB řadič, ale to mi asi přestane fungovat USB klávesnice, ne?"
Tady situace není úplně ideální, ale dá se s tím v některých případech pracovat. Tady je pár mých poznámek, trošku nesetříděných:
* K VM se dá přiřadit jen celý řadič (PCI zařízení), ne samotný port. Já mám ale na notebooku více řadičů.
* Technické omezení: jakmile virtuálnímu stroji přiřadím PCI zařízení, musím mu paměť přiřadit fixně. Pokud mu RAM přestane stačit nebo pokud bych naopak chtěl část RAM předat jinému stroji, neobejde se to bez restartu. U ostatních Linuxových PVM se RAM standardně přiděluje a odebírá automaticky – bez zásahu uživatele.
* Na druhou stranu, většina notebooků má klávesnici i touchpad připojené přes PS/2. Horší je to na MacBoocích a stolních počítačích, ale více různých řadičů ten problém může vyřešit.
* BTW, mít více řadičů je bezpečnostní výhoda tak jako tak. Řadič funguje jako hub, takže nedůvěryhodná zařízení mohou odposlouchávat část komunikace (nebo celou komunikaci) s jiným zařízením na stejném hubu.
* Flashky apod. lze řešit přes virtuální stroj, který má připojený řadič. Z tohoto stroje lze snadno přeřadit blokové zařízení (dokonce i jen jednu partition) jinému stroji.
* Ostatní USB zařízení by asi šlo řešit přes nějaké síťové USB řešení. (Ne však klávesnice a myš` tu člověk potřebuje v dom0 (privilegovaná VM), která nemá přístup k síti – a i kdyby se to vyřešilo jinak (např. přes Qubes RPC), fakticky bychom tím povýšili naši USBVM na důvěryhodný stroj). Zatím jsem to moc neřešil a mám spuštěnou jen jednu VM s přiřazeným USB řadičem. Když potřebuju připojit jiné USB zařízení, tak ji vypnu a spustím jinou VM.„Je tam nějaká alespoň elementární akcelerace videa (XVideo, OpenGL…) nebo to posílá škálované pixmapy (a je to použitelné?)“
AFAIK to posílá škálované pixmapy, ale je to použitelné i na 1600×900 fullscreen. Resp. pokud tu je nějaká akcelerace videa, tak leda nějaké specializované instrukce v procesoru. AppVM do dom0 ale už posílá obsah okna jen jako RGB data.
(Mimochodem, fullscreen je v Qubesu potřeba vyžádat od správce oken. To není problém (defaultně v KWinu: Win+Space, More actions, Fullscreen; s mým nastavením: Win+F), jen to může být trošku překvapení. Virtuální stroj si totiž nemůže jen tak přivlastnit celou obrazovku, aby nemohl podvrhnout třeba dialog pro zadávání hesla.)
-
„AppVM do dom0 ale už posílá obsah okna jen jako RGB data.“
Ještě dodám, že toto je úmysl. Protokol je záměrně navržen tak, aby tu byl co nejmenší prostor pro chyby.
Podobně inter-VM copy&paste je plaintext-only (zatím mi to celkem stačilo) a je navrženo s ohledem na bezpečnost: https://www.qubes-os.org/doc/CopyPaste/
-
Jenda (neregistrovaný)
OK. Já mám náhodou ještě notebook co má USB2 i 3, takže má dva řadiče, ale v Linuxu to prostě nefunguje. A teď se dají očekávat notebooky co mají pouze USB3. Do desktopu bych USB kartu do PCIe klidně vrazil. Klávesnici mám USB, protože ta na notebooku je neergonomická. KVM třeba umí do virtuálu dávat jednotlivá USB zařízení, ale jak je to bezpečné u Xenu netuším.
O fullscreen mi nejde (a bezpečnostní implikace chápu). Většinou prostě okno mplayeru jenom roztáhnu.
-
„Linuxu to prostě nefunguje“ – co nefunguje? Vím, že jsem měl nějaké problémy s USB 3, zejména nemohlo být snad žádné zařízení v portu při bootu systému (aspoň na Ubuntu 12.04), ale jinak to fungovalo. Ale to s tím asi nesouvisí.
Ad USB3 only: To ještě neznamená, že musejí mít jen jeden řadič. I když samozřejmě mohou. Na noteboocích s hodně porty je ale šance, že nebudou.
Obávám se, že USB klávesnice zapojená do stejného řadiče jako nějaké nedůvěryhodné USB zařízení, je stejně game over, ať už bychom se snažili na úrovni SW jakkoli. (Předpokládám, že ten, kdo ovládá klávesnici, ovládá i samotný stroj.) Pokud jsem to dobře pochopil, tak libovolné USB zařízení může podvrhávat pakety s jiného USB zařízení, které je připojeno ke stejnému USB controlleru. Software pak nemá šanci poznat, jestli ten stisk klávesy šel ze skutečné klávesnice, nebo z nedůvěryhodného USB zařízení. To bez změny v HW nevyřešíme.
Napadají mě dvě varianty, jak to řešit na úrovni HW:
* Před nedůvěryhodné USB zařízení připojit něco, co takovéto útoky znemožní. Mohl by posloužit i další USB hub, ale nevím, co zde říká specifikace a jak se to v praxi implementuje.
* Použít pro klávesnici jiný protokol, který by stisky kláves posílal autentizovaně. Nutno přizpůsobit SW a zakázat legacy klávesnice.Tím neřeším odposlouchávání, ale moc nevím, jestli se to nějak prakticky týká klávesnice. Pokud ano, tak to asi bude dost challenge – když uvážím i různé timming attacks. Už tak je můj příspěvek dlouhý, tak to tu nerozepisuju.
Jinak na Qubesu je i možné všechna USB zařízení připojit do dom0 (což je i výchozí volba – právě kvůli USB klávesnicím). Budou fungovat flashky (byť s možností badusb), budou fungovat klávesnice a myši. S hardwarem, který má být připojen přímo k nějaké VM, ale už asi bude problém.
Na druhou stranu, nějaké bezpečnostně suboptimální řešení na Qubesu může být stále přínosem – ve srovnání s klasickými systémy to může být přinejhorším stejně bezpečné a nikde není psáno, že útok musí probíhat skrze USB. Pokud útok přijde z Internetu, tak tuto možnost nemusí mít útočník k dispozici.
BTW: Teď mám USB2 přiřazené k dom0 (tj. privilegovaná VM) – právě kvůli klávesnici, kterou bych si chtěl pořídit. USB3 je pro AppVMs.
-
Jenda (neregistrovaný)
> co nefunguje?
Moje konkrétní kombinace řadičů na Asus U36GS po uspání nevidí USB zařízení nebo použití způsobí kernel panic.
> Obávám se, že USB klávesnice zapojená do stejného řadiče jako nějaké nedůvěryhodné USB zařízení, je stejně game over, ať už bychom se snažili na úrovni SW jakkoli.
Já myslím spíš nedůvěryhodný ovladač/userspace aplikaci. Ale je pravda, že teoreticky může virtuál vyhackovat klávesnici a potom z ní zbytek systému.
-
„po uspání nevidí USB zařízení nebo použití způsobí kernel panic.“ – jaj, to zní hůř. Je fakt, že na Qubesu jsem měl s USB po probuzení taky problém, ale vyřešil to hook na suspend/resume toho zařízení: https://groups.google.com/d/topic/qubes-users/XtdtD20BiSA/discussion
„Já myslím spíš nedůvěryhodný ovladač/userspace aplikaci.“ – Pokud budeme důvěřovat všem připojeným USB zařízením, pak by teoreticky šlo (všechno připojím do dom0 a odtud předávám USB porty do jiných VM), ale na Qubesu to není moc implementováno. Pokusy pro podobné věci byly, ale asi to není priorita: https://www.qubes-os.org/doc/USBVM/
(Spíše je tedy snaha nemít USB zařízení v dom0 a mít pro to nějakou jinou VM, ale pokud by se to vyřešilo, pak asi nebude až takový problém mít to v dom0.)
„Ale je pravda, že teoreticky může virtuál vyhackovat klávesnici a potom z ní zbytek systému.“
To asi hodně teoreticky, zvlášť když se k ní ani přímo nedostane – jen GUID mu přeposílá stisknuté klávesy (pokud je zrovna nějaké jeho okno aktivní) a VM nastavuje tak možná LED diody na klávesnici. Ale mohl by třeba flashnout nějakému zařízení (Arduino?) firmware a to zařízení by se pak snažilo podvrhnout USB pakety, aby vypadaly jako z klávesnice. -
roberto (neregistrovaný)
no kamarad fici na qube asi pul roku a zatim pohodka, ani zatez neni nejak extra velka. jenom kdyz clovek startuje na tom virtuali neco tak to muze chvilku trvat (hlavne kdyz dela neco na 1 a pak prepne na 2), ale celkove pohodka. Musim to i ja skousti zatim bezim na opensuse tumbleweed
