форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	+/–
Сообщение от opennews (??) on 10-Мрт-16, 21:35
Йоанна Рутковская (http://ru.wikipedia.org/wiki/%D0%A0%D1%8...) (Joanna Rutkowska) представила (http://blog.invisiblethings.org/2016/03/09/qubes-31.html)  выпуск операционной системы Qubes 3.1 (https://wiki.qubes-os.org), реализующей идею (https://www.opennet.dev/opennews/art.shtml?num=34732) использования гипервизора для строгой изоляции приложений и компонентов ОС (каждый класс приложений и системные сервисы  работают в отдельных виртуальных машинах). Для загрузки подготовлены (https://www.qubes-os.org/downloads/) установочный образ (4.7 Гб) и экспериментальный Live USB. Для работы необходима (https://www.qubes-os.org/hcl/) система с 4 Гб ОЗУ и 64-разрядным CPU Intel или AMD, желательно с поддержкой технологий VT-x/AMD-v и VT-d/AMD IOMMU. Приложения в Qubes разделены на классы в зависимости от важности обрабатываемых данных и решаемых задач, каждый класс приложений, а также системные сервисы (сетевая подсистема, работа с хранилищем и т.п.), работают в отдельных виртуальных машинах. При этом указанные приложения бесшовно доступны в рамках одного рабочего стола и выделяются для наглядности разным цветом обрамления окна. Каждое окружение имеет доступ на чтение к базовой корневой ФС и локальному хранилищу, не пересекающемуся с хранилищами других окружений, для организации взаимодействия приложений используется специальный сервис. В качестве основы для формирования виртуальных окружений может применяться (https://www.qubes-os.org/doc/Templates/) пакетная база Fedora и Debian, также сообществом поддерживаются шаблоны для Whonix, Ubuntu и Arch Linux. Пользовательская оболочка построена на основе KDE. Когда пользователь запускает из меню KDE приложение, это приложение стартует в определенной виртуальной машине. Содержание виртуальных окружений определяется набором шаблонов. В каждом виртуальном окружении приложения запускается отдельный X-сервер, упрощённый оконный менеджер и видеодрайвер-заглушка, транслирующий вывод в управляющее окружение в композитном режиме. Основные новшества (https://www.qubes-os.org/doc/releases/3.1/release-notes/): -  Реализован управляющий стек на базе инструментария Salt (https://www.qubes-os.org/doc/salt/), предоставляющий (https://www.qubes-os.org/news/2015/12/14/mgmt-stack/) средства для простой и автоматизированной настройки сложных конфигураций Qubes. Например, для настройки  Whonix в Qubes требуется установить два шаблона, создать две виртуальные машины и задать параметры для их выполнения. Много ручной работы также требуется для настройки  USB VM и Split GPG. Salt берёт на себя работу по созданию и настройке виртуальных машин, позволяя централизованно управлять настройками всех компонентов системы. Пока возможности Salt ограничиваются dom0 и общесистемными настройками, не поддерживая управление начинкой виртуальных машин (в будущих выпусках ожидаются средства установки дополнительных пакетов внутри VM, управления сервисами  и  манипуляции шаблонами); -  При помощи Salt реализован сценарий для быстрого развёртывания системы на базе дистрибутива Whonix. В один клик можно создать VM для шлюза и рабочего окружения  Whonix, настроить прокси и проброс USB-мыши. Напомним, что для обеспечения анонимного выхода в сеть в Whonix предлагается (https://www.opennet.dev/opennews/art.shtml?num=43544) использовать два отдельно устанавливаемых компонента - Whonix-Gateway и Whonix-Workstation. Выход в сеть из окружения Whonix-Workstation производится только через шлюз Whonix-Gateway, что изолирует рабочее окружение от прямого взаимодействия с внешним миром и допускает использование только фиктивных сетевых адресов; -  Улучшен мастер первой установки (firstboot), в котором теперь можно просто выбрать желаемые опции для формирования базовой конфигурации, в том числе создать виртуальные машины для Whonix и USB-стека; <center><a href="http://blog.invisiblethings.org/resources/qubes-31-firstboot... src="https://www.opennet.dev/opennews/pics_base/0_1457633029.png&q... style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center> -  Добавлена поддержка UEFI; -  Сформирована Live-сборка, которая пока имеет качество альфа-выпуска; -  Обновлены видеодрайверы, работающие на стороне dom0; -  В состав включены яркие пиктограммы для идентификации окон приложений; -  Добавлена поддержка PV Grub (https://www.qubes-os.org/doc/managing-vm-kernel/#tocAnchor-1-3), позволяющего использовать ядра Linux, установленные внутри виртуальной машины без копирования их на уровень dom0; -  Наличие готовой для использования виртуальной машины для USB-стека (USB VM), поддерживающей (https://github.com/QubesOS/qubes-app-linux-input-proxy/blob/...) работу с USB-мышами; -  Гипервизор Xen обновлён до выпуска 4.6; <center><a href="https://www.qubes-os.org/attachment/wiki/GettingStarted/r2b1... src="https://www.opennet.dev/opennews/pics_base/0_1457631004.png&q... style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center> <center><a href="https://www.qubes-os.org/attachment/wiki/GettingStarted/snap... src="https://www.opennet.dev/opennews/pics_base/0_1443722348.png&q... style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border="0"></a></center> URL: http://blog.invisiblethings.org/2016/03/09/qubes-31.html Новость: http://www.opennet.dev/opennews/art.shtml?num=44023
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

2. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	–4 +/–
Сообщение от commiethebeastie (ok) on 10-Мрт-16, 21:44
Obscurity is not security.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	+1 +/–
	Сообщение от НоНейм on 10-Мрт-16, 22:41
	Мне одному её фамилия постоянно ассоциируется с "руткит"?
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	4. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	+7 +/–
	Сообщение от Хуан on 10-Мрт-16, 23:11
	да
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	28. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	+/–
	Сообщение от Andrey Mitrofanov on 11-Мрт-16, 09:56
	> Мне одному её фамилия постоянно ассоциируется с "руткит"? Правильный псевдлним! И имя "Иоан", и женщина.  Тролит на 89ом уровне одним ником. [/]
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	29. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	–1 +/–
	Сообщение от НоНейм on 11-Мрт-16, 10:33
	Да, такой ))
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	5. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	+2 +/–
	Сообщение от Анонимо on 10-Мрт-16, 23:21
	> Obscurity is not security. Тогда SSL/GNUPG/TLS - тоже не секурити, т.к. шифрование основано на ограниченности вычислительных мощностей.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	8. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	+6 +/–
	Сообщение от solardiz (ok) on 10-Мрт-16, 23:47
	Во-первых, не в тему. Во-вторых, ошибочно: Есть такая вещь как OPSEC - https://en.wikipedia.org/wiki/Operations_security - например, рассказав здесь о конфигурации одного из своих лаптопов, я чуть-чуть повысил риск направленных атак. Для меня это осознанный риск. Если бы опубликовал выдачу dmesg со всеми серийными номерами и т.п., повысил бы еще чуть-чуть. Выражение security through obscurity имеет своё негативное значение, но правильно употребляется лишь в некоторых контекстах (особенно в отношении дизайна криптографических алгоритмов).
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	35. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	–1 +/–
	Сообщение от Аноним (??) on 11-Мрт-16, 14:43
	Хорошее, правильное мышление. Если известно кто ты и ожидается что атака тебя ведет к чему-то ценному, можно ожидать усиленных, адресных атак. Выполняемых с пониманием кого атакуем и чего хочется достичь. p.s. firejail таки сильно юзабельнее сабжа, хоть и менее прочный.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

6. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	+18 +/–
Сообщение от solardiz (ok) on 10-Мрт-16, 23:24
Недавно тестировал один из 3.1-rc на двух недорогих лаптопах - ASUS K501LB i3-5010U, 8 GB (положительно) и ASUS X551MA N3530, 4 GB (отрицательно, выглядит поправимо напильником, но в любом случае на 4 GB будет тесно). Для загрузки с LiveUSB, и там и там требовалось отключить поддержку USB 3.0 (XHCI) в BIOS setup - известный разработчикам Qubes баг, просто нет драйвера XHCI внутри образа initramfs. Пока не знаю исправили ли его в релизе. Эта проблема затрагивает (затрагивала?) только live-систему. В установленной системе такой проблемы нет, с USB 3.0 работает нормально. На K501LB подхватилось всё железо - из коробки работают в том числе такие вещи как suspend (просыпается нормально) и регулировка подсветки клавиатуры, не говоря уже о более важных (на удивление старые/проверенные WiFi Atheros AR5B22-SB, Ethernet Realtek RTL8168/8111, HDMI-выход, звук, яркость экрана). Дискретная графика (NVIDIA 940M) работает с драйвером nouveau до тех пор пока не пытаешься запустить что-нибудь с 3D - тогда виснет. После blacklist'а nouveau, работает с Intel'овой и уже не виснет, но дает где-то 5 FPS для процесса (например, Firefox с blend4web), запущенного внутри одной из VM'ок. Тормозов 2D графики не ощущается - субъективно, работает как и в системе без виртуализации - прокрутка плавная и т.д. Время установки не радует - около 25 минут с быстрой флешки (~30 MB/s) на Samsung 850 EVO SSD (~500 MB/s), добавленный в слот M.2 упомянутого K501LB (судя по top во время установки, думаю на HDD ставилось бы почти столько же, т.к. то и дело тормозит об процессор). Поставленная "по умолчанию" система занимает около 15 GB. Время загрузки системы - около минуты (субъективно). Время старта новой VM - около 12 секунд. Всё это - с шифрованного корневого раздела (надеюсь, используется AES-NI). Процессор в данном K501LB минимальный(?) для этой серии - i3-5010U, это 2-х ядерный Broadwell с HT, но без turbo. В под-варианты того же K501LB чуть подороже ставят i5-5200U, который с turbo, и может дать скорость процентов на 20-30 выше (2.7 GHz vs. 2.1 GHz). Медленное время холодного старта компенсируется быстрым стартом процессов в уже один раз запущенных VM - повторно Firefox в VM стартует почти сразу (меньше секунды?), не говоря уже о чем-то полегче вроде терминала в VM, который стартует моментально. Наверное, работающий suspend здесь окажется полезен. Если вдруг кто захочет такой лаптоп (под Qubes или еще как), за свою цену (чуть больше 40 тыс. руб. или $550, не считая добавляемого самостоятельно SSD) по-моему он неплох. Думаю, это близко к минимально-разумной конфигурации лаптопа для Qubes. (Дискретная графика лишняя, но подходящих вариантов лаптопов без нее толком нет.) Я не знаю во всех ли вариантах ставят упомянутый Atheros - думаю, это как повезет (в любом случае, этот модуль можно поменять). Вес 1.9 кг (для 15.6" хорошо), зарядник 240 гр включая провод, заряда хватает часа на 3.5. Основные недостатки: плохая матрица (углы обзора, цвета), то и дело включается и слегка шумит один из кулеров без серьезных на то оснований. Лаптопы с 4-ядерными Broadwell'ами обычно имеют и более мощную дискретную графику, что тащит за собой мощный зарядник в 600+ гр и суммарно выходит 2.7+ кг.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	7. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 10-Мрт-16, 23:39
	Спасибо, обстоятельно.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	9. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	+/–
	Сообщение от Константавр (ok) on 11-Мрт-16, 00:38
	Ну, то, что для работы Qubes требуется 4 гига памяти и 64-битный проц - эта "шапка" новости, видать завалялась на опеннете с тех пор, когда Qubes только появилась и 4гига - это было ещё круто. С тех пор прошло много лет и теперь простой линукс может тормозить на 4ёх гигах, не то, что обвешенный плюшками. А вот насчёт карточки Nvidia, она вообще не работает там? Или просто не сильно углублялись в вопрос? Хотя, в такой фарш запихнуть ещё и оптимус, нетривиальная, должно быть, задача.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	14. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	+2 +/–
	Сообщение от solardiz (ok) on 11-Мрт-16, 02:10
	> Ну, то, что для работы Qubes требуется 4 гига памяти и 64-битный проц Это всё еще соответствует действительности. На 4 GB Qubes можно использовать, но будет тесновато. Он не станет тормозить, но максимальное количество VM'ок и суммарный размер приложений в них будут маловаты. Думаю, для некоторых применений это может быть нормальной конфигурацией. Будет помогать то, что там есть менеджер памяти, который динамически регулирует выделяемые VM'ам объемы - кстати, когда-то его не было, и, думаю, старые версии Qubes, о которых были первые новости здесь, работали на 4 GB хуже, чем текущая. Помимо объема памяти, второй лаптоп хуже подходил и процессором - отсутствует VT-d (который не является обязательным для Qubes, но желателен), отсутствует AES-NI (было бы медленно работать с шифрованного раздела), да и просто каждое ядро медленнее (Silvermont 2.58 GHz медленнее, чем Broadwell 2.1 GHz), хотя их там и 4 (на лаптопе, даже с VM'ами, редко бывает загрузка больше чем на 2 ядра, поэтому лучше сравнительно быстрые 2, чем суммарно обгоняющие 4). А одна из причин почему Qubes там не пошел была в конкретных устройствах, видимых на PCI шине. Так что в этом плане отличие между лаптопами в good luck vs. bad lack. > теперь простой линукс может тормозить на 4ёх гигах Сам по себе, нет. > А вот насчёт карточки Nvidia, она вообще не работает там? Работает, пока nouveau не запрещен. Кстати, я неправильно написал как будто любое 3D ее вешает - например, torcs просто медленно шевелится в VM'ке, а вот blend4web вешает. Драйвер nouveau мне вообще представляется нестабильным, и не только на этом чипе, и без Qubes. К сожалению. После blacklist'а nouveau, и то и другое медленно шевелится на Intel'е (кажется, чуть быстрее, чем с nouveau) и не вешает. Можно ставить проприетарный драйвер nvidia и даже пробрасывать доступ к GPU в VM (а VT-d может снизить риск от этого), но я не пробовал. Это частично идет вразрез с выбором Qubes. > Или просто не сильно углублялись в вопрос? Да, не сильно.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	25. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	+1 +/–
	Сообщение от Константавр (ok) on 11-Мрт-16, 09:40
	Ну, про память, это сильно зависит от применения, да, ядро само по себе уютно вертится, а вот приложениям частенько не хватает. А про GPU - прочитал на ихней вике, что OpenGL в виртуалках не предвидится по соображениям безопасности. Ну, собсно, не для того и предназначен дистрибутив. Спасибо за пространный ответ, Вы сэкономили мне много времени :)
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	34. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	+1 +/–
	Сообщение от Khariton (ok) on 11-Мрт-16, 13:06
	Хороший обзор. А отдельная виртуализация работает в Кубах? Например VirtualBox, VmWare, KVM, Qemu? И по поводу 3Д, я понял что все очень плохо. Либо не работает вообще, либо частично и медленно. А как с аппаратным ускорением при просмотре HD фильмов?
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	48. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	+1 +/–
	Сообщение от solardiz (ok) on 13-Мрт-16, 17:46
	> А отдельная виртуализация работает в Кубах? Например VirtualBox, VmWare, KVM, Qemu? Насчет перечисленных не знаю (вернее, QEMU точно сможет работать как минимум в режиме эмуляции, но вопрос наверняка не об этом). Работает полная виртуализация средствами Xen - в частности, так запускают Windows под Qubes: https://www.qubes-os.org/doc/hvm-create/ https://www.qubes-os.org/doc/windows-appvms/ > И по поводу 3Д, я понял что все очень плохо. Либо не > работает вообще, либо частично и медленно. При использовании Intel'овой встроенной графики, всё работает полностью (хотя я мало что тестировал). Но медленно. Вероятно, без задействования (встроенного) GPU. При этом в dom0 для window manager'а аппаратное ускорение доступно - для всякого там плавного сворачивания/разворачивания окон и т.п. > А как с аппаратным ускорением при просмотре HD фильмов? Думаю, так же (плохо). Видео обычного разрешения с YouTube смотрятся без проблем, HD я не пробовал. Возможен проброс GPU в VM (и тогда должно работать быстро): https://www.qubes-os.org/doc/user-faq/#can-i-run-application... Вот кто-то успешно пробросил AMD'шные GPU в Windows 7 в HVM под Qubes: https://groups.google.com/forum/#!topic/qubes-users/cmPRMOkxkdA
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

10. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	+/–
Сообщение от Вареник on 11-Мрт-16, 01:46
Раньше это назвали бы "микрядерной архитектурой" со строгими ограничениями, а теперь - "гипервизор", "виртуализация процессов".
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	12. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	–1 +/–
	Сообщение от Анонимо on 11-Мрт-16, 01:56
	+1 ещё 10 лет назад я ломал копья на опеннете же по поводу перспективности архитектуры микроядра (хотя и приходилось любить линух за функциональность). Радостно, что время таки расставляет всё по местам.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	16. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	+/–
	Сообщение от solardiz (ok) on 11-Мрт-16, 02:47
	> ещё 10 лет назад я ломал копья на опеннете же по поводу > перспективности архитектуры микроядра 10 лет назад, с точки зрения безопасности, микроядро на PC-архитектуре было не нужно. Оно было нужно 20+ лет назад, когда диски и сетевушки работали с PIO, а не с DMA, и оно нужно теперь, когда в процессорах начали появляться IOMMU: http://theinvisiblethings.blogspot.ru/2010/05/on-formally-ve... "Without IOMMU there is no security benefit of having a microkernel vs. having a good-old monolithic kernel. Let me repeat this statement again: there is no point in building a microkernel-based system, if we don't correctly use IOMMU to sandbox all the drivers." А Qubes всё-таки в основном не о драйверах (хотя и это тоже, для NetVM и не только, при наличии IOMMU), а о VM'ах с приложениями. Поэтому есть смысл использовать Qubes даже на процессорах без IOMMU.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	17. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	+/–
	Сообщение от Анонимо on 11-Мрт-16, 03:32
	> 10 лет назад, с точки зрения безопасности, микроядро на PC-архитектуре было не > нужно. Оно было нужно 20+ лет назад, когда диски и сетевушки > работали с PIO, а не с DMA, и оно нужно теперь, > когда в процессорах начали появляться IOMMU: Смотрю несколько иначе. Разграничить доступность коду только определённой областью доступа было нужно и вчера и сегодня, и будет нужно всегда. И дрова устройств - лишь частный случай такого кода. (а у x86 процов, кстати, есть аж 4 уровня защиты (protectiong rings) в защищённом режиме, и в самых распространённых ядрах/осях почему-то 2 средних были не у дел... а ведь это потенциал безопасности...) > "Without IOMMU there is no security benefit of having a microkernel vs. > having a good-old monolithic kernel. Несколько голословно (но текст я прочитать не асилил). Попробую взять логически. Есть монолит ядро, и в нём есть драйвер сетевухи. Этот драйвер может причинить много "пользы" внутри всего ядра, ибо монолит. Если же сей код ограничить каким-то пространством доступа - то безопасности: * добавится? * убавится? * не изменится? Думаю, ответ очевиден. Следовательно, "no security benefit" != true Если брать пример код на пользовательском уровне - то если одна прога не сможет иметь доступа к файлам другой - то это ли не добавляет безопасности? - Добавляет. Именно это и достигается в этой Qubes OS. > А Qubes всё-таки в основном не о драйверах (хотя и это тоже, > для NetVM и не только, при наличии IOMMU), а о VM'ах > с приложениями. Поэтому есть смысл использовать Qubes даже на процессорах без > IOMMU. Естественно. Но в том то и дело, что драйвера-недрайвера - это чисто субъективный стереотип, навязанный монолитным ядром. Как насчёт драйвера мыльного аккаунта (Thunderbird)? Или приложения для фильтрации траффика (modprobe xtables)? И то, и другое - код. И то, и другое источник угроз безопасности. И то, и другое можно и нужно изолировать, предоставляя доступ лишь к необходимым для работы ресурсам. А то, что там "под капотом" у прокладки "разговора" с железом (PIO, DMA, IOMMU) - это уже нюансы. У микроядра всё равно есть некоторая базовая часть-загрузчик-менеджер (собственно, МИКРО-ядро). И если нет IOMMU, то в помощь приложениям-драйверам будет подсистема ввода-вывода в этом микроядре (точно также, как и управление памятью тоже будет там). Приложения-дрова делают запрос/ответ об I/O не сами, а просят об этом микроядро. Медленнее, чем монолит, но профит очевиден.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	18. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	+1 +/–
	Сообщение от solardiz (ok) on 11-Мрт-16, 04:37
	> Разграничить доступность коду только определённой областью доступа > было нужно и вчера и сегодня, и будет нужно всегда. Да, но не для кода драйверов, либо с точки зрения защиты от классов атак, не приводящих сразу к выполнению произвольного кода, либо как hardening, а не как надежный механизм защиты. Если же произвольный код уже выполняется, то при доступе такого кода к устройству, поддерживающему DMA, и отсутствии IOMMU, через это устройство можно ограничение на доступ к определенной области памяти обойти (попросить устройство записать/считать куда/откуда хочется). Но я согласен, что Joanna излишне категорична в процитированном мной утверждении. > И дрова устройств - лишь частный случай такого кода. Да. > (а у x86 процов, кстати, есть аж 4 уровня защиты (protectiong rings) в защищённом > режиме, и в самых распространённых ядрах/осях почему-то 2 средних были не > у дел... а ведь это потенциал безопасности...) По-моему, потенциала там почти нет. Два разных ring 3 процесса (или нити в микроядре) могут быть разделены друг от друга не хуже, чем будучи на разных кольцах. Раз кольца есть, ими можно пользоваться, но и без них было бы почти так же. Вот о моем опыте применения ring 2 не по назначению, и еще о кольцах на не-x86: https://www.linux.org.ru/news/hardware/11636749#comment-1163... > Несколько голословно (но текст я прочитать не асилил). Попробую взять логически. > Есть монолит ядро, и в нём есть драйвер сетевухи. Этот драйвер может > причинить много "пользы" внутри всего ядра, ибо монолит. > Если же сей код ограничить каким-то пространством доступа - то безопасности: > * добавится? > * убавится? > * не изменится? > Думаю, ответ очевиден. Следовательно, "no security benefit" != true Ответ не очевиден. С точки зрения перфекциониста, если драйвер всё равно может запросить у сетевухи DMA куда угодно, "не изменится". С точки зрения практика, скорее всего, "добавится", т.к. атаки станут сложнее, а более сложное менее надежно, что приведет к тому что меньший их процент достигнет успеха на конкретных системах в конкретных обстоятельствах. Также, часть классов атак и раньше не достигали бы выполнения произвольного кода сразу, и они могут оказаться полностью нейтрализованы. Возможно также, что безопасность "убавится", если реализация этого ограничения привнесет сложность в ядро, вместе с дополнительными багами. В целом, я обычно за hardening, но "за" и "против" надо оценивать. > Как насчёт драйвера мыльного аккаунта (Thunderbird)? > Или приложения для фильтрации траффика (modprobe xtables)? > И то, и другое - код. И то, и другое источник угроз > безопасности. И то, и другое можно и нужно изолировать, предоставляя доступ > лишь к необходимым для работы ресурсам. Да. > А то, что там "под капотом" у прокладки "разговора" с железом (PIO, > DMA, IOMMU) - это уже нюансы. У микроядра всё равно есть > некоторая базовая часть-загрузчик-менеджер (собственно, МИКРО-ядро). И если нет IOMMU, > то в помощь приложениям-драйверам будет подсистема ввода-вывода в этом микроядре (точно > также, как и управление памятью тоже будет там). Приложения-дрова делают запрос/ответ > об I/O не сами, а просят об этом микроядро. Медленнее, чем > монолит, но профит очевиден. Часть проблемы в том, что то, как к конкретному устройству делать запрос об I/O, отличается между устройствами, а значит плохо ложится в такую универсальную прослойку - она снова становится "монолитным ядром", содержащим в себе кусочки кода, специфичные для драйверов разных устройств. Фактически мы получаем разграничение привилегий между частями каждого отдельного драйвера. Наверное, это можно реализовать хорошо, сильно убавив размер этой монолитной прослойки по сравнению с общим размером ядра. P.S. Вижу, кто-то тут "заминусовал" сообщения выше по треду. По-моему, у нас нормальная дискуссия по теме, и минусы тут ни к чему, т.к. все сообщения являются "сигналом", а не "шумом", несмотря на чуточку разные мнения.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	20. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	–1 +/–
	Сообщение от Анонимо on 11-Мрт-16, 07:24
	> Если же произвольный код уже выполняется, то при доступе такого кода к > устройству, поддерживающему DMA, и отсутствии IOMMU, через это устройство можно ограничение > на доступ к определенной области памяти обойти (попросить устройство записать/считать > куда/откуда хочется). А вот не совсем... см. ниже > По-моему, потенциала там почти нет. Два разных ring 3 процесса (или нити > в микроядре) могут быть разделены друг от друга не хуже, чем > будучи на разных кольцах. Раз кольца есть, ими можно пользоваться, но > и без них было бы почти так же. Ну, вобщем, да. > Часть проблемы в том, что то, как к конкретному устройству делать запрос > об I/O, отличается между устройствами, а значит плохо ложится в такую > универсальную прослойку - она снова становится "монолитным ядром", содержащим в себе > кусочки кода, специфичные для драйверов разных устройств. Счас посмотрел как работает DMA контроллер. Ему в спец. регистр пишется адрес в памяти, куда надо сгружать инфу. Т.е. где, как и в каком формате в DMA запросе проезжает адрес в памяти - чётко детерминировано. А потому, эта I/O-прослойка будет элементарной. А чтобы в регистр адреса не писали чего попало - сделать фильтр в I/O-фильтре микроядра, который бы смотрел: есть право доступа у этого драйвера к этой области этой длины или нет (раздачу памяти всё так же контролирует базовая микро-часть). > P.S. Вижу, кто-то тут "заминусовал" сообщения выше по треду. По-моему, у нас > нормальная дискуссия по теме, и минусы тут ни к чему, т.к. > все сообщения являются "сигналом", а не "шумом", несмотря на чуточку разные > мнения. Видать сторонники Торвальдса в данном вопросе. Фанаты-маньяки монолита :)
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	38. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	+2 +/–
	Сообщение от ОШИБКА Отсутствуют данные в поле Name on 11-Мрт-16, 15:05
	> Т.е. где, как и в каком формате в DMA запросе проезжает адрес > в памяти - чётко детерминировано. А потому, эта I/O-прослойка будет элементарной. А теперь повтори смотрение на DMA-контроллеры всех архитектур поддерживаемых Linux. Начни с ARM, MIPS и PowerPC, потом поговорим о простоте прослойки. И не забудь узнать кто такой (PCI) bus master и чего может. > в I/O-фильтре микроядра, Устройства которые bus master - могут к памяти обращаться сами. Драйвер может попросить свое устройство сделать запрос как надо, анализировать все такие варианты путем анализа всех существующих протоколов драйвер-устройство нереально, придется в фильтр включить все драйверы устройств. Поэтому сделали IOMMU. Как MMU, но не со стороны процессора, а со стороны чипсета, так что обращения bus masters фильтруются железом наподобие того как MMU это делает со стороны процессора.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	41. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	+/–
	Сообщение от Анонимо on 11-Мрт-16, 16:11
	> А теперь повтори смотрение на DMA-контроллеры всех архитектур поддерживаемых Linux. Начни > с ARM, MIPS и PowerPC, потом поговорим о простоте прослойки. Простота тоже относительна. Относительно решаемой задачи - секурити без компромисов. > И не забудь узнать кто такой (PCI) bus master и чего может. Дань скорости, наследие прошлого... > Устройства которые bus master - могут к памяти обращаться сами. Ну что ж, если железо против безопасности - софтом тяжко всё исправить. > Поэтому сделали IOMMU. Как MMU, но не со стороны процессора, а со стороны чипсета Ну, логичный шаг. Т.е. всё-таки имеет место тенденция к разграничению областей доступа. И микроядро придёт в любом случае.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	49. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	+/–
	Сообщение от Аноним (??) on 16-Мрт-16, 02:18
	> Простота тоже относительна. Относительно решаемой задачи - секурити без компромисов. Безопаснее всего - не включать. Или хотя-бы к сети не подключаться, но там уже возможны варианты. Ты включаешь x86 компьютер. Что происходит? Management Engine - слышал? Прошивка подписана Intel, ее нельзя удалить: шатдаун через 30 мин. ME может использовать сеть чипсета, в обход ОС, делать DMA и проч. Даже ОС переставить можно. Исходники ME firmware - где? Подробнее - на сайте libreboot. Мало? Почитай про SMI. А equation умеет прошивку HDD патчить. > Дань скорости, наследие прошлого... В настоящем еще интереснее. В современном х86 компьютере есть с десяток служебных процессоров разной степени опасности. Тебе синюю или красную? > Ну что ж, если железо против безопасности - софтом тяжко всё исправить. Железо в x86 нашпиговано сюрпризами. > Т.е. всё-таки имеет место тенденция к разграничению областей доступа. Да. Но "без компромиссов" там и близко нет, а сколь-нибудь приличный уровень безопасности при наличии выхода в сеть обеспечить - та еще задача. Большинство софта вообще не писалось с security in mind, монолитные ядра в этом плане далеко не хучшие. > И микроядро придёт в любом случае. Смотря куда придет. Торвальдс начинал писать Linux на Minix, не став дожидаться когда Hurd допишут. Прошла четверть века - кто и где?
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	42. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	+/–
	Сообщение от Анонимо on 11-Мрт-16, 16:12
	Да, спасибо за ликбез! И картину прояснили и время сэкономили!
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

11. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	–1 +/–
Сообщение от Kodir (ok) on 11-Мрт-16, 01:51
Изначально тупая затея. Проблема защиты - далеко не высота забора между процессами, а сам принцип, что приложения генерируют файлы - именно так вирус может спокойно бродить по системам, будь они хоть стократно завёрнуты в контейнеры. Написал док-файл, отослал другу - вот тебе транспорт, дорогой вирус! Бороться с этим нереально, это сам принцип взаимодействия людей.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	13. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	–1 +/–
	Сообщение от Анонимо on 11-Мрт-16, 01:58
	Соц. инженерия конечно, объемлет техническую безопасность (если все будут идиотами - никакие секурити не помогут). Но при вынесении соц. вопроса за скобки - чем больше преград при той же пользовательской функциональности - тем секурнее.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	37. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	+/–
	Сообщение от Вы забыли заполнить поле Name on 11-Мрт-16, 14:51
	> Но при вынесении соц. вопроса за скобки - чем больше преград при > той же пользовательской функциональности - тем секурнее. Количество преград не помешало comodohacker захватить аккаунт админа active directory в diginotar, после чего компании осталось только заявить о банкротстве - после этого ВСЕ виндовые машины следует считать скомпрометированными.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	15. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	+1 +/–
	Сообщение от solardiz (ok) on 11-Мрт-16, 02:29
	> Написал док-файл, отослал другу - вот тебе транспорт, дорогой вирус! > Бороться с этим нереально, это сам принцип взаимодействия людей. Разграничивать реально. При правильном использовании Qubes, файл от друга будет получен в Personal VM, и не попадет в Work VM и Banking VM. Еще один подход - переработка таких файлов в безопасное представление во временном Disposable VM: http://theinvisiblethings.blogspot.ru/2013/02/converting-unt...
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	39. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	–1 +/–
	Сообщение от Имя on 11-Мрт-16, 15:09
	Временные контейнеры как-то сильно менее ресурсоемки. Хотя и менее прочны. Зато firejail-ом создаются в любом современном linux на раз-два. Хороший способ укрепить повседневную систему на всякий случай.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	47. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	–1 +/–
	Сообщение от Michael Shigorin (ok) on 13-Мрт-16, 00:37
	> Временные контейнеры как-то сильно менее ресурсоемки. Хотя и менее прочны. > Зато firejail-ом создаются в любом современном linux на раз-два. http://ftp.altlinux.org/pub/people/ldv/hasher/thesis-2005.html :)
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	50. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	+/–
	Сообщение от Аноним (??) on 16-Мрт-16, 03:45
	Firejail-ом удобно пользоваться для именно изоляции программ на десктопе. Пример: firejail --name=browser --shell=none --net=wlan0 --ip=192.168.120.3/24 firefox Поместит "firefox" в контейнер с урезанной и readonly системой, пустым home, где только downloads, 3 процесса и 1 пользователь (private namespaces), stateless /var. С отдельной сетью. Сделав временный macvlan на wlan0 с новым IP, создав namespaces, урезав сисколы SECCOMP, собрав виртуальную иерархию фс из настоящей. Сеть увидит новую машину на 192.168.120.3/24. Это 1 короткой командой. Временный /var, сетевой интерфейс и проч при выходе из браузера перестанут существовать. Для пользователя это временная сверхлегкая виртуалка из частей хоста. Как cubeos, только легкое, но менее прочное. На самом деле это и голый системд может, firejail интересен готовыми профилями и тем что сам делает типовые операции. Они сделали контейнеры правильно.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

21. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	–1 +/–
Сообщение от DmA (??) on 11-Мрт-16, 08:40
>VT-d/AMD IOMMU Щаз, одни материнские платы чего стоят с поддержкой этой технологии.., не говоря уж о процессорах.Да и памяти там сильно желательно хотя бы 16 ГБ ОЗУ.Лучше 32. Да никто не спорит,что 32 лучше,чем 16 :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

22. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	–1 +/–
Сообщение от Sunderland93 (ok) on 11-Мрт-16, 08:50
Извиняюсь за оффтоп. Подскажите, как сделать чтобы окна раскрашивались в цвета приложения, как на последнем скрине?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	24. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	+2 +/–
	Сообщение от Идиот on 11-Мрт-16, 09:20
	Это индикатор AppVM в котором запущен процесс. Тоесть чисто qubes'овская штука, и то что там случайно совпали цвета - это совпадение.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

23. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	–1 +/–
Сообщение от DmA (??) on 11-Мрт-16, 08:52
Чего люди не придумают,лишь бы не писать правила для SeLinux :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	26. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	–1 +/–
	Сообщение от Онаним on 11-Мрт-16, 09:43
	Как с помощю SeLinux заблокировать доступ в Интернет для определённой программы? Если она нативная? Если она на Java?
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	33. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	+1 +/–
	Сообщение от Khariton (ok) on 11-Мрт-16, 12:56
	в селинукс писать правила для каждого приложения сложно. в Apparmor проще. мало того можно обучать его доступам для нужной вам программы. да и доступ к сети контролируется просто. Смотрите в мануале раздел Network rules. http://wiki.apparmor.net/index.php/AppArmor_Core_Policy_Refe...
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	45. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	+/–
	Сообщение от commiethebeastie (ok) on 12-Мрт-16, 14:02
	> в селинукс писать правила для каждого приложения сложно. > в Apparmor проще. мало того можно обучать его доступам для нужной вам > программы. > да и доступ к сети контролируется просто. Смотрите в мануале раздел Network > rules. > http://wiki.apparmor.net/index.php/AppArmor_Core_Policy_Refe... В selinux тоже обучение появилось.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	40. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	+/–
	Сообщение от Аноним (??) on 11-Мрт-16, 15:11
	> Чего люди не придумают,лишь бы не писать правила для SeLinux :) вот firejail придумали - тот же результат, только за 2 минуты времени, не говоря уж о том что selinux отключает любой уважающий себя эксплойт первым же делом.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	43. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	+/–
	Сообщение от Анонимо on 11-Мрт-16, 16:15
	> вот firejail придумали - тот же результат, только за 2 минуты времени, > не говоря уж о том что selinux отключает любой уважающий себя > эксплойт первым же делом. Спасибо за ссылку. Действительно, вполне годная реализация seccomp'а
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

30. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	+/–
Сообщение от Аноним (??) on 11-Мрт-16, 10:44
Персистентность планируется?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	46. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	+1 +/–
	Сообщение от solardiz (ok) on 12-Мрт-16, 20:45
	> Персистентность планируется? В Qubes есть как постоянные, так и временные VM. Показанные на большинстве скриншотов как раз постоянные. Т.е., например, я поставил Adobe Flash в Untrusted VM, и теперь он там просто есть.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

44. "Релиз ОС Qubes 3.1, использующей виртуализацию для изоляции ..."	–2 +/–
Сообщение от Аноним (??) on 11-Мрт-16, 18:49
Изоляция приложений, какой она не должна быть. Вместо того чтобы сделать хотя бы как в ведроиде.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема