Йоанна Рутковская (http://ru.wikipedia.org/wiki/%D0%A0%D1%8... (Joanna Rutkowska) представила (http://blog.invisiblethings.org/2016/03/09/qubes-31.html)&nb...выпуск операционной системы 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... позволяющего использовать ядра 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
Obscurity is not security.
Мне одному её фамилия постоянно ассоциируется с "руткит"?
да
> Мне одному её фамилия постоянно ассоциируется с "руткит"?Правильный псевдлним! И имя "Иоан", и женщина. Тролит на 89ом уровне одним ником. [/]
Да, такой ))
> Obscurity is not security.Тогда SSL/GNUPG/TLS - тоже не секурити, т.к. шифрование основано на ограниченности вычислительных мощностей.
Во-первых, не в тему. Во-вторых, ошибочно:Есть такая вещь как OPSEC - https://en.wikipedia.org/wiki/Operations_security - например, рассказав здесь о конфигурации одного из своих лаптопов, я чуть-чуть повысил риск направленных атак. Для меня это осознанный риск. Если бы опубликовал выдачу dmesg со всеми серийными номерами и т.п., повысил бы еще чуть-чуть.
Выражение security through obscurity имеет своё негативное значение, но правильно употребляется лишь в некоторых контекстах (особенно в отношении дизайна криптографических алгоритмов).
Хорошее, правильное мышление. Если известно кто ты и ожидается что атака тебя ведет к чему-то ценному, можно ожидать усиленных, адресных атак. Выполняемых с пониманием кого атакуем и чего хочется достичь.p.s. firejail таки сильно юзабельнее сабжа, хоть и менее прочный.
Недавно тестировал один из 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+ кг.
Спасибо, обстоятельно.
Ну, то, что для работы Qubes требуется 4 гига памяти и 64-битный проц - эта "шапка" новости, видать завалялась на опеннете с тех пор, когда Qubes только появилась и 4гига - это было ещё круто. С тех пор прошло много лет и теперь простой линукс может тормозить на 4ёх гигах, не то, что обвешенный плюшками.А вот насчёт карточки Nvidia, она вообще не работает там? Или просто не сильно углублялись в вопрос? Хотя, в такой фарш запихнуть ещё и оптимус, нетривиальная, должно быть, задача.
> Ну, то, что для работы 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.
> Или просто не сильно углублялись в вопрос?
Да, не сильно.
Ну, про память, это сильно зависит от применения, да, ядро само по себе уютно вертится, а вот приложениям частенько не хватает.А про GPU - прочитал на ихней вике, что OpenGL в виртуалках не предвидится по соображениям безопасности. Ну, собсно, не для того и предназначен дистрибутив.
Спасибо за пространный ответ, Вы сэкономили мне много времени :)
Хороший обзор.
А отдельная виртуализация работает в Кубах? Например VirtualBox, VmWare, KVM, Qemu?
И по поводу 3Д, я понял что все очень плохо. Либо не работает вообще, либо частично и медленно.
А как с аппаратным ускорением при просмотре HD фильмов?
> А отдельная виртуализация работает в Кубах? Например 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
Раньше это назвали бы "микрядерной архитектурой" со строгими ограничениями, а теперь - "гипервизор", "виртуализация процессов".
+1ещё 10 лет назад я ломал копья на опеннете же по поводу перспективности архитектуры микроядра (хотя и приходилось любить линух за функциональность). Радостно, что время таки расставляет всё по местам.
> ещё 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.
> 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 не сами, а просят об этом микроядро. Медленнее, чем монолит, но профит очевиден.
> Разграничить доступность коду только определённой областью доступа
> было нужно и вчера и сегодня, и будет нужно всегда.Да, но не для кода драйверов, либо с точки зрения защиты от классов атак, не приводящих сразу к выполнению произвольного кода, либо как 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. Вижу, кто-то тут "заминусовал" сообщения выше по треду. По-моему, у нас нормальная дискуссия по теме, и минусы тут ни к чему, т.к. все сообщения являются "сигналом", а не "шумом", несмотря на чуточку разные мнения.
> Если же произвольный код уже выполняется, то при доступе такого кода к
> устройству, поддерживающему DMA, и отсутствии IOMMU, через это устройство можно ограничение
> на доступ к определенной области памяти обойти (попросить устройство записать/считать
> куда/откуда хочется).А вот не совсем...
см. ниже
> По-моему, потенциала там почти нет. Два разных ring 3 процесса (или нити
> в микроядре) могут быть разделены друг от друга не хуже, чем
> будучи на разных кольцах. Раз кольца есть, ими можно пользоваться, но
> и без них было бы почти так же.Ну, вобщем, да.
> Часть проблемы в том, что то, как к конкретному устройству делать запрос
> об I/O, отличается между устройствами, а значит плохо ложится в такую
> универсальную прослойку - она снова становится "монолитным ядром", содержащим в себе
> кусочки кода, специфичные для драйверов разных устройств.Счас посмотрел как работает DMA контроллер. Ему в спец. регистр пишется адрес в памяти, куда надо сгружать инфу.
Т.е. где, как и в каком формате в DMA запросе проезжает адрес в памяти - чётко детерминировано. А потому, эта I/O-прослойка будет элементарной.А чтобы в регистр адреса не писали чего попало - сделать фильтр в I/O-фильтре микроядра, который бы смотрел: есть право доступа у этого драйвера к этой области этой длины или нет (раздачу памяти всё так же контролирует базовая микро-часть).
> P.S. Вижу, кто-то тут "заминусовал" сообщения выше по треду. По-моему, у нас
> нормальная дискуссия по теме, и минусы тут ни к чему, т.к.
> все сообщения являются "сигналом", а не "шумом", несмотря на чуточку разные
> мнения.Видать сторонники Торвальдса в данном вопросе. Фанаты-маньяки монолита :)
> Т.е. где, как и в каком формате в DMA запросе проезжает адрес
> в памяти - чётко детерминировано. А потому, эта I/O-прослойка будет элементарной.А теперь повтори смотрение на DMA-контроллеры всех архитектур поддерживаемых Linux. Начни с ARM, MIPS и PowerPC, потом поговорим о простоте прослойки. И не забудь узнать кто такой (PCI) bus master и чего может.
> в I/O-фильтре микроядра,
Устройства которые bus master - могут к памяти обращаться сами. Драйвер может попросить свое устройство сделать запрос как надо, анализировать все такие варианты путем анализа всех существующих протоколов драйвер-устройство нереально, придется в фильтр включить все драйверы устройств. Поэтому сделали IOMMU. Как MMU, но не со стороны процессора, а со стороны чипсета, так что обращения bus masters фильтруются железом наподобие того как MMU это делает со стороны процессора.
> А теперь повтори смотрение на DMA-контроллеры всех архитектур поддерживаемых Linux. Начни
> с ARM, MIPS и PowerPC, потом поговорим о простоте прослойки.Простота тоже относительна. Относительно решаемой задачи - секурити без компромисов.
> И не забудь узнать кто такой (PCI) bus master и чего может.Дань скорости, наследие прошлого...
> Устройства которые bus master - могут к памяти обращаться сами.Ну что ж, если железо против безопасности - софтом тяжко всё исправить.
> Поэтому сделали IOMMU. Как MMU, но не со стороны процессора, а со стороны чипсетаНу, логичный шаг.
Т.е. всё-таки имеет место тенденция к разграничению областей доступа. И микроядро придёт в любом случае.
> Простота тоже относительна. Относительно решаемой задачи - секурити без компромисов.Безопаснее всего - не включать. Или хотя-бы к сети не подключаться, но там уже возможны варианты.
Ты включаешь x86 компьютер. Что происходит? Management Engine - слышал? Прошивка подписана Intel, ее нельзя удалить: шатдаун через 30 мин. ME может использовать сеть чипсета, в обход ОС, делать DMA и проч. Даже ОС переставить можно. Исходники ME firmware - где? Подробнее - на сайте libreboot. Мало? Почитай про SMI. А equation умеет прошивку HDD патчить.
> Дань скорости, наследие прошлого...
В настоящем еще интереснее. В современном х86 компьютере есть с десяток служебных процессоров разной степени опасности. Тебе синюю или красную?
> Ну что ж, если железо против безопасности - софтом тяжко всё исправить.
Железо в x86 нашпиговано сюрпризами.
> Т.е. всё-таки имеет место тенденция к разграничению областей доступа.
Да. Но "без компромиссов" там и близко нет, а сколь-нибудь приличный уровень безопасности при наличии выхода в сеть обеспечить - та еще задача. Большинство софта вообще не писалось с security in mind, монолитные ядра в этом плане далеко не хучшие.
> И микроядро придёт в любом случае.
Смотря куда придет. Торвальдс начинал писать Linux на Minix, не став дожидаться когда Hurd допишут. Прошла четверть века - кто и где?
Да, спасибо за ликбез!
И картину прояснили и время сэкономили!
Изначально тупая затея. Проблема защиты - далеко не высота забора между процессами, а сам принцип, что приложения генерируют файлы - именно так вирус может спокойно бродить по системам, будь они хоть стократно завёрнуты в контейнеры. Написал док-файл, отослал другу - вот тебе транспорт, дорогой вирус! Бороться с этим нереально, это сам принцип взаимодействия людей.
Соц. инженерия конечно, объемлет техническую безопасность (если все будут идиотами - никакие секурити не помогут).
Но при вынесении соц. вопроса за скобки - чем больше преград при той же пользовательской функциональности - тем секурнее.
> Но при вынесении соц. вопроса за скобки - чем больше преград при
> той же пользовательской функциональности - тем секурнее.Количество преград не помешало comodohacker захватить аккаунт админа active directory в diginotar, после чего компании осталось только заявить о банкротстве - после этого ВСЕ виндовые машины следует считать скомпрометированными.
> Написал док-файл, отослал другу - вот тебе транспорт, дорогой вирус!
> Бороться с этим нереально, это сам принцип взаимодействия людей.Разграничивать реально. При правильном использовании Qubes, файл от друга будет получен в Personal VM, и не попадет в Work VM и Banking VM. Еще один подход - переработка таких файлов в безопасное представление во временном Disposable VM:
http://theinvisiblethings.blogspot.ru/2013/02/converting-unt...
Временные контейнеры как-то сильно менее ресурсоемки. Хотя и менее прочны. Зато firejail-ом создаются в любом современном linux на раз-два. Хороший способ укрепить повседневную систему на всякий случай.
> Временные контейнеры как-то сильно менее ресурсоемки. Хотя и менее прочны.
> Зато firejail-ом создаются в любом современном linux на раз-два.http://ftp.altlinux.org/pub/people/ldv/hasher/thesis-2005.html :)
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 интересен готовыми профилями и тем что сам делает типовые операции. Они сделали контейнеры правильно.
>VT-d/AMD IOMMUЩаз, одни материнские платы чего стоят с поддержкой этой технологии.., не говоря уж о процессорах.Да и памяти там сильно желательно хотя бы 16 ГБ ОЗУ.Лучше 32. Да никто не спорит,что 32 лучше,чем 16 :)
Извиняюсь за оффтоп. Подскажите, как сделать чтобы окна раскрашивались в цвета приложения, как на последнем скрине?
Это индикатор AppVM в котором запущен процесс. Тоесть чисто qubes'овская штука, и то что там случайно совпали цвета - это совпадение.
Чего люди не придумают,лишь бы не писать правила для SeLinux :)
Как с помощю SeLinux заблокировать доступ в Интернет для определённой программы? Если она нативная? Если она на Java?
в селинукс писать правила для каждого приложения сложно.
в Apparmor проще. мало того можно обучать его доступам для нужной вам программы.
да и доступ к сети контролируется просто. Смотрите в мануале раздел Network rules.
http://wiki.apparmor.net/index.php/AppArmor_Core_Policy_Refe...
> в селинукс писать правила для каждого приложения сложно.
> в Apparmor проще. мало того можно обучать его доступам для нужной вам
> программы.
> да и доступ к сети контролируется просто. Смотрите в мануале раздел Network
> rules.
> http://wiki.apparmor.net/index.php/AppArmor_Core_Policy_Refe...В selinux тоже обучение появилось.
> Чего люди не придумают,лишь бы не писать правила для SeLinux :)вот firejail придумали - тот же результат, только за 2 минуты времени, не говоря уж о том что selinux отключает любой уважающий себя эксплойт первым же делом.
> вот firejail придумали - тот же результат, только за 2 минуты времени,
> не говоря уж о том что selinux отключает любой уважающий себя
> эксплойт первым же делом.Спасибо за ссылку. Действительно, вполне годная реализация seccomp'а
Персистентность планируется?
> Персистентность планируется?В Qubes есть как постоянные, так и временные VM. Показанные на большинстве скриншотов как раз постоянные. Т.е., например, я поставил Adobe Flash в Untrusted VM, и теперь он там просто есть.
Изоляция приложений, какой она не должна быть. Вместо того чтобы сделать хотя бы как в ведроиде.
