The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Qubes - новая безопасная операционная система на базе Linux и Xen

08.04.2010 00:16

Джоанна Рутковска (Joanna Rutkowska), известная польская исследовательница безопасности, систем виртуализации и руткитов, выпустила новую открытую операционную систему Qubes, основанную на идее строгой изоляции приложений и компонентов ОС. Новая ОС находится в альфа стадии развития и построена с использованием гипервизора Xen и стандартного окружения Fedora Linux.

Подход к безопасности в Qubes реализуется путем полной изоляции приложений друг от друга при помощи технологий виртуализации. Это позволяет отделить друг от друга различные программы, многие системные компоненты, такие как сеть и дисковые подсистемы, и даже сами «песочницы», так, что их функционирование не влияет на целостность остальной системы. По сути, реализуется принцип микроядерности, только на прикладном уровне (прим пер.).

Qubes позволяет определить пользователю свои домены безопасности, реализованные как «легковесные» виртуальные машины. Например, пользователь может создать виртуальные машины с именами "Личное", "Работа", "Торговля", "Банк" и "Случайное" и использовать приложения в рамках этих виртуальных машин так же, как если бы они выполнялись на стандартном рабочем столе. Qubes поддерживает режимы безопасного копирования, вставки данных через буфер обмена и обмен файлами между виртуальными машинами.

На вопросы пользователей о том почему был использован Xen, а не KVM, Джоанна ответила, что она считает, что архитектура Xen позволяет создавать системы с большей безопасностью. Рутковска сказала, что она планирует выпустить полную версию Qubes к концу 2010 года, и что она может создать некоторые коммерческие расширения ОС в будущем.

Ключевые особенности:

  • Система базируется на гипервизоре Xen;
  • Код доступной приложениям сетевой подсистемы изолирован и работает в непривилегированной виртуальной машине, работа которой поддерживается при помощи аппаратных технологий IOMMU/VT-d. Костяк сетевой подсистемы работает в привилегированном домене (dom0);
  • Драйверы устройств хранения изолированы в отдельную непривилегированную виртуальную машину;
  • Пользовательские приложения запускаются в специальных легковесных виртуальных машинах "AppVM", в которых работает полноценное Linux-окружение;
  • При обновлении системы все содержимое созданных AppVM-ов автоматически обновляется по заданному шаблону;
  • Технология виртуализации GUI-интерфейса делает запуск программ в разных AppVM незаметным для пользователя, для которого приложения работают и взаимодействуют как на обычном десктопе;
  • Процесс загрузки в будущих выпусках будет защищен при помощи технологии доверенной загрузки Intel TXT (Intel Trusted Execution Technology).


  1. Главная ссылка к новости (http://theinvisiblethings.blog...)
  2. QUBES
  3. Исходники
  4. OpenNews: Уязвимость в процессорах Intel, позволяющая выполнить код на уровне SMM
Автор новости: pavlinux
Тип: Интересно / К сведению
Короткая ссылка: https://opennet.ru/26140-virtual
Ключевые слова: virtual, security, Qubes, xen
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (76) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 01:15, 08/04/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Интересно.
     
  • 1.2, Аноним (-), 01:15, 08/04/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Кошерно. Но интересно как там с игрушками всякими, которые хотят DRI всякие, например?

    (да, игрушки ненужны(tm), да... но тем не менее)

     
     
  • 2.3, аноним (?), 01:39, 08/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Проброс видяхи в гостевое окружение.

    Раньше (AFAIK) можно было только вторую видяху пробросить, а в новом xen'е (см. соседнюю новость) можно и основную прокинуть. И спокойно запускать 3D с полный использованием GPU.

     
  • 2.8, User294 (ok), 03:37, 08/04/2010 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >Кошерно. Но интересно как там с игрушками всякими, которые хотят DRI всякие,

    Думаю что рутковской они похрену - у нее другие игрушки. Ей бы правильнее было сменить фамилию на Руткитская, лучше бы отражало суть дела :)

     
  • 2.76, zz (??), 16:01, 10/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Кошерно. Но интересно как там с игрушками всякими, которые хотят DRI всякие,
    >например?
    >
    >(да, игрушки ненужны(tm), да... но тем не менее)

    выдержка из Faq на офф сайте:
    "How about running applications like games that required 3D support.

    Those won’t fly. We do not provide OpenGL virtualization for AppVMs. This is mostly a security decision, as implementing such feature would most likely introduce lots of complexity to the GUI virtualization infrastructure. However, Qubes allows for use of accelerated graphics (OpenGL) in Dom0’s Window Manager, so all the fancy desktop effects should still work under Qubes."

    так что похоже что нет

     

  • 1.4, Непонимающий (?), 01:43, 08/04/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Скажите, только без стеба:
    XEN, KVM, QEMU, VMWare, VirtualPC - Это все, по сути, одно и то-же?
    Ну, то-есть, это все программы, позволяющие на одном процессоре, одновременно выполнять несколько ОС? Я правильно понимаю? Принципиальной разницы ведь нет(суть имеется в виду)?
     
     
  • 2.5, ArsenShnurkov (?), 02:02, 08/04/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В принципе, это все примерно одно и то же.

    VirtualPC
    - это от микрософта, отличается недостатоком фич по сравнению с VmWare
    VmWare
    - мегалидер, но не опенсорное
    QEMU & KVM
    - опенсорсные, примерно одно и то же, обязательно требует аппаратную поддержку
    XEN
    - опенсорсная, отличается от KVM тем, что может работать на процессорах без аппаратной поддержки виртуализации

     
     
  • 3.11, аноним (?), 05:22, 08/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > QEMU & KVM
    > - опенсорсные, примерно одно и то же, обязательно требует аппаратную поддержку

    Ничего подобного. QEMU не требует аппаратной поддержки. А KVM хоть и опенсорсное, завязано на linux.

    > XEN
    > - опенсорсная, отличается от KVM тем, что может работать на процессорах без аппаратной поддержки виртуализации

    Но требует модифицированную версию ОС.

     
     
  • 4.15, Mna (??), 07:11, 08/04/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Host должен быть модифицирован, конкретнее, - его ядро.
    а Guest в случае с аппаратной поддержкой может быть неизменным.
     
  • 3.24, vivi (?), 11:00, 08/04/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    XEN не может работать на процессорах без аппаратной поддержки виртуализации
     
     
  • 4.25, Аноним (-), 11:07, 08/04/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >XEN не может работать на процессорах без аппаратной поддержки виртуализации

    Xen может запускать гостевые ОС в двух режимах:
    HVM и PV (паравиртуализация). Первый требует аппаратной поддержки и позволяет запустить любую ОС. Второй требует установки в ОС специальных драйверов, но работает быстрее.

     
     
  • 5.26, vivi (?), 11:23, 08/04/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >>XEN не может работать на процессорах без аппаратной поддержки виртуализации
    >
    >Xen может запускать гостевые ОС в двух режимах:
    >HVM и PV (паравиртуализация). Первый требует аппаратной поддержки и позволяет запустить любую
    >ОС. Второй требует установки в ОС специальных драйверов, но работает быстрее.
    >

    я не про гостевые, а про хостовую, ты не запустишь на ксене виртуалку, просто не запустишь, и дрова не поставишь, если процессор не поддерживает виртуализацию.

     
     
  • 6.29, Аноним (-), 12:31, 08/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ошибаетесь. Модифицированная ОСь без проблем запускается без поддержки визуализации процессором с помощью Xen
     
     
  • 7.34, vivi (?), 13:44, 08/04/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Ошибаетесь. Модифицированная ОСь без проблем запускается без поддержки визуализации процессором с помощью
    >Xen

    модифицированная не интересно. Я про стандартные говорю.

     
     
  • 8.37, Аноним (-), 14:25, 08/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Цитата из вашего сообщения выше я не про гостевые, а про хостовую Хостовая ра... текст свёрнут, показать
     
  • 8.46, аноним (?), 22:12, 08/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Оно вполне стандартное Просто это еще одна архитектура, как i386 или amd64 ... текст свёрнут, показать
     
  • 7.68, User294 (ok), 01:35, 10/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >визуализации

    Epic fail! oO


     
  • 4.42, Filosof (ok), 18:58, 08/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    *базовых.
    Хотя вообще то Hyper-V это тот же XEN только Vendor-lock. Это проговорился один хороший специалист. Вроде как это даже не особо и скрывают.
     
  • 4.47, аноним (?), 22:13, 08/04/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >- это от микрософта, отличается недостатоком фич по сравнению с VmWare
    >ага, а Wmware отличается от Hyper-V тоже недостатком фич

    Так обидно за хозяев, да, но остается только сказать "сам дурак". Hyper-V это детская поделка по сравнению не только с WMVare, но и с открытыми решениями для виртуализации.

     
     
  • 5.69, User294 (ok), 01:38, 10/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >с открытыми решениями для виртуализации.

    Hyper-V столь глюкав что не понятно каким надо быть камикадзе чтобы заюзать его в ответственных местах.

     
     
  • 6.82, Шурик (?), 17:54, 13/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >>с открытыми решениями для виртуализации.
    >
    >Hyper-V столь глюкав что не понятно каким надо быть камикадзе чтобы заюзать
    >его в ответственных местах.

    Юзаю гипер-ви р2 с полгода в продакшене: 6 виндов и один линукс на одном хосте. Все ОК.
    Я что-то делаю не так, научите, как сломать?


     
     
  • 7.83, Andrey Mitrofanov (?), 18:08, 13/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >полгода в продакшене: 6 виндов и один линукс

    Ждите. К вам придёт: вирус, антивирус, сервис-пак или маски-шоу из близлежащего УВД.

    >на одном хосте. Все ОК.

     
     
  • 8.84, Шурик (?), 09:48, 14/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Про маски шоу не надо - хост бесплатен, гости лицензированы И если хост один, т... текст свёрнут, показать
     
  • 7.85, User294 (ok), 22:40, 15/04/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вот это наверное Семь виртуалочек - это что, такой дикий продакшн на основе кот... большой текст свёрнут, показать
     
  • 3.86, Аноним (-), 23:20, 19/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    > - это от микрософта, отличается недостатоком фич по сравнению с VmWare
    >
    >VmWare
    > - мегалидер, но не опенсорное
    >QEMU & KVM
    > - опенсорсные, примерно одно и то же, обязательно требует аппаратную поддержку
    >
    >XEN
    > - опенсорсная, отличается от KVM тем, что может работать на процессорах
    >без аппаратной поддержки виртуализации

    Забыли Hyper-V и Virtual Server

     
  • 2.6, Vitto74 (ok), 02:50, 08/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    По своей основной сути это одно и тоже. Но принципы работы сильно отличаются. Скажем VMWare полностью эмулирует железо, а OpenVZ обеспечивает работу нескольких Linux не на уровне железа, а на уровне ОС, что дает меньше возможностей, но большую производительность.
    Опять же различаются цели проектов и соответственно их пригодность для различных нужд.
     
  • 2.9, User294 (ok), 04:06, 08/04/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Принципиальной разницы ведь нет(суть имеется в виду)?

    На совсем уж общем уровне, разумеется - виртуализация и в африке виртуализация. Вот только в деталях отличия могут быть и достаточно ощутимые. А то болид F1, горбатый запор, мерс и древняя самобеглая коляска - номинально все как бы автомобили, с 4-я колесами, рулем, мотором и так далее. Но вот есть небольшие (или большие) отличия в деталях...

     
  • 2.61, Кирилл (??), 12:17, 09/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ты всё в кучу смешал. Все, что ты перечислил существенно отличаются. Причём, отличаются принципиально.
     

  • 1.7, Аноним (-), 03:30, 08/04/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Если забить на всю чухню с "безопасностью" и писать проги на ассемблере, то любой недобук превратится в мощнейший суперкомпьютер, жаль что этого не будет...
     
     
  • 2.10, User294 (ok), 04:09, 08/04/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > любой недобук превратится в мощнейший суперкомпьютер

    Это мягко говоря совсем не факт. Особенно со столь абсолютистским подходом (даже msdos был на сях в массе своей, если не глючу).

     
  • 2.12, аноним (?), 05:27, 08/04/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >Если забить на всю чухню с "безопасностью" и писать проги на ассемблере,
    >то любой недобук превратится в мощнейший суперкомпьютер, жаль что этого не
    >будет...

    Этого не будет потому что на ассемблере писать проги во-первых, не кроссплатформенно (на этом, вообще, можно закончить), также очень медленно, и получатся они точно менее стабильные безопасные и очень не факт что более эффективные. Вот ты с такими высказываниями, которые говорят о уровне познаний, любой суперкомпьютер превратишь ассемблером в тормознейший недобук.

    C - портабельный ассемблер, вот на нем надо писать. И на C++. А конкурентов у них нет, и в ближайшее время не предвидится.

     
     
  • 3.28, Аноним (-), 12:08, 08/04/2010 [^] [^^] [^^^] [ответить]  
  • –4 +/
    кроссплатформенность это не только возможность запустить свою поделку на пяти-десяти-стапятидесяти разных линуксах. гнутый софт в основной своей массе все равно непортабелен, потому что IS NOT UNIX
     
     
  • 4.48, аноним (?), 22:16, 08/04/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >кроссплатформенность это не только возможность запустить свою поделку на пяти-десяти-стапятидесяти разных линуксах.
    >гнутый софт в основной своей массе все равно непортабелен, потому что
    >IS NOT UNIX

    Такого понятия, как UNIX нет. Есть POSIX, поэтому все портабельно, и работает везде. А вообще речь шла о железных архитектурах, а не операционных системах. Код на ассемблере как таковой с последними вообще никак не связан.

     
     
  • 5.53, pavlinux (ok), 01:33, 09/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Такого понятия, как UNIX нет..

    Это тебя нет, а UNIX это The Single UNIX Specification
    http://www.unix.org/what_is_unix/single_unix_specification.html

     
  • 4.70, User294 (ok), 01:43, 10/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >кроссплатформенность это не только возможность запустить свою поделку на пяти-десяти-
    >стапятидесяти разных линуксах.

    Ну так хорошо написанный код работает на разных системах и архитектурах. А если вы взяли какойнить модуль ядра линукса - ну так никто и не обещал что он заработает с чем-то еще.

     

  • 1.17, anonymous (??), 08:37, 08/04/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > известная польская исследовательница безопасности

    и
    > почему был использован Xen, а не KVM, Джоанна ответила, что она верит в то,

    Хм. То есть все построено на женской интуиции что ли ?
    Круто ;)
    --
    mx

     
     
  • 2.20, XoRe (ok), 09:18, 08/04/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> известная польская исследовательница безопасности
    >

    >> почему был использован Xen, а не KVM, Джоанна ответила, что она верит в то,
    >
    >Хм. То есть все построено на женской интуиции что ли ?
    >Круто ;)
    >--
    >mx

    Скорее на профессиональной интуиции.

     
  • 2.21, develop7 (ok), 09:40, 08/04/2010 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Просто переводчик, скорее всего, дубина. She believes переводится не как «она верит», а «она считает»
     
     
  • 3.22, splat_pack (ok), 09:56, 08/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    не гони на баяниста, играет как умеет :)
     
  • 3.31, pavlinux (ok), 13:23, 08/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Вот в этом вся и прелесть, что "считать" и "верить" в русском
    сильно различны и по произношению и по смыслу.
    А вот инглишь стирает эту грань, и становится ясна суть,
    что расчёты одного индивида  равны его вере в это.
    Так что, её "She Belives" без доказательств равен "I'm Норе" :)

     
     
  • 4.32, Andrey Mitrofanov (?), 13:30, 08/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >равен "I'm Норе" :)

    i believe not. ###Alarm-alarm! Semanic nazi detected!!

     
     
  • 5.33, pavlinux (ok), 13:40, 08/04/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Тогда beliver - это счёты :)
     
  • 5.58, rfc.1118 (?), 02:55, 09/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Semantic.
     
     
  • 6.75, Andrey Mitrofanov (?), 12:46, 10/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Semantic.

    Отож. %) А теперь и граммар до кучи'''

     
  • 4.35, Аноним (-), 13:53, 08/04/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Так что, её "She Belives" без доказательств равен "I'm Норе" :)

    am это уже глагол. Так что I hope, без am

     
     
  • 5.36, konst (??), 14:12, 08/04/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    = she hopes
     
  • 2.23, Аноним (-), 10:57, 08/04/2010 [^] [^^] [^^^] [ответить]  
  • +6 +/
    В PDF-ке по ссылке в новости про то почему выбрали Xen, а не KVM, достаточно подробно написано. В KVM изоляция организована на встроенных в ядро функциях, т.е. изоляции ввода/вывода почти никакой.

    3.2. Xen vs. KVM security architecture comparison

    Most Xen advocates would dismiss KVM immediately by saying that itʼs not a true bare-metal hypervisor, but rather more of a type II hypervisor added on top of (fat and ugly) Linux kernel. The KVM fans would argue that while Xen itself might indeed be much smaller than Linux with KVM, however that itʼs not a fair comparison, because one needs to also count Xenʼs Dom0 code as belonging to TCB, and that Dom0 uses a pretty much regular Linux system, which in the end comes down to pretty comparable code bases we need to trust
    (Linux + KVM vs. Xen + Linux).

    Both of those arguments are oversimplifications, however.
    The thin vs. fat hypervisor argument
    In KVM architecture each VM is just another type of a Linux usermode process. The exception being that such a “VM process” doesnʼt have access to the standard Linux system call interface, but instead can interact with the kernel via VMX or SMX intercepts. In that case the kernel actually becomes the hypervisor for all the VM processes. One should note, however, that the VM hypervisor interface in that case is much simpler than in case of a regular process kernel interface.

    However itʼs not entirely true. Particularly the hypervisor still uses (or is free to use) the whole Linux kernel infrastructure, with all its drivers and internal interfaces. This makes the line between what code in the Linux kernel is, and what is not, used for handling various VM-generated events, to be blurry. This is not the case when we consider a true bare-metal hypervisor like Xen. In Xen, at no point does the execution path jump
    out of the hypervisor to e.g. Dom03 . Everything is contained within the hypervisor.

    Consequently itʼs easier to perform the careful security code audit of the Xen hypervisor, as itʼs clear which code really belongs to the hypervisor.

    At the same time the above argument cannot be automatically transfered to Xenʼs Dom0 code.

    The main reason is that it is possible to move all the drivers and driver backends out of Dom04 . The same is true for moving the IO Device Emulator (ioemu) out of Dom05 .
    The only element (that is accessible to VMs) that must be left in Dom0 is the XenStore daemon, that is responsible for managing a directory of system-wide parameters (e.g. where is each of the backend driver located). That represents a very minimal amount of code that needs to be reviewed.


    The I/O Emulation vs. PV drivers

    KVM uses full virtualization approach for all its virtual machines. This means that every virtual machine in KVM must have an associated I/O emulator. KVM uses the open source qemu emulator for this purpose. In KVM architecture the I/O emulator is running on the host, although as an unprivileged non-root process.

    Xen, on the other hand, allows for both fully virtualized, as well as para-virtualized virtual machines. This offers an option of either removing the I/O emulator completely from the system (in case the user wants to use only PV guests, as they donʼt need an I/O emulation), or to host the I/O emulators in dedicated minimal PV domains. Xen provides even a dedicated mechanism for this, the so called “stub-domains”.

    The I/O emulator is a complex piece of software, and thus it is reasonable to assume that it contains bugs and that it can be exploited by the attacker. In fact both Xen and KVM assume that the I/O emulator can be compromised and they both try to protect the rest of the system from a potentially compromised I/O emulator. They differ, however, in the way the try to protect the system from a compromised I/O emulator.

    KVM uses standard Linux security mechanisms to isolate and contain the I/O emulator process, such as address space isolation and standard ACL mechanisms. Those can be further extended by using e.g. SELinux sandboxing. This means that the isolation quality that KVM provides cannot be significantly better than what a regular Linux kernel can provide to isolate usermode processes6.

    Xen uses virtualization for the I/O emulator isolation, specifically para virtualization, just in the very same way as it is used for regular VM isolation, and doesnʼt relay on Linux to provide any isolation.


    Driver domains support

    A very essential feature for the Qubes OS is the ability to sandbox various drivers, so that even in the case of a bug in a driver, the system could be protected against compromise. One example here could be a buggy WiFi driver or 802.11 stack implementation that could be exploited by an attacker operating at an airport lounge or in a hotel. Another example could be a bug in the disk driver or virtual filesystem backend, that
    could be exploited by the attacker from one of the (lesser-privileged) VM in order to compromise other (more-privileged) VMs.

    In other to mitigate such situations, Qubes architecture assumes existence of several so called driver domains. A driver domain is an unprivileged PV-domain that has been securely granted access to certain PCI device (e.g. the network card or disk controller) using Intel VT-d. This means that e.g. all the networking code (WiFi drivers, stack, TCP/IP stack, DHCP client) is located in an unprivileged domain, rather than in Dom0.

    This brings huge security advantages -- see the specific discussions about network domain and disk domain later in this document.

    KVM, on the other hand, doesnʼt have support for driver domains. One could argue it would be possible to add a support for driver domains (that is for hosting PV driver backends in unprivileged domains) using Linux shared memory, because KVM allows to use VT-d for secure device assignment to unprivileged VMs, but that would probably require substantial coding work. More importantly, because KVM doesnʼt support PV domains, each driver domain would still need to make use of the I/O emulator running on the host. As explained in the previous paragraph, this would diminish the isolation strength of a driver domain on a KVM
    system.

    Summary

    We believe that the Xen hypervisor architecture better suits the needs of our project. Xen hypervisor is very small comparing to Linux kernel, which makes it substantially easier to audit for security problems. Xen allows to move most of the “world-facing” code out of Dom0, including the I/O emulator, networking code and many drivers, leaving very slim interface between other VMs and Dom0. Xenʼs support for driver domain is crucial in Qubes OS architecture.

    KVM relies on the Linux kernel to provide isolation, e.g. for the I/O emulator process, which we believe is not as secure as Xenʼs isolation based on virtualization enforced by thin hypervisor. KVM also doesnʼt support driver domains.


     
  • 2.71, User294 (ok), 01:54, 10/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Хм. То есть все построено на женской интуиции что ли ?
    >Круто ;)

    Вот чему чему а интуиции руткитской :) по части безопасности имхо можно доверять. На ее счету обнаружение нескольких потенциальных дыр в висте, нестандартные фокусы с руткитами юзающими виртуализацию и так далее.В общем то спец своего дела.И вон тут кто-то нафлудил обоснование чем по ее мнению xen защищеннее.Дизайн ее системки оверпараноидален и обладает нехилым оверхедом (достаточно посмотреть на скрине сколько памяти сожрано) но можно отметить и интересные решения.От параноиков для параноиков :).

    p.s. как извеснтно, лучший способ защиты - это нападение. ИМХО есть смысл юзать виртуализацию первым, до того как это сделают хаксоры.Пусть лучше они сношаются с пониманием куда попали, поисками невидимого админа, незаметным мониторингом, откатами снапшотов и прочая чем наоборот когда админ даже и не заметит что у его системы - двойное дно.

     

  • 1.18, Аноним (-), 09:06, 08/04/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    вроде что-то подобное реализовано в ОСВС российской
     
     
  • 2.62, Влад Косичка (?), 14:42, 09/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Эта недоось не реализует ничего кроме несовместимости с 50% написанного командой RedHat и 90% написанного другими (ибо в основе своей использует старую шапку).

    P. S. Да, я видел эту недоось не надо домашненьком компе с работающим Konqueror-ом, а в условиях ее применения по назначению. И не раз, и не два, а больше года.

     
     
  • 3.87, playnet (?), 02:29, 21/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >P. S. Да, я видел эту недоось не надо домашненьком компе с
    >работающим Konqueror-ом, а в условиях ее применения по назначению. И не
    >раз, и не два, а больше года.

    Кто-нибудь, переведите ЭТО на русский... а то перечитал 5 раз, но смысл до меня так и не дошел....

     

  • 1.27, anon1 (?), 11:40, 08/04/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Новость очень интересная (без всяких шуток). Но вот вопрос минимальных системных требований скромно опущен :) Сколько там Xeon'ов нужно чтобы всё это запустить?
     
     
  • 2.30, User294 (ok), 12:31, 08/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Xeon-ов то немного. А вот оперативки... судя по скринам Джоанна придумала куда извести >= 4Gb :)
     
     
  • 3.38, Аноним (-), 14:27, 08/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Xeon-ов то немного. А вот оперативки... судя по скринам Джоанна придумала куда извести >= 4Gb :)

    Xen умеет расшаривать одни и теже данные между несколькими окружениями, поэтому оверхед по памяти не так страшен, как кажется на первый взгляд.

     
     
  • 4.54, pavlinux (ok), 01:36, 09/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >>Xeon-ов то немного. А вот оперативки... судя по скринам Джоанна придумала куда извести >= 4Gb :)
    >
    >Xen умеет расшаривать одни и те же данные между несколькими окружениями, поэтому оверхед
    >по памяти не так страшен, как кажется на первый взгляд.

    Осталось только доказать, что существуют одни и те же данные на уровне страниц.

     
     
  • 5.57, s79 (?), 02:52, 09/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >>>Xeon-ов то немного. А вот оперативки... судя по скринам Джоанна придумала куда извести >= 4Gb :)
    >>
    >>Xen умеет расшаривать одни и те же данные между несколькими окружениями, поэтому оверхед
    >>по памяти не так страшен, как кажется на первый взгляд.
    >
    >Осталось только доказать, что существуют одни и те же данные на уровне
    >страниц.

    а так же что такое расшаривание не нарушает принципы безопасности ради которой все и затевается.

     
     
  • 6.59, pavlinux (ok), 04:18, 09/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >>>>Xeon-ов то немного. А вот оперативки... судя по скринам Джоанна придумала куда извести >= 4Gb :)
    >>>
    >>>Xen умеет расшаривать одни и те же данные между несколькими окружениями, поэтому оверхед
    >>>по памяти не так страшен, как кажется на первый взгляд.
    >>
    >>Осталось только доказать, что существуют одни и те же данные на уровне
    >>страниц.
    >
    >а так же что такое расшаривание не нарушает принципы безопасности ради которой
    >все и затевается.

    Врать не буду, глубоко ещё KSM не изучал, но думается там должно быть расшаривание
    на уровне READ-ONLY ресурсов. Ну как, к примеру, QEMU-клон работает с базовым образом.
    Но это дисковые операции, что там творят с оперативкой, пока не знаю. :)
    Если это не R/O, то это дырень огромная...

     

  • 1.43, JL2001 (ok), 19:48, 08/04/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    тобишь как бы намекают что ядро линукса не в состоянии обеспечить изоляцию одних приложений от других? и что текущая организация большинства линукс-дистрибутивов не обеспечивает изоляцию данных на диске одной программы от другой? и это типа надёжная ось?
     
     
  • 2.44, Аноним (-), 21:23, 08/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >тобишь как бы намекают что ядро линукса не в состоянии обеспечить изоляцию
    >одних приложений от других? и что текущая организация большинства линукс-дистрибутивов не
    >обеспечивает изоляцию данных на диске одной программы от другой? и это
    >типа надёжная ось?

    И как по вашему Linux изолирует допустим OpenOffice.org или Firefox-а от других приложений запустившего их пользователя, если через какую-то непоправленную дыру в этих программах злонамеренный код получит управление ? Изоляция от других пользователей не в счет, в Qubes рассматривается именно изоляция отдельных видов приложений одного пользователя.

     
     
  • 3.50, аноним (?), 22:20, 08/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >И как по вашему Linux изолирует допустим OpenOffice.org или Firefox-а от других
    >приложений запустившего их пользователя, если через какую-то непоправленную дыру в этих
    >программах злонамеренный код получит управление ? Изоляция от других пользователей не
    >в счет, в Qubes рассматривается именно изоляция отдельных видов приложений одного
    >пользователя.

    Запустить их от разных пользователей было бы гораздо легче, и интеграция на одном десктопе была бы из коробки. Значит либо мы имеем дело с "бабой за рулем", либо в Linux действительно не так все хорошо с изоляцией.

     
     
  • 4.52, XoRe (ok), 22:57, 08/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > либо в Linux действительно не так все хорошо с изоляцией.

    Эксплоит накатаете?)

     
     
  • 5.64, JL2001 (ok), 14:57, 09/04/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> либо в Linux действительно не так все хорошо с изоляцией.
    >
    >Эксплоит накатаете?)

    тогда зачем некая баба монстрячит поверх лиункса нечто стрёмномноговиртуальное?

     
     
  • 6.72, User294 (ok), 02:03, 10/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >тогда зачем некая баба монстрячит поверх лиункса нечто стрёмномноговиртуальное?

    Есть разные степени паранои, у Рутковской параноя прокачана, благо, она уже показывала почти невидимый руткит "blue pill" в свое время. Клевый руткитик - становится чем-то типа гипервизора для оси и та не в курсе что ее уже дурят и вертят как хотят ;).Правда в ответ появился детектор руткитов "red pill" от другого исследователя, ловящий этот руткит косвенными методами. Но глядя на blue pill я понимаю причины паранои. Это что-то типа превентивной атаки: в песочнице оказывается хакер а не одмин. Имхо разумно вполне. И да, мелкий гипервизор проаудитить проще чем весь линуксный кернел. В этом кто-то сомневался???

     
  • 4.56, pavlinux (ok), 01:55, 09/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Значит либо мы имеем дело с "бабой за рулем",

    Эта баба нашла и обнародовала метод SMM атаки, используя баги в процах Интель.
    http://invisiblethingslab.com/itl/Resources.html
    > либо в Linux действительно не так все хорошо с изоляцией.

    А где лучше?

     
     
  • 5.65, JL2001 (ok), 14:58, 09/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >> Значит либо мы имеем дело с "бабой за рулем",
    >
    >Эта баба нашла и обнародовала метод SMM атаки, используя баги в процах
    >Интель.
    >http://invisiblethingslab.com/itl/Resources.html
    >> либо в Linux действительно не так все хорошо с изоляцией.
    >
    >А где лучше?

    а это вобще не аргумент

     
  • 5.88, 1 (??), 20:27, 15/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > А где лучше?

    в XTS-400

     
  • 4.60, szh (ok), 06:57, 09/04/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Запустить их от разных пользователей было бы гораздо легче, и интеграция на одном десктопе была бы из коробки. Значит либо мы имеем дело с "бабой за рулем", либо в Linux действительно не так все хорошо с изоляцией.

    мы имеем дело с бабой за рулем в лице тебя.
    доступ к X нужен для всех GUI программ, что убивает изоляцию между ними в обычных дистрибутивах. В X нет никакой изоляции из коробки.

     
     
  • 5.63, JL2001 (ok), 14:57, 09/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >доступ к X нужен для всех GUI программ, что убивает изоляцию между
    >ними в обычных дистрибутивах. В X нет никакой изоляции из коробки.

    чтот я не понял - Х это клиентсерверное решение? так какого это требуется доступ к Х в обход предусмотренного самим Х?

     
     
  • 6.73, User294 (ok), 02:06, 10/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    ну если вам захочется скорости то в ход пойдет shared memory и прочая, очевидно?
     
  • 5.77, Анон (?), 22:15, 11/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Давным давно (99году) для изоляции на уровне XWindow запускал каждое приложения в своем отдельном Xvnc, но через некоторое время надоело.
    Для параноидальных операций, в итоге, оказалось удобнее держать отдельный комп.
     
  • 2.55, pavlinux (ok), 01:45, 09/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >тобишь как бы намекают что ядро линукса не в состоянии обеспечить изоляцию
    >одних приложений от других? и что текущая организация большинства
    > линукс-дистрибутивов не обеспечивает изоляцию данных на диске одной
    > программы от другой? и это типа надёжная ось?

    Запусти 2 скрипта, в одном:

    #!/bin/bash

        while true
             do
               sleep(10);
               echo "Sleep";
        done;

    во втором

    #!/bin/bash

    killall -9 sleep || sleep 1 && killall -9 sleep && killall -9 sleep;


    ------

    Всё пипец, вторая программа нарушила работу первой, галактико вАпасности, Линюкс дырявый!!!!


     
     
  • 3.66, JL2001 (ok), 15:06, 09/04/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    если второе запущено не из под админа и работает - то это писец какая дыра в лине
     
     
  • 4.67, pavlinux (ok), 23:30, 09/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Во-о-о-о-т, а тут не сработает.
     
  • 4.74, User294 (ok), 02:09, 10/04/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >если второе запущено не из под админа и работает - то это
    >писец какая дыра в лине

    В чем дыра? В том что я как юзер могу свои программы стрелять? Так такая "дыра" у всех наверное есть.А вот программы рута например простой юзер ессно убить не сможет (морда треснет).

     
  • 4.80, Sugar (ok), 13:54, 13/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    По-моему, Вы тролль.
     

  • 1.78, Живот (?), 13:49, 13/04/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Какая Джоанна, однако, красотка!
    http://static.diary.ru/userdir/9/1/3/0/913017/39438313.jpg
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру