В гипервизоре Xen обнаружена (http://lists.xenproject.org/archives/html/xen-announce/2014-...) опасная уязвимость (CVE-2014-7188), позволяющая инициировать крах хост-окружения или прочитать данные на уровне гипервизора или других гостевых систем. Эксплуатация возможна при выполнении специально оформленных гостевых систем, работающих в режиме полной виртуализации (HVM). Например, данный режим поддерживается во многих облачных службах, включая Amazon Elastic Compute Cloud, RackSpace и некоторых решениях на базе OpenStack. Уязвимость может быть использована для компрометации серверной инфраструктуры данных служб.
Проблеме не подвержены конфигурации, в которых гостевые системы выполняются только в режиме паравиртулизации (PV). Исправление пока доступно в виде патча (http://xenbits.xen.org/xsa/xsa108.patch). Проблема проявляется в Xen 4.1 и более новых выпусках на системах с процессорами x86.URL: http://lists.xenproject.org/archives/html/xen-announce/2014-...
Новость: http://www.opennet.me/opennews/art.shtml?num=40724
Я, как продавец_кирпичей, заявляю - кирпичей будет много
кирпичей не знаю, но перезагрузок серверов - да.
Янка Руткитовская фпечали, опять Qubes дырявый :)
> Янка Руткитовская фпечали, опять Qubes дырявый :)Анка Пулеметчица, версия 2.0 :)
В прошлый раз дебиановцы своим секьюрити-апдейтом сломали проброс видюх в гостевую систему и, вроде бы, до сих пор не исправили. Интересно, что у них отвалится на этот раз?
Кстати, у рутковской тоже дырка! Могла бы часть доменов сделать pv, а по необходимости использовать hvm.
В Qubes под HVM только Windows-окружения запускаются.
Кажется, мы оба неправы. Судя по прошлой новости, тамошнее appvm предназначено для любых не-pv ос.
Нет, для Linux там PV. HVM появился только в Qubes 2 и применяется специально для Windows или для запуска нестандартных систем.
тогда текст прошлой новости надо поправить
Там про это в списке новшеств написано, что в новой версии появилась возможность использования HVM. Про то, что HVM используется по умолчанию ничего нет.
> Нет, для Linux там PV. HVM появился только в Qubes 2 и применяется специально для Windows или для запуска нестандартных систем.Дык, PV быстрее и менее накладно. Только для закрытого крапа PV делать геморно, вот и приходиться отползать на HVM.
> В Qubes под HVM только Windows-окружения запускаются.А какая разница - из виндовой программы тебя поимеют или из линуксной?
>Кстати, у рутковской тоже дырка!Да вы шо?!
Если вдоль, то не интересно
> включая Amazon Elastic Compute Cloud,Теперь эластичность им пригодится - их натянут :).
> RackSpace
А эти могут переименоваться в HackSpace.
Только я задумал попробовать детище Рутковской...
Даа, с этой уязвимостью твой локалхост точно сломают
Ща рожу
Билана?
и это в который уже раз. при этом, ксенолюбители все еще кричат о том что у них система безопаснее чем kvm
Амазон ребутал сотни виртуалок, все перегрузились шустро. А вот парочка виртуальных машин, у которых номер 13 был в хостнейме - полчаса висели в непонятном состоянии. Задумаешься...
Надо слушать людей которые хоть что-то понимают в компьютерной безопасности: kerneltrap.org/OpenBSD/Virtualization_SecurityПоскольку эту ссылку зделали недоступной и 99% российских админов убеждённо и упрямо считают виртуализацию как средство безопасности приведу здесь мнение Тео:
"В списке рассылки OpenBSD началось обсуждение по поводу возможности включения технологии виртуализации Xen в эту операционную систему. Было высказано предположение, что виртуализация должна стать приоритетом в связи с вопросами безопасности. Цитата: "Виртуализация, как нам кажется, имеет большое количество преимуществ в плане безопасности".
Создатель OpenBSD Theo de Raadt категорически не согласился с этим предположением: "Вы обкурились чем-то совершенно невозможным и вы должны срочно с нами этим [травой] поделиться". Далее он высказался так: "[Виртуализация] это как нечто красивое и разноцветное, лежащее на полке [магазина], и что вы, наконец, купили".
Он пояснил это изречение следующими словами: "Виртуализация на платформе x86 в самом простом случае обычно выражается в виде запуска дополнительной, практически полновесной версии ядра, содержащей большое количеством ошибок, на основе отвратительной архитектуры x86, которая едва ли имеет правильную защиту страниц [памяти]. Затем вы запускаете другую ОС в другой части этой кучи экскрементов [shit]. Вы находитесь в абсолютном заблуждении, если не сказать, что вы глупы, если думаете, что мировое сообщество софтверных инженеров, которые не могут написать ни ОС, ни приложения без ошибок в безопасности, вдруг написали слой виртуализации их не содержащий".
дыры будут всегда, но именно поэтому надо выбирать архитектуру в которой может оказаться меньше дыр by design и это - kvm
> дыры будут всегда, но именно поэтому надо выбирать архитектуру в которой может
> оказаться меньше дыр by design и это - kvmНу сомнения терзают, kvm проще за щёт использования спец инструкций процов. Но всё равно в Линукс и ФриБСД с дизайном виртуализации большие проблемы, как раз by design этих ОС.
В OpenBSD тоже дизайн для виртуализации не подходит. Тэо это понимает и от виртуализации отказался.
На сегодня пока единственная в мире ОС где с виртуализацией "by design" проблем быть не должно - DragonFlyBSD. Она именно с целью реализации простой и правильной виртуализации пишется... Хотя сие их утверждение требует отдельной проверки со стороны.
>> дыры будут всегда, но именно поэтому надо выбирать архитектуру в которой может
>> оказаться меньше дыр by design и это - kvm
> Ну сомнения терзают, kvm проще за щёт использования спец инструкций процов. Но
> всё равно в Линукс и ФриБСД с дизайном виртуализации большие проблемы,
> как раз by design этих ОС.ну так в линуксе есть куча средств для улучшения безопасности. для виртуализации есть специальный selinux - svirt. вообще, таких новостей как эта, о KVM пока не было, и на это есть хорошие причины.
> Ну сомнения терзают, kvm проще за щёт использования спец инструкций процов. Но
> всё равно в Линукс и ФриБСД с дизайном виртуализации большие проблемы,Да понятно что на проволоку и скотч привинтили, но от ОС надо чтобы это работало, а не чтобы это был отполированный музейный экспонат.
> как раз by design этих ОС.Сам по себе design ОСей достаточно нейтрален к виртуализации. Единственная проблема - гипервизор это часть ядра. Достаточно большого. Там потенциально могут быть баги. Поэтому рутковска и взяла Xen. Там гипервизор сам по себе и мелкий. Что иронично, в xen с тех пор было здорово больше багов чем в KVM. Чем-то таким теория и отличается от практики. А, ну у фрибзд еще 1 проблема - у них виртуализации можно считать что нет. Потому что всякое недопиленное/экспериментальное недоразумение при наличии полудюжины решений в виде пригодном для продакшна - ну вы поняли. Рынок уже поделили и там фрибзды уже не ждут. А так все хорошо.
> В OpenBSD тоже дизайн для виртуализации не подходит. Тэо это понимает и
> от виртуализации отказался.А Тео вообще сидит в своем сельском скворечнике. И удобства во дворе. Зато рассуждает что этот ваш унитаз в теплом доме - штука ненадежная. В водопроводе может пропасть вода, насос может сломаться, особо толстый зад унитаз не выдержит. А в его седалище он дескать каждый гвоздик знает. И оно сколочено с таким запасом что выдержит даже небольшого слона. Может и выдержит. Но большинству людей будет обломно тащить свой окорок на мороз. А у тео нет никаких предложений как это улучшить. Его ответ - "морозьте задницы".
> проблем быть не должно - DragonFlyBSD.
Когда и если ей кто-то будет пользоваться столько же сколько Xen и KVM - мы и посмотрим насколько это правда. Про Xen тоже так говорили, при том эксперт в области, собственно, Рутковска. А на практике - эвона оно как :).
> Да понятно что на проволоку и скотч привинтили, но от ОС надо
> чтобы это работало, а не чтобы это был отполированный музейный экспонат.так весь линукс это проволока и скотч, и что самое приятное - работает ведь.
> Сам по себе design ОСей достаточно нейтрален к виртуализации. Единственная проблема -
> гипервизор это часть ядра. Достаточно большого. Там потенциально могут быть баги.не сомненно, только они в любом случае будут иметь место, не в микроядре Xen так в Dom0.
> Поэтому рутковска и взяла Xen. Там гипервизор сам по себе и
> мелкий. Что иронично, в xen с тех пор было здорово больше
> багов чем в KVM. Чем-то таким теория и отличается от практики.KVM гораздо более минималистичен чем Xen, там кода не больше чем в любом другом модуле ядра (изначальную версию Ави написал за 6 недель емнип), это в принципе драйвер для VT и SVM, и все. Нет дополнительных шедулеров, и прочих костылей, все остальное уже и так умеет само ядро, которое по определению проходит больше проверок на безопасность и стабильность чем Xen. Без дополнительных костылей, стандартные линуксовые системы работают без костылей. так что cgroups, selinux, apparmor и т.д. нативно дополняют процессы KVM, а Xen просто никак к ним не относится, и торчит голой задницей в сеть.
>[оверквотинг удален]
>> оказаться меньше дыр by design и это - kvm
> Ну сомнения терзают, kvm проще за щёт использования спец инструкций процов. Но
> всё равно в Линукс и ФриБСД с дизайном виртуализации большие проблемы,
> как раз by design этих ОС.
> В OpenBSD тоже дизайн для виртуализации не подходит. Тэо это понимает и
> от виртуализации отказался.
> На сегодня пока единственная в мире ОС где с виртуализацией "by design"
> проблем быть не должно - DragonFlyBSD. Она именно с целью реализации
> простой и правильной виртуализации пишется... Хотя сие их утверждение требует отдельной
> проверки со стороны.Спецы нахрен такие спецыалные спецы-Ыксперты аналитики опеннета - трындим и трындим.
По делу едиственная рабочая ( БСЭМ-6 померла, к сожаления)
безопасная виртуализация - IBM System z9 ( и где то в какой то мере AS400).
То, что аналЫтеГЫ опеннета про них не видели - вполне закономерно :-(
> ОС, ни приложения без ошибок в безопасности, вдруг написали слой виртуализации
> их не содержащий".Тео упускает из вида соотношение затрат усилий к результату. Виртуалки позволяют получить изоляцию близкую к железной при минимальных затратах сил на администрирование и минимальном изменении практик администрирования. Это админится как просто отдельная система.
Да, это не идеально. Но зато это легко настраивается и улучшает защищенность, попутно позволяя полнее использовать железо. А у Тео из решений вообще есть только громкие бла-бла и фига в кармане.
> и улучшает защищенность,Да виртуалки сильно помогают и упрощают админам жизнь. Но они были сделаны и есть средством виртуализации, а не безопасной изоляции.
Использовать виртуалки можно НО НЕ КАК СРЕДСТВО БЕЗОПАСНОСТИ.
> А у Тео из решений вообще есть только громкие бла-бла и фига в кармане.
Пока у него есть единственная в мире безопасная ОС.
> Да виртуалки сильно помогают и упрощают админам жизнь. Но они были сделаны
> и есть средством виртуализации, а не безопасной изоляции.По изначальной задумке - это именно средство безопасной изоляции, то-есть, подразумевается развязка от хоста и невозможность ему нагадить. То что иногда возможны баги позволяющие это обойти - ок, но они возможны и в иных реализациях решений по изоляции (про это концептуалы почему-то тактично молчат в тряпочку, делая вид что они святоши и их баги не касаются, что попахивает лицемерием).
И если сравнивать например безопасность машины где форум, почтарь, DNS и все остальное висело на 1 машине, сломали форум - унесли всю почту - покорежили DNS и прочее vs когда оно на все той же машине по отдельным VM и хаксор застрял на машине с форумом и попортил только форум - вот извините, безопасность определенно улучшилась. То что в сильно некоторых случаях хакер может попробовать вылезти за пределы VM - ок, но Xen и KVM нынче используются на коммерческой основе для хостинга и массовых взломов через VM что-то не видно. Обычно если у хостеров что-то и ломают - так это дырявую и открытую всем ветрам панель управления, которая позволяет что угодно в административных целях, а там уже все-равно какие операционки были.
> Использовать виртуалки можно НО НЕ КАК СРЕДСТВО БЕЗОПАСНОСТИ.
В том числе и как средство безопасности.
> Пока у него есть единственная в мире безопасная ОС.
Которая безопасна по примерно тем же причинам по которым неуловим неуловимый Джо. Всякие колибри и менуэты тоже безопасные. По примерно тем же причинам. И у Тео вообще нет никаких решений. Он просто сидит в своем деревянном сортире и рассказывает нам про то что наш унитаз неправильный.
> про это концептуалы почему-то тактично молчат в тряпочку, делая вид что они святоши и их баги не касаются, что попахивает лицемериемБаги делают все люди, это наша сущность, кто меньше кто больше... Но хотел сделать акцент на другом, XEN сложен, ибо Линукс изначально для виртуализации не был спроэктирован, следовательно из-за сложности ошибок будет больше! Кроме того он не спроэктирован с учётом безопасности, в угоду быстроте и упрощению.
> И если сравнивать например безопасность машины где форум, почтарь, DNS и все остальное висело на 1 машине, сломали форум...
Для изоляции сервисов в Юникс применяют технологию chroot. Сегодня есть укреплённые её варианты https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity... помещающие процес в изоляционную тюрму. И для безопасной изоляции процесов рекомендуется использовать их.
>> Использовать виртуалки можно НО НЕ КАК СРЕДСТВО БЕЗОПАСНОСТИ.
> В том числе и как средство безопасности.Нет! Только как удобное средство хостинга. Критичные данные с помощью виртуалок охранять не стоит.
> И у Тео вообще нет никаких решений. Он просто сидит в своем деревянном сортире и рассказывает нам про то что наш унитаз неправильный.
Ты считаешь что твой Линукс правильный в плане безопасности? :)
установи и запусти paxtest(http://pax.grsecurity.net/), checksec(http://tk-blog.blogspot.ru/search/label/checksec.sh), hardening-check(https://wiki.debian.org/Hardening), scanelf(http://hardened.gentoo.org/pax-utils.xml)
Могу поспорить что твой "правильный унитаз" даже элементарное выделение памяти не контролирует по ГЛАВНОМУ правилу безопасности: ВСЁ ЧТО ИСПОЛНЯЕТСЯ НЕ ДОЛЖНО ИЗМЕНЯТСЯ, А ВСЁ ЧТО ИЗМЕНЯЕТСЯ НЕ ДОЛЖНО ИСПОЛНЯТСЯ! По этому любой баг при проверки длины -> переполнение буфера -> взлом... пример: https://www.linux.org.ru/news/security/9162177?cid=9170049
Так вот в Линукс ядре возможности:
CONFIG_PAX_KERNEXEC=y
PAX_MEMORY_UDEREF=y
PAX_USERCOPY=y
CONFIG_GRKERNSEC_KERN_LOCKOUT=y
были реализованы в значительной мере благодаря Тео.Также все ssl, ssh и почти все правильные вещи по безопасности в Линукс тоже работа Тео!
Вот так вот, не лицемерь больше ;)
>[оверквотинг удален]
> проверки длины -> переполнение буфера -> взлом... пример: https://www.linux.org.ru/news/security/9162177?cid=9170049
> Так вот в Линукс ядре возможности:
> CONFIG_PAX_KERNEXEC=y
> PAX_MEMORY_UDEREF=y
> PAX_USERCOPY=y
> CONFIG_GRKERNSEC_KERN_LOCKOUT=y
> были реализованы в значительной мере благодаря Тео.
> Также все ssl, ssh и почти все правильные вещи по безопасности в
> Линукс тоже работа Тео!
> Вот так вот, не лицемерь больше ;)Только применим твой хваленый грсек только на рутерах ( для кернелспейс машин), т.е примерно как бсд
...
> Только применим твой хваленый грсек только на рутерах ( для кернелспейс машин),
> т.е примерно как бсдНу да?!
А мы-то и не знали!.. почему-то у нас self-compiled ядра c GRsecurity на всех (1000+) production серверах по всем континентам стоят... :)
> получить изоляцию близкую к железнойДля безопасной изоляции в Линукс пока разработано это: https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity...