Йоанна Рутковская (http://ru.wikipedia.org/wiki/%D0%A0%D1%8... (Joanna Rutkowska) представила (http://blog.invisiblethings.org/2015/10/01/qubes-30.html)&nb...выпуск операционной системы Qubes 3.0 (https://wiki.qubes-os.org), реализующей идею (https://www.opennet.me/opennews/art.shtml?num=34732) использования гипервизора для строгой изоляции приложений и компонентов ОС (каждый класс приложений и системные сервисы работают в отдельных виртуальных машинах). Для загрузки подготовлены (https://www.qubes-os.org/downloads/) установочный DVD (3.7 Гб) и экспериментальный Live USB. Для работы необходима (https://www.qubes-os.org/hcl/) система с 4 Гб ОЗУ и 64-разрядным CPU Intel или AMD, желательно с поддержкой технологий VT-x/AMD-v и VT-d/AMD IOMMU.
Приложения в Qubes разделены на классы в зависимости от важности обрабатываемых данных и решаемых задач, каждый класс приложений, а также системные сервисы (сетевая подсистема, работа с хранилищем и т.п.), работают в отдельных виртуальных машинах. При этом указанные приложения бесшовно доступны в рамках одного рабочего стола и выделяются для наглядности разным цветом обрамления окна. Каждое окружение имеет доступ на чтение к базовой корневой ФС и локальному хранилищу, не пересекающемуся с хранилищами других окружений, для организации взаимодействия приложений используется специальный сервис.<center><a href="https://www.qubes-os.org/attachment/wiki/GettingStarted/snap... src="https://www.opennet.me/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>
В качестве основы для формирования виртуальных окружений может применяться (https://www.qubes-os.org/doc/Templates/) пакетная база Fedora и Debian, также сообществом поддерживаются шаблоны для Whonix, Ubuntu и Arch Linux. Пользовательская оболочка построена на основе KDE. Когда пользователь запускает из меню KDE приложение, это приложение стартует в определенной виртуальной машине. Содержание виртуальных окружений определяется набором шаблонов. В каждом виртуальном окружении приложения запускается отдельный X-сервер, упрощённый оконный менеджер и видеодрайвер-заглушка, транслирующий вывод в управляющее окружение в композитном режиме.
<center><a href="https://www.qubes-os.org/attachment/wiki/GettingStarted/r2b1... src="https://www.opennet.me/opennews/pics_base/0_1443722413.png&q... style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
Особенности нового выпуска:
- Уход от привязки к Xen в пользу использования универсальной прослойки HAL (http://blog.invisiblethings.org/2013/03/21/introducing-qubes... (Hypervisor Abstraction Layer), использующей libvirt для абстрагирования от типа используемого гипервизора. Из гипервизоров официально пока поддерживается только Xen, но нет никаких преград для портирования под другие системы виртуализации.<center><a href="http://4.bp.blogspot.com/-rO-XZF5DsFk/UUsxPE-PUXI/AAAAAAAAAL... src="https://www.opennet.me/opennews/pics_base/0_1443722236.png&q... style="border-style: solid; border-color: #606060; border-width: 1px;max-width:100%;" title="" border=0></a></center>
- Обновление Xen c версии 4.1 до выпуска 4.4 (https://www.opennet.me/opennews/art.shtml?num=39279) со стеком libxl, что позволило расширить поддержку оборудования и увеличить производительность (вместо vchan задействована штатная библиотека libvchan);
- Представлены официально поддерживаемый шаблон (https://www.qubes-os.org/doc/Templates/Debian/) окружения для Debian GNU/Linux 7 и 8;
- Интегрирован шаблон (https://www.whonix.org/wiki/Qubes) на базе дистрибутива Whonix, который можно использовать в качестве альтернативы TorVM (https://www.qubes-os.org/doc/TorVM/) для предоставления гарантированной анонимности при выходе в сеть;
- Новая реализация механизма Qrexec (https://www.qubes-os.org/doc/Qrexec3Implementation/), который позволяет выполнять команды в контексте заданных виртуальных окружений, например, когда пользователь запускает из меню KDE приложение, это приложение стартует в определенной виртуальной машине. В новом Qrexec значительно увеличена производительность за счёт реализации возможности прямого соединения виртуальных машин и применения буферов большего размера;
- Улучшенная система сборки, в которой появилась поддержка применения плагинов, специфичных для определённых дистрибутивов, и шаблоны сборки, основанные на DispVM (https://www.qubes-os.org/doc/DispVMCustomization/);
- Увеличение качества кодовой базы за счёт внедрения системы автоматизированного тестирования.
В октябре планируется начать тестирование следующей версии Qubes 3.1, в которой появится поддержка UEFI, будет стабилизирован образ Live USB и воплотится в жизнь концепция предконфигурированных стеков, предоставляющих готовые настройки для использования Whonix/Tor, Split GPG или изолированной USB VM, включение котрых в настоящее время требует ручной настройки.
URL: http://blog.invisiblethings.org/2015/10/01/qubes-30.html
Новость: http://www.opennet.me/opennews/art.shtml?num=43069
а для запуска ей необходимо 4Гб ОЗУ - типа за "безопасность" надо платить?
А что 4ГБ это сейчас такая роскошь? С учетом виртуализации, понятно на что тратятся эти гигабайты.Вот то что TPM рекомендуется это более серьезная проблема с моей точки зрения.
Да но для запуска нормального количества уже будет нужно 64гб ОЗУ вашего ноутбука.
> Да но для запуска нормального количества уже будет нужно 64гб ОЗУ вашего
> ноутбука.Про KSM что-нибудь слышал?
> Вот то что TPM рекомендуется это более серьезная проблема с моей точки зрения.Почему?
TPM это a) гарантия хорошего генератора случайных чисел, б) место, куда можно надежно спрятать ключи шифрования и прочее (намного надежнее, чем без TPM, когда они хранятся на жестком диске) с возможностью ограничения доступа только при использовании доверенной цепочки (подписанный загрузчик/ядро/модули, если кто-то пытается загрузиться другим способом, например с флешки, ключи недоступны и извлечь их невозможно) и прочие плюшки. Он сильно увеличивает защищенность системы при правильном подходе. Спецификация TPM - открытый стандарт ISO. То, что его могут использовать технологии DRM для хранения *не* является его недостатком, если вас это смущает, не связывайтесь с этими технологиями и все. TPM это просто средство, а не источник проблем сам по себе.
Увы, в России TPM несертифицирован если не ошибаюсь,поэтому в продаже отсутствует.
соболь купи
Уже давно всё доступно.
> Увы, в России TPM несертифицирован если не ошибаюсь,поэтому в продаже отсутствует.Между прочим, в любом ноуте или планшете на атомном Bay Trail (и выше) есть TPM 2.0, безо всяких дополнительных чипов и трат. Он просто встроен в SoC. Пользуйся - не хочу!
Вообще-то, в TPM нельзя ничего спрятать, там нет хранилища. Ключи хранятся на винчестере в зашифрованном ключом, который находится в TPM, виде.Но вообще, да, TPM, по моему мнению, это хорошо.
#> TPM это просто средство, а не источник проблем сам по себе.
> Но вообще, да, TPM, по моему мнению, это хорошо.Бесполезная ня, которая не прокатила у проприерастов. "Хорошо"?
---
https://www.gnu.org/philosophy/can-you-trust.html :""[...]модули оказались совершенно непригодными для[...]вообще не применяются для цифрового управления ограничениями, и есть основания полагать, что применять их для этого будет невозможно. [...]ограничены невинными второстепенными приложениями — такими как проверка, что никто не изменил украдкой систему на компьютере.
[...]не опасны, и нет оснований отказываться от включения такого модуля в состав компьютера или от поддержки его в системных программах.
[...]Это не значит, что все превосходно.
[...]не означает, что удаленное освидетельствование безвредно.
> #> TPM это просто средство, а не источник проблем сам по себе.
>> Но вообще, да, TPM, по моему мнению, это хорошо.
> Бесполезная ня, которая не прокатила у проприерастов. "Хорошо"?Какое отношение текст по ссылке имеет к вопросу?
TPM это технология, сама по себе нейтральная, с полезной функциональностью. Столлман протестует не против технологии, а против софта и разработчиков этого софта, которые могут использовать ее для того, чтобы ограничить свободу пользователя, да так, что он не сможет легко это ограничение снять (и тут надежность и функциональность TPM на руку разработчику "плохого" софта). Его мнение разумно и понятно, но оно никак не отменяет факта, что TPM - полезная штука, и может быть использована в своих целях (напр. для защиты приватности пользователя).
Есть небольшое хранилище NVRAM (напр. luks умеет там ключ держать, 256-ти битный вполне влезает). А в новой версии TPM дополнительно для каждой иерархии (платформа/хранилище/ограничение доступа) можно сохранять ключи разных алгоритмов, напр. RSA, ECC-ключи, SHA256 и прочее. Т.к. можно дернуть любую несимметричную или симметричную криптографическую функцию относительно этих ключей, мне видится, можно составить реальный ключ шифрования декодированием пароля пользователя (к примеру) ключом в TPM - и получить много ключей для разных целей.
По моему слишком избыточно и сложно, любой шаг в сторону от дефолта будет вызывать боль и страдания.
Тогда ставь убинту и не мешай взрослым дядям наслаждаться шедевром умной тети.
Разработчики всего мира отчаянно пытаются доказать, что код на Си может лагать и жрать памяти больше чем Java. Вот на кой чёрт каждому приложения нужно своё персональное ядро ОС? Даже микроядерная архитектура с общими библиотеками будет жрать меньше ресурсов, обеспечивая аналогичный уровень изоляции.
Как раз эта проблема относительно просто решается системами поддерживающими паравиртуализацию, в которой виртуалка почти ничего не стоит в плане потребления памяти. Но, конечно, с соответствующим понижением степени изолированности. Впрочем, количество пробоев на уровне ядра заметно меньше количества пробоев на прикладном уровне.
Это "почти ничего не стоит" вылилось в 4Гб памяти при старте Qubes. В моём понимании "почти ничего" это менее 10% от изначальных затрат.
ОС не для нашего времени. Лет через 15, когда в Эльдорадо будет слоган "64 ядра, 64 гига!", такой оверхед не будет казаться оверхедом.
Лет через 15??? Тогда будет слоган "64 гигаядра, 64 петабайта!"
Да уж если через 15 лет 64 ядра будут в десктопных процах - и то хорошо. А то чот наращивание количества ядер фактически остановилось.
Не забываем фразу про 640 Кб. Как ни как но 1 Гб намного больше чем 640 Кб, на 640 в своё время писались качественные приложения, а сейчас и 4 не хватает. Что будет через 15 лет страшно подумать.
Коммент из будущего: То, что приложение потребляет 20Гб это нормально, у меня 256Гб и всё летает. При нынешних ценах на оперативку такой объём памяти не проблема.
Серьёзно, у софтописателей вошло в привычку выжирать все доступные ресурсы.
"Надо бабки делать, а не оптимизацией заниматься!" - лозунг написания современного ПО.
"Да. И вообще, все утилиты GNU надо заменить. Они хоть и отлаженные годами, но ведь старые, а значит непригодны для нашего времени. Мы напишем свои альтернативы, и кстати будем для этого использовать не GPL, а истинно свободные MIT- и BSD-лицензии. Такие инновации требуют средств, не дураки же мы работать бесплатно. Прежде, чем писать, мы обложимся правительственными грантами с одной стороны, и поддержкой больших корпораций, навроде Google, Microsoft и Red Hat с другой. И мы не будем планировать систему на выброс, как завещал Брукс, мы сразу пихнём её в продакшн. Да, пользователям будет не удобно, однако такова цена прогресса. К тому же, мы развернём пиар-компанию о том, какая наша новая система инновационная, полезная и удобная".
>И мы не будем планировать систему на выброс, как завещал Брукс, мы сразу пихнём её в продакшн.Мне кажется или с GPL та же ситуация?
работает она быстро, нормально и на 2-ух гигах, сам пробовал, но вот когда пробовал в прошлом году стабильности не хватало, так что рекомендуемые тут не значит обязательные
Кроме памяти, большой проблемой является отсутствие видеоускорения.
А у меня вопрос, а зачем изолировать все? Почему нельзя просто для каждой программы сделать chroot? В чем прймущество такого подхода?
> А у меня вопрос, а зачем изолировать все? Почему нельзя просто для
> каждой программы сделать chroot? В чем прймущество такого подхода?Вместо того, чтобы просто отстроить безопасность системы - не представляете, OpenVMS это умела задолго не только до гипервизоров, но даже до SMP-систем - и это возможно, мать вашу, без всякой сpaной виртуализации, которая только добавляет слоев, но не безопасности - вы, недоумки, пытаетесь косорукость и косорылость скомпенсировать тюрьмами-чрутами-виртуалками.
параноя...вот она в чистом виде....
Вот так все расписано а где дрова брать под винду??
